I have to say, by the way, that the relevant parts of the SVG spec are truly worthless. Where are the UA conformance criteria? You'd think a spec that was so verbose and detailed would actually tell you stuff, instead of just rambling on without actually saying what the requirements were...

Just as Reddit is celebrating Opera reaching 100/100, with the misleading headline Opera the first browser to pass the Acid3 test (hey, submitter: it wouldn't hurt to read the Opera blog post before submitting it to Reddit), the Apple guys track me down and point out that there's yet another bug in the test. With heycam's help, we have now fixed the test . Again. This presumably means Opera is now at 99/100... the race continues!

When we released Acid2, the first browser passed it in about a fortnight. Acid3 is orders of magnitude more complicated. I really didn't expect to see passing browsers this side of August, let alone within a month. I am really impressed by the level of commitment to standards that Opera and the WebKit team (and Apple in particular) are showing here.

Of course, with a test as complex as this one, I was bound to make some mistakes, which the browser vendors were very quick to tell me about. Sometimes they were mistaken, and the test was actually correct; other times I was wrong, and had to fix the test, and in one case, the spec changed.

Since we announced the Acid3 test a few short weeks ago, two major browser vendors have been tripping over themselves trying to pass the test, with both Opera and Safari getting very close in the last few hours.

Meanwhile, HTML5 continues to make good progress. I have a page now which shows my progress in replying to e-mails , and as you can see from the changelog tracker , checkins are as fast and furious as ever.

Speaking of standards, and of good news from browser development teams, Microsoft's IE team announced today that they were changing their mind about their mode switch, and that bug fixes they make to their rendering engine will be applied to pages in what HTML5 calls "no-quirks" mode (what has historically been known as "standards mode"). I'd like to congratulate the IE team on this brave decision. It's the right thing for the Web.

I have to say straight up that I've been really impressed with the WebKit team. Even before the test was finished, they were actively following up every single bug the test showed. Safari 3 (the last released version) scores 39/100 with bad rendering errors. At the start of last month their nightly builds were scoring about 60/100 with serious rendering errors. Now barely a month later the nightly builds are already up to 87/100 and most of the rendering errors are fixed. That's a serious testament to their commitment to standards. (Also, I have to say, it was quite difficult to find standards compliance bugs in WebKit to use in the test. I had to go the extra mile to get WebKit to score low! This was not the case with most of the other browsers.)

After baking it for several weeks, we have finally decided Acid3 is stable enough to announce it is ready . We'll be working on a guide and other commentary in the coming weeks and months, but it'll take a while — Acid3 is far more complex than Acid2 was.

There were several announcements yesterday.

First: The W3C finally got around to publishing one of the drafts of the HTML5 spec as a "first public working draft" (a misnomer if ever there was one, given the history of HTML5). This is news for one reason and one reason only: it starts the W3C patent policy clock, which means that within a few months we will know if any of the browser vendors have patents they wish to use to block progress on the Web. Still, a step forwards.

Second: The syntax for Microsoft's plans for yet another quirks mode switch in IE8 were announced. Basically they are offering authors the option to pick a specific set of bugs, defaulting to IE7's. The idea is that with each new major IE version, they can decide to simply freeze their last set of bugs forever.

If Web authors actually use this feature, and if IE doesn't keep losing market share, then eventually this will cause serious problems for IE's competitors — instead of just having to contend with reverse-engineering IE's quirks mode and making the specs compatible with IE's standards mode, the other browser vendors are going to have to reverse engineer every major IE browser version, and end up implementing these same bug modes themselves. It might actually be quite an effective way of dramatically increasing the costs of entering or competing in the browser market. (This is what we call "anti-competitive", or "evil".)

It will also increase the complexity of authoring by an order of magnitude. Big sites will become locked in to particular IE version numbers, unable to upgrade their content for fear of it breaking. Imagine in 18 years — only twice the current lifetime of the Web! — designers will not have to learn just HTML, they'll have to learn 4, 5, maybe 10 different versions of HTML, DOM, CSS, and JS, just to be able to maintain the various different pages that people have written, as they move from job to job.

I mentioned all this on public-html last April, pointing out that if Microsoft was really interested in not breaking the Web they would instead send technical comments on the HTML5 spec, explaining what exactly the spec requires that is incompatible with deployed content. (Microsoft have yet to send any technical feedback on HTML5 at all, 8 months later.)

I've been shocked to see several people in the industry supporting this move, including people whom I have met personally and whom I know know better, but I'm in no position to criticise people who should have known better. I'm glad to see that at least people from Opera, from Mozilla (continued), from Webkit, and even from the WaSP, and from the community as a whole (if the comments on Slashdot and other sites are representative) see this for what it is.

There are several directions we can go in from here. We could prematurely claim that our pages want IE8's new quirks mode, which would likely cause pages to change rendering in IE8 as compared to IE7. However, that's mostly a futile exercise, as either few people will do this, and it won't matter, or a lot of people will do this, and Microsoft will just change the syntax before IE8 comes out.

We could use the "edge" feature that is apparently being provided to always trigger the latest mode. However, that would be even worse: if enough people use this feature, then Microsoft will feel compelled to just make "edge" equivalent to "IE8" and introduce a new way to trigger the "latest" mode.

This is what happened with the original DOCTYPE-switched "standards mode": many people wanted their pages to use the latest standards, but found that they ran into bugs in IE6, so they worked around those bugs with hacks — which relied on simple parsing bugs — to pass content specifically to IE6. With IE7, many of the simple parsing bugs that these hacks relied on were fixed, but the bigger underlying problems that the hacks were working around weren't. The pages thus broke in IE7. Microsoft's reaction was to make "standards mode" mean "IE7" mode, and to introduce a new mode ("IE8"). The same will happen if so many people use "edge" that a significant number of pages break in IE8 or IE9.

We could encourage everyone to actually use this feature, but actually then we're just contributing to making the syntax legitimate, and we end up fragmenting the Web, on Microsoft's terms. This is possibly the worst outcome.

Finally, we could just ignore the feature altogether, continuing to use JS compatibility libraries for the time being, the same way that everyone has been doing for years. Authors would also have to support IE7 anyway, at least for the forseeable future, so it wouldn't be an additional cost. This would make the experience on IE worse than on other browsers, but not so much worse as to turn users away from the sites themselves. Microsoft would find themselves having to support a number of rendering modes that were not being used, which is not a cost-effective measure; they would find their market share eroding, as customers switched to browsers that actually followed standards; and they would find their developers still asking for standards compliance that was actually compliant to the specs and interoperable with other browsers.

Therefore I recommend not including the meta tag, or, if you are forced to include it, making sure it says "IE=7", even once IE8 ships. This seems to me to be the best way to show your support for an open, interoperable Web on the long term.

It will be interesting to see whether IE8 really supports Acid2, since that test page doesn't include any of the special magic words being proposed here. Will they hard-code the URI? Will they check every page against a fingerprint and if it matches the fingerprint of the Acid2 page, trigger the IE8 quirks mode instead of the IE7 quirks mode?

Third: Well, not really an announcement, but Sjoerd Visscher pointed out something that for some reason I had never heard of, and which nobody I have spoken to about it since has ever heard of: using document.createElement() with the tag name of an unknown tag causes IE7's HTML parser to start parsing that tag differently. This piece of information makes building an HTML5 compatibility shim for IE7 far easier than had previously been assumed. This is probably the most noteworthy news of the day. I don't really know why I didn't know this before.

Pingbacks: 1 2 3 4 5 6 7 8 9 10 11