IE8

[blufive]

So, it turns out I was wrong about Microsoft's IE8 standards-mode rendering switch - they're proposing that web authors use either a meta element or an HTTP header as an opt-in.

My initial gut reaction: wow, that sucks.

This was announced with simultaneous posts on respected web-guru magazine and th e Web Standards Project by Aaron Gustafson, a member of the WSP Microsoft Taskforce. There was also a companion piece on ALA by Eric Meyer, another guru-level figure, in which he appeared to indicate tentative support (of which, more later).

There was a short pause, then the web-dev community went Ka-boom! Those initial announcements generated a lot of, um, vigorous debate. It often got pretty vitriolic. Shortly afterwards, a WSP co-group leader posted, clarifying that Gustafson was posting only as a member of the WSP Microsoft Task Force and not speaking for the WSP as a whole. Cue somewhat heated comment threads involving a who's who of web standards over who did what to whom.

Here are some of the more reasoned and non-insulting comments by qualified people (I've noted affiliations with rival browser makers where appropriate)

• Jeffrey Zeldman (General Web Standards Guru, WSP member, proprietor of A List Apart)
• Three follow up posts from Eric Meyer (Formerly Netscape (during the Mozilla years) Invited Expert to the CSS2 Working Group, generally acknowledged CSS guru). I'd recommend the third of those, in particular, as it provides an excellent summary of how this argument looks from the browser-developer's point of view.
• Robert O'Callahan (Mozilla, rendering engine programmer who knows way more about web page layout than most of the web authors you've ever met put together). Further follow-ups here and here.
• L. David Baron, (Mozilla, ditto). Follow up.
• Ian Hickson (Google, formerly Opera, editor of the HTML5 and CSS2.1 specs, plus various bits of CSS3)
• John Resig (Mozilla, creator of JQuery, formerly an independent Javascript Guru)
• Maciej Stachowiak (Apple)

My distilled summary of those luminaries' comments (with apologies if I end up misrepresenting anyone):

• This is a can of worms for other browser makers, potentially making it orders-of-magnitude harder to comply with users' expectations of how any given page should render.
• this could make it much harder for new browser rendering engines to enter the marketplace. (Microsoft, do something anti-competitive? Never.)
• It threatens to explicitly lock large chunks of the web into IE7 compatibility for long periods, creating a ball-and-chain for the whole browser and web development community.
• Other browser developers are looking rather unlikely to join in on supporting this approach
• Eric Meyer clarifies his position, saying that while he agrees that using meta tags is an improvement on previous switching mechanisms (doctypes, conditional comments, javascript sniffing) he thinks that it should be opt-in, not opt-out, i.e. the default behaviour should be standards-based rendering, rather than emulating old browsers.

Now, my more detailed/reasoned thoughts. Headline: This sucks in various subtle, evil and long-term ways.

Who wins? There are several interested parties here (list inspired by a comment I saw somewhere in the first wave of the hoo-hah, but can't find now)

Microsoft PR/Support (MSPR)

The people who have to deal with the shitstorm when a new browser version shags websites

IE development team

who have to develop/maintain IE

Legacy Intranets

Understaffed operators of legacy intranet applications, who have to cope with their corporations upgrading the web browser on the 47 gazillion workstations that access the app)

Other browser developers

MS's competitors, both current and future, who develop/maintain other browsers, and have their own particular version of the shagged-website-shitstorm, which involves the added excitement of matching user expectations moulded by IE.

Ignorant Web Developers

Web authors who don't give a flying wotsit about standards, who just want their site to work for whatever group of users they have to pay attention to, which may be countable on the fingers of one or two hands)

Overworked Standardistas

Standards-supporting web authors who are severely constrained by a bad maintenance workload/developer resource ratio, who have to try to write forward- and backward-compatible cross-browser websites without changing a bajillion files and pushing the ensuing monster release though a testing/staging/release cycle every time a new major browser gets released.

Standards ninjas

Standards-supporting web authors who don't have significant problem with maintenance workload for whatever reason, e.g. they're prepared to let their sites break in dodgy browsers, or they are sufficiently well-organised/resourced for the changes to be easy to make.

