We thought this day would never come: Internet Explorer 8 now renders the "Acid2 Face" correctly in IE8 standards mode!

Apparently we can expect to see Internet Explorer 8 in at least Beta form in early 2008. According to the IE blog:

The key goal (for the Web Standards Project as well as many other groups and individuals) is interoperability. As a developer, I’d prefer to not have to write the same site multiple times for different browsers. Standards are a (critical!) means to this end, and we focus on the standards that will help actual, real-world interoperability the most.

Sounds like the IE team has finally seen the light! :)

The title says it all: you can use an empty action attribute on a form to submit that form to the current page. This means you don't need to use server-side scripting (using REQUEST_URI or PHP_SELF or whatnot) to write the current URL into the HTML.

The following is perfectly valid:

<form action="" method="post">
    <p><input type="submit"/></p>
</form>

Now beware, the action attribute is mandatory, and it must contain a valid URI. But according to the URI RFC, an empty URI is still a URI:

4.2. Same-document References

A URI reference that does not contain a URI is a reference to the current document. In other words, an empty URI reference within a document is interpreted as a reference to the start of that document, and a reference containing only a fragment identifier is a reference to the identified fragment of that document. Traversal of such a reference should not result in an additional retrieval action. However, if the URI reference occurs in a context that is always intended to result in a new request, as in the case of HTML's FORM element, then an empty URI reference represents the base URI of the current document and should be replaced by that URI when transformed into a request.

So there you have it. Enjoy.

What are the minimum requirements for using the web?

• an Internet connection
• a web browser

What are the minimum requirements for using your web site? Well, the answer could include any of the following:

• a high-speed Internet connection
• a keyboard
• a mouse (and the ability to use a mouse)
• a large computer screen (eg. 1024x768+)
• specific web browser versions (eg. IE 7, FF 2+)
• specific browser plugins and version (eg. Flash 7 or VRML)
• JavaScript
• a PDF viewer
• near perfect vision
• lack of colour blindness
• knowledge of a language (English) or jargon (web development)
• potentially many more...

How many requirements does your site make? How many are really necessary and how many can you eliminate?

Being accessible means minimizing requirements. The less requirements you have, the more freedom people have to use your site, the more accessible it is to the world.

The more requirements you make, the more you're requiring people to have specific devices, software and even physical abilities that may not be possible. As a result, the site becomes inaccessible to some.

Of course, some requirements are necessary. Can you imagine a web site translated into every language? And what would this blog be without assuming a basic knowledge of HTML, JavaScript and CSS?

But how many are just trivial requirements, made to save a bit of programming or decision making? And how many are simply unreasonable given the wide range of physical and technical limitations people face in the world?

One thing is for sure: plain HTML makes the fewest requirements. Start with that and add other technologies carefully and unobtrusively.

Finally, there is an automated CSS Sprite Generator (via)! Just upload a zip of graphics and it will spit out a single image and a block of CSS you can use.

What are CSS Sprites? If you use a ton of CSS backgrounds for things like icons, buttons and other non-repeating graphics, then you can combine them into a single graphic and use background-position with width and height to show a slice of the larger graphic. This can make a site load faster since there are less files to download.

This is generally a pain to do by hand (not only combining the graphics, but calculating and remembering pixel positions), but with a tool like this it should be a cinch!

Are you attaching an onload function to an image but finding it doesn't always get called?

The problem is almost always this: you need to set the onload before you set the src. The reason is obvious when you think about it: if the image is in the cache, the image will be loaded immediately after setting the src, even before the onload is set.

Adding fuel to the fire, Firefox and Safari will let you set an onload immediately after (it seems they don't call the onload until the block of JavaScript finishes). This doesn't happen in Internet Explorer or Opera.

Long story short:

// evil:
var image = new Image();
image.src = 'image.jpg';
image.onload = function() {
    // sometimes called
    alert('image loaded');
};

// good:
var image = new Image();
image.onload = function() {
    // always called
    alert('image loaded');
};
image.src = 'image.jpg';

No matter how many times I come across this bug and find the solution, I end up making the same mistake a few weeks later. I'm hoping that blogging about it will get this stuck in my long-term memory.