After spending years of griping about IE6’s staying power and lamenting Microsoft’s earlier decision to advocate against upgrading to IE7 (a decision they didn’t stick with, thankfully), Microsoft has turned a new leaf today, announcing that they will be pushing updates to IE to anyone who takes part in their Windows Update service.

What does this mean? Well, it means that grandma will be upgraded to IE8 if she’s still on Windows XP or IE9 if she’s on Vista or Windows 7.

Corporations (and individuals) still have the ability to opt-out of these updates, but this move should put an end to upgrades that haven’t happened purely because users didn’t know how to upgrade to a new version of IE. As Microsoft’s own Peter Laudati so eloquently put it, “Upgrade Your Parents Browser Weekend” is now officially obsolete.

The current accessibility support implemented in browsers lags behind their implementations of the sexy new features themselves. These are still early days in the implementation of HTML5 features, so lets keep our fingers crossed that Google, Apple (Safari on Windows) and Opera will get their acts together to provide at least a basic level of HTML support in their browsers for assistive technology users. Equally it is hoped Mozilla, Apple (Safari on Mac) and Microsoft will strive to have their rate of accessibility support match their rapid implementation of the new HTML5 features.

To address the need for standardizing the implementation of accessibility features, Steve and others have begun working on the HTML to Platform Accessibility APIs Implementation Guide.

We can’t thank Steve enough for his work on this and wish him well as these efforts continue.

1. HTML5
2. CSS3
3. speed

