According to the HTML5 Boilerplate team (and many other authors, for sure), all JS on a given page should go at the bottom (right before the </body> tag) as far as this is possible, except for Modernizr due to the way it acts during page load.
Given that Google WebFonts Loader works, as far as I can tell, pretty much the same way as Modernizr (by doing #font-face feature-detection and adding classes to the <html> tag), I wonder if the same holds true for this script...
Should this go on the <head> or <body> tag? Does it matter all that much?
Short answer: as much as the pageload speed purists would love to tell you otherwise, the reality is that no, it doesn't actually matter that much. Put it at the top.
The only reason for putting JS includes at the foot of the page is for page loading performance reasons. If putting it at the top does not result in a noticeable performance drop, then it really doesn't matter. Particularly it's just the one or two scripts and you stick to having most of your scripts still at the bottom. The things is: for most sites, the difference it makes is pretty negligible.
I don't really know the answer as it applies specifically to Google Webfonts, as I haven't used that library (yet), but my advice is just stick it at the top with Modernizr, and be done with worrying about it.
Related
I'm a Graphic Designer.
I was wondering if it's possible for a programmer to code this website or I should redesign this?
Because I have doubts about how hard the header and footer are, and I think it's a really hard work for a programmer to code a website like this.
If it's not, please let me know then I will find a developer.
This is not impossible. It just takes a moment to think it through.
The footer can be made as a background image of the three colour splats which wraps three separate divs (Projects, Products, Contact Us). The header is a series of images absolutely positioned within a relative parent.
This is actually a very simple layout.
The design is bit complex and unusual but not impossible.
It's possible to convert this design in code with use of some script and css hacks mainly position and z-index based hacks
I'm doing a comparison of a bunch of landing pages in the wild. I'm trying to pull out the main header and the call to action, but of course the HTML formatting of the pages varies wildly.
I started looking for H1, H2, etc. assuming that the header tags correspond to primacy, but this is often not the case. Rendered font-size* might be a better indicator, however this seems messy and wouldn't handle cases where images with alt tags are used.
What's a good strategy to identify the main heading of 100 wild landing pages using Nokogiri?
*Also- is there a clever selector for rendered font-size?
You can't do it unless you have an AI running that can determine the most semantically important section of a document.
You can't count on the tags, such as headers or meta-tags, because those can be missing entirely.
You can't count on location in the source because CSS can move things anywhere.
And, even if you think you've got it nailed by looking at the CSS, the JavaScript can rip that reality from you because it can override everything, relying on the fact it takes a human's eyes and brain to make sense of the final rendered page.
So, basically, you're going to be mostly shooting in the dark unless you have code that can understand the content of the page and determine how often a word occurs, along with its synonyms and their root words, and then determine their placement on the page after CSS and JavaScript have been run.
It's really a tough task that a lot of big companies are spending a lot of money on.
Works fine in firefox but displaying bottom left in ie9
I assume it's either something to do with css in ie9 or the DOCTYPE?
Any help appreciated. The site this is happening on is below.
http://bydezign.co.nz/Products/Chairs/ManoliChair.aspx
Where to begin
Okay lets start with validation
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fbydezign.co.nz%2FProducts%2FChairs%2FManoliChair.aspx
Now a lot of those errors are I think as a result of not adhering to your transistional doctype. I always go xhtml1 BUT you may have your reasons for the transistional (though I can't believe anyone worth their salt nowadays would not use xhtml as it is pretty much the standard.
Sorting your doctype MAY (and probably will) solve your rendering issues but if it doesn't I would look at your use of tables for layout. This is a very big 'no-no'. You should be using divs and css for layout. It will give you much better design capabilities. Tables are not semantically correct to use for layout - they are for displaying tabular data.
Fix these first and see if that solves your issue (99% confident just the doctype and getting it through validation will resolve the issue
I'm working on a site with lots of CSS3 transitions (which are hardware accelerated) and high memory objects (for example, an array of 39 objects, each containing the full html source for a typical online news article) and I'm noticing some very choppy/jittery scrolling, which I've been unable to debug.
I've kept these high memory objects out of the DOM, which should prevent them from affecting DOM performance, however, I can't help but think that they are still having a negative effect. I don't have code samples to post because I'm unsure of whether this is even an issue.
Please go to this site (Orange) and click on an article tile. In the reader div that pops up over the page, try scrolling as you normally would. Does it feel choppy/jittery? Do you have any suggestions on how to improve this?
CSS3 transitions, opacity, text and box-shadows and the like are certainly known to impact rendering speeds. In fact, even sites with heavy use of text-shadow alone can cause choppy scrolling on the average computer. Combining this with heavy use of javascript seems like a recipe for choppy web browsing.
edit: The loading animation on the o in orange is pretty awesome!
Yes, that's jittery. A page with a lot of Javascript will do that and frameworks like jQuery won't help at all. I'd recommend recoding as much as you can without using jQuery and passing it through JSLint (http://www.jslint.com/).
Try using Chrome's developer tools too to get an idea of what the bottleneck is.
Try disabling Javascript too and seeing if it's any better. If it isn't, then you know where your problem lies.
See here: http://code.google.com/p/ie7-js/
Does anyone have any experience or remarks about this javascript? Is it worth including? Do you recommend it?
I know many people, myself included that are using various IE hacks to get transparent PNG support. THis looks like a little bit more help, and as long as it works, and the size is fairly small, I wouldn't see much against using it.
I've used it before, and my results are mixed. Those scripts cause IE to churn for a bit on page load. Basically, you have to think of it as iterating through Elements and stylesheet rules to apply "fixes" for areas that are deficient in that particular rendering engine. In some cases, depending on how complicated your markup or stylesheets are, that can take a bit of time and you will see the browser hang.
That said, if you can trade off that performance cost, you will save development time as you'll spend less time hacking around IE6 quirks; IE7/IE8 will provide enough missing functionality that you can avoid certain edge cases, can develop using standards better (min-width/min-height, multiple className selectors, etc.), and certain rendering issues will disappear.
However, if you just need 24-bit transparent PNG support, use a tool built for that. Including IE7/IE8.js for PNG support alone is like pounding in a nail with a tank. Use DD_belatedPNG for that.
It works, but its worth keeping in mind that ie7.js and ie8.js do much more than provide transparent PNG support. Even with the transparent PNG support, its worth keeping in mind that transparent background images cannot be tiled (repeated) using background-repeat or positioned using background-position. This hinders any ability to use CSS rollovers using background-position. I've only used it on one site I've done, and now that I'm updating the site I can't remove the ie8.js because if I do the entire website breaks layout in IE. I don't believe I'll be using it in the future, and instead rely on simple CSS hacks or simply allow my sites to "degrade gracefully" in IE6.
I know that there are some tools for fixing the transparent PNG problem which are more flexible than this. For instance, the jQuery plugin ifixpng2 will support background position, which ie7-js doesn't do.
As long as you are aware of exactly what it fixes, I would say go for it. I'm not sure about this lib exactly, but some libs get very expensive if you have a large DOM, as they tend to hook in HTC file base behaviors on EVERY DOM Element. This causes the dreaded "Loading x of y" status bar message to flash constantly on the initial load, and any newly generated DOM content.
well its beautiful and works grate way u can use cs3 features like li:hover. we did lost of project last time using ie8.js and it works great way.