In the wake of the blog reactions to IE engine version targeting, Eric Meyer blogged about the story behind the Almost Standards Mode in Gecko portraying it as precedent. I think engine version targeting and the almost standards mode are substantially different and, moreover, in hindsight we would have been better off without the Almost Standards Mode. Therefore, I think the history with the Almost Standards Mode shouldn’t be used as precedent that justifies engine version targeting.
In 2000, after Mac IE 5 was published with the doctype switch, I realized that Mac IE 5 had a way of triggering its standards mode for Transitional doctypes while the development versions of Mozilla didn’t. It seemed clear to me that the most cutting-edge Web authors would want trigger the standards mode in Netscape 6 in order to use CSS properly but would also want to use deprecated attributes in HTML in order to degrade gracefully in legacy browsers.
The conclusion I drew was that if Netscape shipped Mozilla as it were then, authors would use a Strict doctype with Transitional markup and this would make authors disrespect validation and that would have been just horrible. Therefore, I filed a bug suggesting that Mozilla adopt the same behavior with Transitional doctypes as Mac IE 5: quirks without system id and standards with system id. (I have since adjusted my views on validation.)
There was a problem though: Mozilla’s Standards mode (unlike Mac IE 5’s Standards mode) broke layouts that had image slices in table cells and there was one top site that used such a layout with a Transitional doctype with a system id. The site was apple.com. The Netscape Product Delivery Team didn’t want to break the Apple front page.
To make the long story short, this was the solution: Triggering the standards mode for HTML 4.01 Transitional with system id (like Mac IE 5) but (unlike Mac IE 5) not triggering it for the doctype used on the Apple front page at the time—HTML 4.0 Transitional. (The Wayback machine seems to edit the doctype.) And this is why the big doctype table has a weird quirky dent at HTML 4.0 Transitional with system id.
Two years later, when the Almost Standards Mode was introduced as recounted by Eric, the HTML 4.0 Transitional with system id case was not upgraded to Almost Standards Mode and continues to trigger the Quirks Mode in Gecko.
Developer.apple.com broke and was handled through upgrade evangelism.
So I’ve been there too, but I still think IE version targeting is different. Here’s why:
In Gecko, WebKit and Presto, there’s a handful of conditional quirks. While WebKit and Presto have had to imitate Gecko quirks mode, the Gecko quirks are mostly documented and few enough not to create lock-in or impose undue burden on other implementors imitating the quirks.
Netscape 6 did not ship with a frozen Netscape 4 in it. And Netscape 7 didn’t ship with a frozen Netscape 6 in it. Having a few conditional quirks as a one-time solution is very, very different from adding a whole frozen engine in each major release.
Back when the Quirks Mode and the Almost Standards Mode were introduced, the way people thought about the relationship of existing content, Web developers, browsers and specifications was very different from what it is now.
Back then, committees created specs and that were enshrined as W3C Recommendations before there was solid implementation experience. Then the Web Standards Project lobbied browser-makers to implement the W3C specs as they were. The mindset was that the specs given from above couldn’t and shouldn’t change. People thought that vigorous upgrade evangelism would work and make Web authors change their existing sites.
The design principles that drive HTML5 today weren’t part of the
mindset back then. For example, it didn’t occur to me back then
that perhaps the specs should change to match the pre-existing
implementation practice on comment
parsing, the effect of <table> when a <p>
is open and the parsing of unitless CSS lengths. (It did occur to me
to question the Standards mode behavior of images in tables, though.
It was and is so hard to explain with a straight face to friends who
create Web sites.)
Things are now different from what they were in 2000 or 2002. For example, CSS2 has been reopened as CSS 2.1 that isn’t yet REC-worthy. The issue of images in tables was and continues to be much bigger a deal than the examples from the last paragraph. It doesn’t really matter if one thinks layout tables are good or bad. They are out there and that’s the way existing content is. In the light of today’s HTML5 design principles, CSS2 failed to Support Existing Content with its default behavior. And that’s a bug in CSS2.
Now, I do agree that the CSS2 behavior makes sense for laying out tabular textual data. To allow that behavior and to avoid breaking existing content, in hindsight, introducing a new engine mode wasn’t the best solution. It would have been better to make a CSS property for toggling table cell shrink-wrapping and making the property default to legacy-compatible behavior.
Given that the Almost Standards Mode is not the best solution that can be thought of today and that version targeting is substantially different from Gecko modes, I think the Almost Standards Mode should not be used as precedent justifying engine version targeting.
As I understand it, there are two major problems that IE faces when launching a better engine:
Intranet apps written exclusively for old IE.
Sites on the public Web assuming that IE is always has certain quirks.
David Baron suggested a way to address the first problem: maintaining an old IE engine for intranet customers and letting IT admins select what servers it is used with. Maintaining only one legacy engine (e.g. IE 5.5 aka. the current IE7 quirks mode) and for intranets only is better than having sites on the public Web lock into a particular engine versions.
For the second problem the solution seems to be building feature parity with Firefox, Safari and Opera and then minting a new User-Agent string without the substring “MSIE” to break free of old expectations.