Now three “developer previews” in, by all accounts they’re living up to that promise: HTML5 support is increasing rapidly (including support for canvas; as PPK just confirmed, their CSS3 support is nearly complete; and several benchmark tests put them right up there with Chrome in terms of speed.

In playing around with the browser, I’ve been really impressed so far. To me, IE9 really puts the oft-maligned browser on par with the remainder of the browser landscape and even gives them the edge in certain cases. My hat’s off to the IE team, this is great work. I’m excited to see what happens as it continues to develop.

You can download the IE9 preview and check out some of the demos at http://ie.microsoft.com/testdrive/, but keep in mind that you’ll need Vista or Windows 7 to run it.

This leads me to two questions:

1. Will these warnings have an impact on the use of IE6 in France and Germany?
2. What about the rest of the world?

What do you think?

Accessibility Task Force member, Bruce Lawson, interviews Hixie on how the specification for the next generation of the Web’s markup language is shaping up. Disclosure of affiliations: both work for browser vendors—Bruce for Opera, Hixie for Google (and previously, Opera and Netscape).

The spec now known as HTML 5 began with a "guerilla" group called WHATWG. How and why did the WHATWG begin?

The short answer is the W3C told us to.

The long answer: Back in 2003, when XForms was going through its final stages (the "Proposed Recommendation" vote stage), the browser vendors were concerned that it wouldn’t take off on the Web without being made a part of HTML, and out of that big discussion (which unfortunately is mostly hidden behind the W3C‘s confidentiality walls) came a proof of concept showing that it was possible to take some of XForms’ ideas and put then into HTML 4. We originally called it "XForms Basic", and later renamed it "WebForms 2.0". This formed the basis of what is now HTML 5.

In 2004, the W3C had a workshop, the "The W3C Workshop on Web Applications and Compound Documents", where we (the browser vendors) argued that it was imperative that HTML be extended in a backwards-compatible way. It was a turning point in the W3C‘s history—you could tell because at one point RedHat, Sun, and Microsoft, arch-rivals all, actually agreed on something, and that never happens.

The outcome of that workshop was that the W3C concluded that HTML was still dead, as had been decided in a workshop in 1998, and that if we wanted to do something like HTML 5, we should go elsewhere. So we announced a mailing list, and did it there.

At the time I was working for Opera Software, but "we" in this case was Opera and Mozilla acting together (with Apple cheering us from the sidelines).

How did you become editor?

I was at the right place at the right time and everyone else was too busy.

How do you personally go about editing the spec and incorporating feedback? What are your processes?

This has varied over the years, as we’ve gone from a nascent organisation with a few dozen people to a well-established project with a mailing list with 900+ subscribers. Mostly it’s all down to managing e-mail. When someone writes feedback on the spec, whether by sending an e-mail to one of the mailing lists I’m on, or by blogging somewhere, or twittering, I log their feedback in a folder on my IMAP server. Feedback gets categorised into either feedback I can work on right away, or feedback that I can’t deal with yet for whatever reason. An example of the latter would be requests relating to mutation events, because I’m waiting for DOM3 Events to update how mutation events work.

Then, I just go through all the feedback I have, e-mail by e-mail, more or less in the order that I received them, sending replies and fixing the spec to address the issues that were raised.

This has some disadvantages, for example there’s a big delay in between when someone spots an error and when I fix it. It also has some really important advantages. If I respond to feedback on something I wrote straight after writing it, I sometimes find that I have an attachment to that section, so if someone suggests a total replacement, I tend to not like their idea. But if I have a delay, I find my attachment has gone away, and I’m eager to replace my old stupid idea with their better one. (Assuming it’s better, anyway!)

What’s the hardest thing to do?

There are a few things that are hard. One is saying "no" to people who have clearly spent the time to come up with a good idea. The sad truth is that I reject almost everything that I and anyone else thinks of, because if I didn’t, the spec would be a thousand times more bloated than it is now. We get proposals for all kinds of things, and we have to have a very high bar for what goes in. There’s also the danger that if we add too many things to the spec too quickly, the browser vendors will each implement their own bit and it’ll be a big mess that won’t help Web authors.

So I have to make judgements about what is worth adding and what isn’t, and that’s hard. I’ve upset a lot of people by rejecting their ideas, because they take it personally. On the other hand, some of the most productive members of the community now are people who’ve had many of their ideas rejected, but they stuck around long enough to see a few of their ideas make it in. The best way to get an idea into the spec is to find something in the spec that’s just clearly wrong, which is something that a lot of the most active people do a lot, too!

Something else that’s hard is making up new features. The bulk of HTML 5 is actually just defining how browsers already do things, which, although complicated and sometimes unbelievably arcane, is, at the end of the day, pretty easy to spec: you test the browsers, and you write what they do. Rinse, repeat, until the spec covers every possible case.

Making up new features, though, means actually thinking about what should happen, what is the most understandable solution, figuring out how things should fit together, and so on. It’s often tempting to make something that is theoretically neat, but which doesn’t fit in with the rest of the language, too. After all, that’s where all this came from—we don’t want to create a new XForms, a really well-designed technology that doesn’t fit into the way people write pages.

What’s in the spec?

You’ve said that HTML 5 is in "direct competition with other technologies intended for applications deployed over the Web, in particular Flash and Silverlight". Why is it so important to do so, and isn’t it a lost cause given that those techologies are already out there while HTML 5 is not yet complete?

HTML 4 is also in direct competition with proprietary technologies, and it’s winning, hands-down. HTML5 is just continuing the battle, because if we don’t keep up, then the proprietary technologies will gain ground.

What are the main philosophies of HTML 5?

Backwards-compatibility, incremental baby steps, defining error handling. Those are the main philosophies.

What else did WHATWG try to achieve with this new iteration of HTML?

We started from trying to put features from XForms into HTML 4, and we quickly also took the opportunity to fix some of the things in HTML 4 that were either too vague or disagreed with reality (that is, where the browsers all did one thing but the spec said another). It turns out that HTML 4 is so vague that this is a pretty big task—it even involved defining the whole HTML parsing model, including error handling, which is a huge job (it took me the better part of a month to write the first draft, and we were tweaking it for about a year before it become more or less stable).

Something else we’ve tried to do is make things simpler. We’ve simplified the syntax (e.g. the rules about what can be quoted, what strings are valid ids, etc, are much simpler now). We’ve made things which people used to do in JavaScript have shortcuts, so now you can just say autofocus="" to focus a form field when the page loads, instead of using control.focus(), which allows the browser to do clever things like not actually focus the control if the user is already typing elsewhere.

Does HTML 5 legitimise tag soup? Does "paving the cowpaths" perpetuate bad markup?

No, HTML 5 actually makes the rules for markup even stricter than HTML 4 in many ways, both for authors (the rules are simpler, but stricter, than HTML 4′s) and for implementers (gone are the days where they can just do whatever they want when handling parse errors, now every browser has to act the same).

Hopefully, we’ve managed to make the rules on what is valid syntax more understandable, which should help with getting more good markup. We’ve also made it possible to write clearer validators, so I have high hopes.

Does including JavaScript and DOM APIs in the HTML 5 spec dilute the message about separating behaviour and structure?

I didn’t know about a message about separating behaviour and structure, I must have missed that memo! HTML 5 takes a pretty hard line on separating style and presentation from structure and semantics; there are no more font tags. Separating the logic and behaviour from the structure and semantics of an HTML document isn’t as important, generally, as far as I can tell.

The main advantage of defining the HTML DOM APIs and the HTML elements in the same specification is that we don’t let stuff fall through the cracks. In practice, browsers implement the HTML elements as DOM nodes, there’s no difference. When we separate the two in the specs, therefore, we introduce a conceptual gap where there isn’t one in reality. The DOM2 HTML spec, for instance, doesn’t say what happens when you change the type attribute of an input element from text to checkbox on the fly, and the HTML 4 spec doesn’t mention that changing attributes on the fly is possible, so in the HTML 4 / DOM2 HTML era, there’s a big hole there. In HTML 5, this is all defined together, so we can tighten this up and make sure there are no gaps.

Why no native support for microformats/ RDFa in HTML 5?

Microformats is natively supported in HTML5, just like it was in HTML 4, because Microformats use the built-in extension mechanisms of HTML.

We considered RDFa long and hard (in fact this is an issue that’s a hot topic right now), but at the end of the day, while some people really like it, I don’t think it strikes the right balance between power and ease of authoring. For example, it uses namespaces and prefixes, which by and large confuse authors to no end. Just recently though I proposed something of a compromise which takes some of RDFa‘s better ideas and puts them into HTML 5, so hopefully that will take care of the main needs that caused people to invent RDFa. We’ll see.

About browsers

Do the browser makers have too much influence on the spec?

The reality is that the browser vendors have the ultimate veto on everything in the spec, since if they don’t implement it, the spec is nothing but a work of fiction. So they have a lot of influence—I don’t want to be writing fiction, I want to be writing a spec that documents the actual behaviour of browsers.

Whether that’s too much, I don’t know. Does gravity have too much influence on objects on earth? It’s just the way it is.

One of the chairs of the W3C working group is a Microsoft employee. Is that giving too much power to one browser vendor, or a good thing, given that Microsoft’s browsers still dominate and their buy-in on any spec is therefore essential?

Personally I would like Microsoft to get more involved with HTML 5. They’ve sent very little feedback over the years, far less than the other browser vendors. Even when asking them about their opinion on features they are implementing I rarely get any feedback. It’s very sad. If I e-mail them a question about how I can best help them, I usually get no reply; at best I’ll get a promise that they’ll get back to me, but that’s it.

Accessibility

There has been a lot of spirited debate (ahem) about accessibility in the development of HTML 5. How does the spec deal with the requirements of people with disabilities?

Universal access—the requirement that anyone be able to use information on the Web—is a fundamental cornerstone of HTML‘s design, just like security, privacy, and so on. In general, we try to design features so that they Just Work for everyone, regardless of how you are accessing the Web. For example, in HTML 5 we’ve added new input controls like calendars. These will Just Work with screen readers once browsers support them, authors don’t have to do anything special.

Does your personal support of humanitarian eugenics affect your opinion of giving extra "help" for people with disabilities?

You’ve been reading too much of our pet troll’s blog! ;-)

