Sometimes (too often) you get to hear all content has to be above the fold or people will miss it. I have always been very skeptical of this, especially when applied dogmatically. I am convinced that most people who use the Web know how to scroll and will do so when necessary.

A good article to refer people to next time this discussion comes up is The myth of the page fold: evidence from user testing. In the article, which is based on data from over 800 user testing sessions, the authors come to the conclusion that the fold is not a significant barrier.

The article ends with three design tips:

1. Less is moreDon't be tempted to cram everything above the fold. Good use of whitespace and imagery encourages exploration.
2. Stark, horizontal lines discourage scrolling - this doesn't mean stop using horizontal full width elements. Have a small amount of content just visible, poking up above the fold to encourage scrolling.
3. Avoid the use of in-page scroll bars - the browser scrollbar is an indicator of the amount of content on the page. iFrames and other elements with scroll bars in the page can break this convention and may lead to content not being seen.

Note that the authors are not saying that your pages can be endlessly long and that it doesn't matter where you put the most important content. The most important stuff should still be near the top of the page, but you do not need to squeeze everything into the top 600 pixels as long as you design the page to encourage scrolling when necessary.

An understandable reaction many people have when they realise they can’t use a certain feature of HTML, CSS or other web technologies is to blame the W3C for being slow. Sometimes doing so may be correct, but a lot of the time it is browser vendors who are slow to implement emerging standards.

Keeping track of which browsers – and from which version – support a particular recommendation or standard is no easy task. But there is help. Alexis Deveria’s When can I use... contains a lot of compatibility tables for features in HTML5, CSS3, SVG and other upcoming web technologies.

Don’t need to see the whole lot? Only want to check the status for standards that have Recommendation status? Not interested in what really old browsers (do not) support? No problem – just use the filters at the top of the page to pick what interests you.

Needless to say, these compatibility tables make it very obvious which browser vendors are quick to implement new technologies and which are a little slower.

One of the purposes of the alt attribute is to provide alternate text that can be shown when an image cannot be displayed, either because it is missing or broken, or because the user has disabled images in their (graphical) web browser.

Most graphical web browsers do display alt text in place of missing images, but there is one notable exception: Safari and most other WebKit-based browsers (iCab, Shiira, Chrome). In those browsers, all you get when an image is missing is either a small blue icon with a question mark in it or a broken image icon.

Beside the decision to display a question mark instead of the more helpful alt text, there are two things that I find particularly odd:

1. OmniWeb, which is WebKit-based, does display alt text for missing images. I guess The Omni Group have added support for this on top of WebKit.
2. For images that do not have dimensions specified in HTML or CSS, the size of the placeholder is affected by the length of the alt text, even though it is not displayed.

It seems that since it affects the size of the placeholder WebKit is aware of the alt text, but does not display it. I can’t think of any reason not to display alt text for missing images, so I think this should be changed to match the behaviour of other browsers.