(Aside the first: many of these categories are illustrative stereotypes; there will be people who straddle multiple labels, or are off on their own planet somewhere. I count myself as an overworked standardista)

In my opinion, MS based their decision primarily on the short-term interests of MSPR (who don't get the shitstorm), Legacy Intranets (who can let their corporation upgrade without shafting their intranet, then upgrade the app at their leisure, if at all), Ignorant web developers (who remain blissfully unaware) and maybe the overworked standardistas (same as Intranets).

(Aside the second: this feeds my barely-formed-bollocks-theory that large parts of Microsoft-the-applications-company, strategically, has been totally captured by the large corporates with installed bases of several thousand workstations, who have the power to meet face-to-face with upper-middle-level MS sales/management people and threaten them with the removal of 7-digit-per-annum cashflow)

The Standards Ninjas have to choose whether or not to use the meta tag, but it's not a monster change for them if they decide to go ahead.

Many of the standardistas (even the overworked ones) probably aren't that happy about this, though, because their sites may well just work in the new IE8 mode without any real changes. If they've done IE-specific hacks properly, they've done them such that an unknown browser (including IE8) will be presumed standards compliant until proven otherwise. All this is doing is putting another hurdle in their way before they get the pay-off on all the work they've already done.

The IE Developers get clobbered, because they're basically going to have to ship two rendering engines in one box - the "old" IE7 and the "new" IE8 - or put major amounts of special-case code in (which is bad, take my word for it). Theoretically, this could be a one-off step-change, and we won't have to go through it all again with IE9; in practice, the whole structure of the flag indicates that this may not be the case, and a future version of IE could easily do it all again.

Other browser developers also get clobbered, because they are forced to emulate the market leader, to a greater or lesser degree, or suffer the broken-sites-shitstorm. So they have to ship multiple engines too (except, they won't - they've pretty much all lined up on the "no way!" side of the discussion).

My main problems are with the signals this sends, and the long-term effects on the web at large.

First, the signals: this effectively tells all the people working hard to produce high-quality cross-browser code that Microsoft is happy to make them jump through hoops to make their sites work in IE8, but people who can't be bothered to learn to do their job properly (the ignorant web developers) get a free pass. To borrow a phrase much tossed about by financial regulators recently in the UK: this creates a moral hazard. The people who are working hard to Do The Right Thing get slapped in the face and forced to do even more work, but the people who are doing a shoddy job get let off the hook without any penalty. Remind me why we're supposed to do things The Right Way, again?

The long-term effect of this is straightforward: this creates enormous inertia which will encourage many web developers to stay on the IE7 rendering model for a very long time. Those web developers will write loads of pages that will be around even longer after that, forcing this same decision to get re-enacted every time there's a new browser version anywhere. This isn't a fix, it's just postponing the problem, passing the buck to your successors.

This "browser inertia" problem has existed since way back. Just ask the web developers who remember when Netscape 4.x ruled the world. The thing is, in the past, the "inertia" has always been tied to this or that browser version. Once the problematic browser version finally goes away (as NN4.x thankfully did a few years ago) the inertia goes away with it.

The difference here is that this new system decouples the "legacy" support from the actual usage of the legacy browser. It creates the situation where we could have 80% of users on IE8 or higher, with only 2% on IE7, but web browsers still need to keep parity with IE7 to avoid breaking all the "IE7-compatible" sites. This effectively removes any incentive for the "old" sites to upgrade. IMO, this threatens to stall the development of the web for as long as any browser implementing this stuff is the dominant market player. (Yes, the previous statement suggests one way out of this mess, which may well come to fruition sooner rather than later - there are countries in Europe where Firefox has a market share of well over 30%, and rising - us Brits are laggards at a mere 15% or so).

(Aside again: I think it's at least arguable that the trigger for the great Web 2.0/AJAX functionality leap of the last couple of years was at least partially due to all the relevant web authors thinking "oh, thank $DEITY! IE4/NN4 are dead! Now I can finally start playing with all this cool new stuff that IE5 introduced without worrying about trying to make it work in those fossils.")

The cynics may imply that this is deliberate policy to stifle the development of the web, creating an opportunity for the "rich web application" frameworks (like MS's own Silverlight or Adobe's AIR) to leap into the functionality gap beyond AJAX/Web 2.0, by holding HTML5 and its ilk back. Go read the MS vs DOJ Findings Of Fact for the background on why MS might want to do that. Summary: if people's productivity apps move off the desktop and onto the web, people are no longer tied to windows, and MS lose the Windows Tax. Personally, I reckon the primary driver really is the far more short-sighted "defuse the broken websites shitstorm", though they might regard nobbling one of Silverlight's major competitors before the race even starts as a nice-to-have side-effect.

I think that this perception of old sites holding the browsers back is somewhat misplaced. I'm pretty sure that most of those "legacy" sites are piles of crud emanating from the Ignorant web developers, or even full-blown orphaned sites (i.e. no longer maintained in any meaningful way). Many of them are probably coded such that they're going to be in quirks mode anyhow, and probably look rubbish even there. In fact, I bet many of them have always looked crap in whatever browser you use (or all browsers bar the one they were tested in - if you're lucky, it'll be one modern enough that lots of people are still using it).

Pretty much all those sites either "work" in quirks mode already, in which case they're going to keep working in the new quirks mode, or they're already stuffed, and none of this is going to make any difference.

Now, the bit that really gets me. What MS is proposing is this damn close to being a semi-decent solution. Meta/Http headers are a passable switch mechanism. The only change I'd really want is that suggested by Eric Meyer and many others: swap the default. The current proposal is totally backwards. Go to standards mode first (unless the page is obviously b0rked, like standards mode currently works). Use the switch to flip back to IE7 compatibility mode

At a stroke, that makes all the standardistas and the intranets happy (or at least happier). At most, the overworked standardistas and the intranets only need to make a small change to get "compatibility" with IE8. If they want, they can even do it at the webserver level (using the HTTP header) rather than updating all the individual pages. The Standardistas, if they've been cunning in the past and/or good at their jobs, with a dash of luck thrown in, probably don't even need to do that; their sites should just work in uber-standards mode anyway.

It also makes the Ignorant Web Authors happier than doing nothing - their sites may break, but they've got a simple "fix" to apply, which may even encourage them to do a bit more research into how to do things properly. Though, again, most of them are probably in quirks mode anyway, so this whole discussion is probably moot for them. Worst case scenario: it creates them one more round of run-around-and-fix-everything-while-cursing-Microsoft, but after that, all the leading browsers are in the same ballpark. Browser compatibility testing gets way easier for everyone, the IWAs included. Most of the cross-browser issues end up in obscure little corners where most authors (especially this crowd) rarely wander, or out on the bleeding-new-technology edge (again, most of the IWAs don't go there).

Reversing the default also removes the moral hazard; the incentive remains (as it currently is) to learn to do it properly, and produce a single set of code that works on all browsers, saving yourself work in the long run. Many people won't do so, but once they're doing their prime testing in IE8 (ETA: 1.5 years after they release it, so probably ~2.5-3 years from now) then, from their perspective, all the major browsers do much the same thing, and most of the problem goes away.

So: flip the default around, and this is a good idea. Otherwise, it sucks.

Finally, a word from the lemurs.

Comments

[richc.livejournal.com]

I'd pretty much agree with that with one additional thing that I'd like to see. It needs to be very easy to tell which rendering mode the page is using. It's really annoying to spend ages trying to fix something that was caused by a simple typo swapping the rendering mode.

[stsquad.livejournal.com]

Doesn't the DOCTYPE specify how compatible you are? I mean if you serve up a DOCTYPE that says you should meet a certain validated criteria isn't that enough to say render it in standards based mode?

[blufive.livejournal.com]

That's the way every other multi-rendering-mode browser works, yes. Not good enough for IE8, apparently.

The rationale is that, since all the other browsers (including IE6/7) started doing it that way, even the IWA's (or their tools, on their behalf) started putting DOCTYPEs everywhere, which means it's allegedly not a guarantee any more.

I don't agree with that, but, that's their argument.

IIRC, most other browsers, even with a doctype in place, flip out of standards mode when they hit egregiously bad markup - horribly mis-nested tags, three body elements, that sort of thing.