[Bruce's note: this refers to Mr Last Week, mysterious author of the blog Last Week in HTML 5, which lampoons the HTML 5 Working Group in very funny, frequently foul-mouthed manner.]

People with disabilities are just as important to me in my work on HTML 5 as is anyone else.

You wrote to ask screenreader vendors to participate in the specification process. Did they ever reply?

A couple did, but only to say they had little time for the standards process, which was quite disappointing. Since then, though, Apple has ramped up their efforts on their built-in Mac OS X screen reader software, and we do get a lot of feedback from Apple. So at least one screen reader vendor is actively involved.

HTML 5 and WAI-ARIA appear to do the same thing in some places. How should developers handle this?

When there’s a built-in way to do something, using that is the simplest and most reliable solution. So for example, if you want to have a checkbox, using the input element with its type attribute set to checkbox is the simplest solution—it’ll work for everyone, with or without JavaScript, with or without a screen reader, and so on. ARIA is useful when HTML doesn’t let you do what you want and you find yourself hacking around with many nested divs, scripting your own controls and so forth.

Can we expect ARIA-specific constructs which have no equivalent in HTML 5, such as live regions, to be allowed under the rules of HTML 5 so it will all validate?

Yes, the plan is to make sure ARIA and HTML5 work well together. Right now I’m waiting for ARIA to be complete (there are a number of last call comments that they haven’t yet replied to), and for the ARIA implementation rules to be clearer (it’s not yet obvious as I understand it what should happen when ARIA says a checkbox is a radio button, for instance). Once that is cleared up, I expect HTML 5 will give a list of conformance criteria saying where ARIA attributes can be used and saying how they should be implemented in browsers.

Why, when, how, who?

Why would we content authors want to move to HTML 5? What’s in it for us?

Today is probably too early to start using HTML 5.

Long term, content authors will find a variety of new features in HTML 5. We have a bunch of new structural elements like section, article, footer, and so on. We have new elements for embedded media, like video and audio. We have new input controls, like the calendars I mentioned, but also fields for URLs, e-mail addresses, telephone numbers, and for color selection. We have control over autocomplete values in text fields, as well as field validation so that you can say which fields are required. We have context menus, pushState() so you can update the URL in Ajax applications, and offline application cache manifests so that your users can take your applications offline. The list goes on.

There’s also the benefits that come from using an HTML 5 validator. HTML 5 is much more precise about many things than HTML 4, so the validators will be more useful in catching real errors. The embed element is no longer invalid.

Are there advantages for end-users, too?

A more powerful HTML means more powerful Web applications. Just like XMLHttpRequest resulted in more interactive apps, HTML 5 will result in a richer and more consistently reliable experience. I hope!

What’s the the timeline? When can we start using HTML 5?

The plan is to have the spec mostly finished by October 2009. A lot depends on the browser vendors, though. I don’t know when things will be implemented widely enough that authors can use them reliably everywhere. Some features, like canvas and video, are getting implemented in most browsers as we speak. Others will take longer.

What can standards-savvy WaSP readers do to get involved with the specification process?

There are a number of ways of taking part. What we need most of all these days is technical review of the specification text, calling out places where I screwed up, where the spec defines something that’s not easy to use for Web authors, where the spec contradicts itself, typos, spelling mistakes, grammar errors, errors in examples, you name it.

I posted a blog entry recently detailing how people can send feedback. You can join the W3C HTML Working Group or the WHATWG. There are also lots of other things people can do—write demos, write tutorials, edit other related specs, write articles introducing parts of the spec on the blog, write test cases… Anyone who wants to help out but doesn’t know where to start should drop me an e-mail at ian@hixie.ch.

Will there ever be an HTML 6, or is it a convenient fiction to park out-of-scope discussions?

I’m sure there will be an HTML 6, and 7, and 8, and probably many more, until someone comes up with something so radically better that we stop evolving the Web as we know it.

I expect work on HTML 6 will start even before HTML 5 is completely done, in fact. Putting the finishing touches on HTML 5 will be a long and tedious job involving writing a massive test suite. HTML 4 never had a serious test suite created (it was too vague as a specification to really be properly tested), so we have to start from scratch with HTML 5. The HTML 6 team will at least be able to build on what we’ve done with HTML 5, I’m jealous!

Actually if it was up to me, after HTML 5 I would probably transition HTML to an incremental model. Once we have a basic spec that is well-defined and has been proven, instead of releasing a frozen snapshot every few years, I’d prefer a model where we can slowly evolve the language, call it "HTML Current" or something, without having to worry about versioning it. To some extent that’s what we’re doing with HTML 5, but I think formalising it would really help.

Having versions of specs doesn’t make sense when you have multiple implementations that are all evolving as well. No browser is ever going to be exactly HTML 5, they’ll all be subsets or supersets. So why bother with versioning the spec?

It’s a very unusual idea in the standards world, so I don’t expect us to do this. But I do think it’d be the best way forward.

Would you like to be the HTML 6 editor?

Too early to tell! It’s been a lot of fun working on HTML 5, it’s quite challenging and you have to deal with all kinds of issues from the deeply technical to the highly political. I might want a change of pace when we’re done with HTML 5, though.

What’s your fave feature that didn’t get into HTML 5 that you’d put into HTML 6?

In-window modal dialogs or dialog box—the kind of prompt you get when the computer asks you a question and won’t let you do anything else until you answer the question. For instance, the window that comes up when you say "Save As…" is usually a modal dialog.

Right now people fake it with divs and complicated styles and script. It would be neat to just be able to say "make this section a modal dialog". Like showModalDialog(), but within the page instead of opening a new window with a new page.

I’d add it to HTML 5, but there are so many new features already that we need to wait for the browsers to catch up.

Finally, is it true that you and Mr Last Week are the same person, like Edward Norton and Brad Pitt in "Fight Club"?

Oh, no. Our pet troll is a phenomenon all to himself.

Thanks for your time.

• the death of hasLayout
• object fallbacks
• stylable legend elements
• generated content (including support for dynamic attribute insertion via attr())
• CSS counters
• support for the quotes property
• outline control
• data URIs
• full access to the style attribute via the DOM
• mutable DOM prototypes
• and much more

This browser is a giant leap forward for standards support at Microsoft, but reviews so far seem mixed. What do you think?

Today the Protocols and Formats Working Group of the W3C has announced the Last Call Working Draft for ARIA. This means that the working group believes that this specification is ready to advance to the next stage. We’ll leave the specifics of the W3C Process to the W3C. What you need to know is that you have until March 24, 2009 to provide feedback to the W3C on the working draft.

Accessibility Task Force member James Craig was involved as part of the Protocols and Formats Working Group that has been working on ARIA; many thanks to James for all of his work on this!

Our own Henny Swan (International Liaison Group Co-lead) has put together some questions about the ARIA spec to get you kick started.

Also of note — commentary and criticisms of Safari 4 Beta abound. Did you take a look at the top of the Safari 4 new features list?

Yes, that’s right. Accessibility, including ARIA.

This isn’t something that is years off. This is something that is happening right now, before your eyes and it is important work for the future of creating accessible web applications, so dig in and have a read and provide feedback — even the small things count!

These suggested that for government web sites, webmasters need not test in less popular browsers (those with less than 2% in that site’s usage statistics) and that there should be a page on the site listing the popular browsers which had been tested with the message “We advise you to upgrade your browser version as far as your computer allows and if possible to one of those listed above”.

I called on readers to email the consultation address and object that the guidelines did not advocate web standards and methodologies like progressive enhancement to ensure that all browsers were served. The Register carried the story, and two days after I made that call, the author of the guidelines, Adam Bailin, commented that over 400 people had already emailed him.

Last Friday, 16 January, Adam published the revised browser testing guidelines, and he’s done a great job of including best-practice development. The guidelines point to the BBC‘s support table as a good example of graded browser support, and notes the importance of supporting standards-compliant browsers (paragraphs 17-18):

Coding a site to web standards should ensure that any browser that supports web standards will render and behave as intended. Therefore your browser testing matrix must include browsers that support web standards.

You should follow a progressive enhancement approach to developing websites to ensure that content is accessible to the widest possible number of browsers.

The importance of valid code is noted (paragraphs 21-23):

All (X)HTML content must validate with respect to your chosen DTD.

You must use valid CSS for the presentational layer of your website including layout and styling. (X)HTML tables should only be used for presenting tables of data.

Code used for adding richness to the user interface (e.g. JavaScript, ActionScript) must be ECMAScript-compliant.

The guidelines now emphasise functionality over identical layout across browsers (paragraph 39):

You should check that the content, functionality and display all work as intended. There may be minor differences in the way that the website is displayed. The intent is not that it should be pixel perfect across browsers, but that a user of a particular browser does not notice anything appears wrong.

Graceful degradation without scripting/ plug-ins and accessibility are required (paragraphs 41-42)

You should also test your website to make sure that it works with scripting and plug-ins turned off.

Some users will be unable to use pointing devices so you should verify that the site works using a keyboard only.

I could be churlish and quibble about a couple of points in the document that I personally disagree with, but I won’t; the philosophical framework of the new Guidelines is a scalable, future-proof one that will properly serve taxpayers, web visitors and government webmasters in the UK.

I’d like to congratulate Adam Bailin and the team who revised the guidelines, and I’d like to congratulate every one of the 400+ readers who took the time and the trouble to write and support web standards.

It’s a job well done.

(Disclosure: I work for Opera, the browser vendor, and wrote the Opera consultation response).

WCAG 2

Shawn Henry writes of WCAG 2,

Over the last few months, the Web Content Accessibility Guidelines (WCAG) Working Group has been going through a process to ensure that WCAG 2.0 can be implemented. Developers and dsigners from around the world gave WCAG 2.0 a “test drive” in their own Web content.

The result: Successful implementations in a wide range of sites including education, commerce, government, and a blog; in languages including Japanese, German, English, and French; and using a wide range of technologies including scripting, multimedia, Flash, and WAI-ARIA. You can get the nitty-gritty details from the Implementation Report.

It’s possible that WCAG 2 could be the new accessibility standard by Christmas. What does that mean for you? The answer: it depends. If your approach to accessibility has been one of guidelines and ticking against checkpoints, you’ll need some reworking your test plans as the priorities, checkpoints and surrounding structures have changed from WCAG 1. But if your site was developed with an eye to real accessibility for real people rather than as a compliance issue, you should find that there is little difference.

mobileOK Basic Tests

I’ve mentioned this largely so you don’t have the same worries with them that I did. Crudely speaking, they’re an automated test that a site will be OK on a very low-spec mobile mobile device called the “Default Delivery Context” (DDC) so there are certain rules in the validator such as a page cannot be larger than 20K. This caused me some degree of tizzy, until I read the caveats at the top of the specicaton:

mobileOK Basic primarily assesses basic usability, efficiency and interoperability. It does not address the important goal of assessing whether users of more advanced devices enjoy a richer user experience than is possible using the DDC.

…The Best Practices, and hence the tests, are not promoted as guidance for achieving the optimal user experience. The capabilities of many devices exceed those defined by the DDC. It will often be possible, and generally desirable, to provide an experience designed to take advantage of the extra capabilities.

So my advice: make your pages as long as the content requires, no longer or shorter. Use the images that the content and design needs, and let the user decide whether he or she wishes to accept your images. Make sure all images that convey information have explanatory alternative text for those who can’t consume your images.

Now that sounds familiar…

What exactly does it mean to pass the Acid3 test?

There has been some confusion about the test and its importance. Some people have been saying things like ”my browser does not pass the test and I have no problems using it”. Quite a few other people seem to think that Webkit and Gogi (Opera’s internal build) passed the test already in March – despite the fact that neither team has made this claim.

To answer these misconceptions we need to address the issue of what exactly is being tested and how. The main part of test is automated through JavaScript, a sort of test harness that runs 100 subtests. Getting a score of 100 is not the same as passing Acid3 – a common misconception, or perhaps an oversimplification.

Many subtests are high on a developer’s wish list: Full CSS 3 selectors support, media queries, SVG fonts. Admittedly a few others test edge cases and more esoteric features – but the test was supposed to be a significant challenge!

The second part is a rendering test. Some of the scripted subtests produce results that affect the rendering, but there are also rendering issues that come in addition to these. Some of them are high on many designers’ wish list: Text shadow, downloadable fonts, and display: inline-block.

The third test is the so called “smoothness” criterion. It is basically a speed test. No subtest may take too long – and especially subtest 26 is challenging. Compared to Slickspeed, Sun Spider, the V8 test suite or Dromaeo Acid3 is not so thorough. It will give some indication of a browsers speed, though.

This is exactly as planned. Acid3 was not meant to be the one and only indication of a browser’s performance. In fact many other test suites are far more important. (We provide links to some of them below.)

Testing is really important. Without tests that check how well a certain browser follows standards, i.e. applies mark up and displays the result correctly, we can never guarantee an open, fully interoperable web.

A highly visible test like Acid 3 hopefully helps to promote such interoperability. One can also hope that all the other tests will receive the attention they deserve. Writing them is not a glamorous task, but highly essential.

Apart from improving its support for CSS in its browser, Microsoft has contributed 2524 test cases to the CSS 2.1 test suite. For that they deserve credit!

We all know that Internet Explorer currently lag a bit behind the other browsers in standards compliance. Indeed they are last of the big ones to pass Acid2 and they fail Acid3 more than any other browser. But can we declare Webkit as the best rendering engine now that they pass it?

Of course not. Since Acid3 is only one indicator of many. Webkit’s achievement is great – and there are many other really exciting things they are pioneering, like CSS transitions and transformations. And with Squirrelfish Extreme JavaScript performance looks really exciting as well.

In other regards Opera is a clear leader. It is the only browser that supports more than 90 % of the SVG test suite. It is the only browser that implements Web Forms 2.0, currently being merged into HTML 5. They supported media queries and SMIL long before Acid3 came out.

Gecko (with Spidermonkey) is no longer an underdog. Besides the fun of meeting the technical challenge it is not hard to guess that the Webkit team rushed to pass Acid3 also for marketing reasons – that they perhaps need a bit more than Mozilla. Mozilla concentrated on releasing Firefox 3 before Acid 3 received any real attention. Now that they are working on it they are impressive in another way, compared to Webkit. Looking at the discussions for bug 410460 and its related bugs, it is clear that any improvement must be rock solid. Work often continues even when a particular feature is good enough for Acid3.

In fact, there is actually one open issue still in Acid 3 that might temporarily cause Webkit to become incompliant again. http://lists.w3.org/Archives/Public/www-style/2008Sep/0218.html. I rest assured that a fix probably already is being made, though.

Perhaps one can compare this to a race where you are supposed to run a distance, with a bucket of water. One competitor crosses the finishing line first, the other, on the other hand, has not lost a single drop from his bucket. Both have done great. (By the way, internal builds of Firefox get a score of 97 now, and downloadable fonts work on Windows and Mac.)

In the end the winner is neither Webkit, Opera, Mozilla nor Microsoft, but developers who get more powerful features to work with and more consistency between browsers. And that means that in the long run they are able to focus on user experience, not browser shortcomings. This means that the true winner of Acid3 is anybody who surfs the web.

Some other test suites for your review:

• Cascading Style Sheets level 2 revision 1
• Selectors
• CSS Color Module
• Collection of DOM tests
• SVG
• Web Forms
• Canvas