X-UA-Incompatible

If you can't stand any more X-UA-Compatible debate, apologies for fuelling it. It's just that several people arguing for the merits of the proposal – including very high profile supporters like Eric Meyer and PPK assume that the versioning META tag won't affect other browsers. The theory goes that Opera, Mozilla, Safari, Konqueror, iCab et al will keep doing whatever they are doing and only IE8, 9, 10 will have to add multiple modes.

This assumption is WRONG, WRONG, WRONG.

Opera had to follow Mozilla and add an almost-standards mode (which wasn't so bad actually since Eric and Mozilla defined very clearly what the mode was about). If META X-UA-Compatible gets used on the web, we WILL encounter pages that apply CSS meant for a very specific quirk in IE8, and we will have to do something about it. And if Microsoft has taken this shortcut without documenting the IE6/7/8/9 quirks it covers, we're left to figure that out with time-consuming testing. The cost of being compatible is again placed on IE's competitors.

Today at least the HTML standard is being actively developed. CSS development is less open so I don't know what happens – if anything at all – but we have a situation where Microsoft could use fresh implementation experience to improve the specs, tell us what is compatible with the web and what isn't.

A small story to show what I mean by that: the CSS "display" property used to have the values "none", "inline" and "block" (maybe others, I'll simplify). At some point the CSS group decided to also add values like table-row and table-cell.

The problem was those styles also worked "in reverse", so a "TD style='display:block'" would not be a table cell anymore – it would become a block element, and thus mess up most of the table it was a part of! And because several important existing sites were hiding TDs or TRs by setting style.display='none' and showing them again by setting display back to 'block', Opera ran into serious problems. Sites like allmusic.com broke in very ugly ways. (Besides, they weren't exactly quick to fix it when we pointed it out to them..)

In this situation, it would have been sweet to be able to go back to the working group and say: "look, we had some problems supporting this spec-in-progress, could you consider changing 'display: table-row' to for example 'table-display: row'?" What if Mozilla instead of implementing almost-standards-mode could have discussed whether the standard could resolve the dilemma?

Microsoft has this window of opportunity with HTML5. It probably has it with CSS3. So please join the collaboration – detail by detail – instead of ramming a maddening number of X-UA-Compatible modes down our throats.

Advertisements

9 thoughts on “X-UA-Incompatible

  1. Firstly: I do want everyone to win. I understand the IE team's technical dilemma very well – since we've been there, broken that and often need elegant but crazy hacks to improve web compatibility.The infamous glacial speed of standards development could be a feature if it improved the end result (e.g. made it more web-compatible) ;). The political in-fighting in standards groups (not seen first-hand since I'm not much involved with W3C stuff but I have no reason do disbelieve your description of anti-Microsoftism causing valid concerns and technical solutions being thrown out) is sadly a reality bug, and I don't know how to fix it 😦 . I hope Hixie can.. :p

  2. There really is no way for any of us to win this, is there? And I don't mean "us who support the idea" or "us who are committed to advancing standards"– I mean ALL of us, no matter where we stand.Your concerns are totally valid. I could ask whether your view would change if Microsoft would offer to share full documentation with other browser makers, but let's be real: they almost certainly wouldn't, even if the IE team wanted to do so. So we have to assume that IE doing this pushes work on its competitors.The argument that old sites should just break in newer browsers seems only to be applied to Microsoft, though. In other words, very few people seem to think it's okay to have Microsoft do its targeting thing and have other browsers hew to the line of letting old sites break as they advance. And I get why that is, or at least think I do.So they can either cut everyone else's throat by doing this, or cut their own throat by not doing it. When deciding on throat-cutting, of course, it's a rare situation where one's own throat is chosen. I can think of only a few, and none of them involve competitors.I do have to chuckle over the fact that your story about 'display' just about perfectly illustrates why version targeting is generally a good idea, right down to the intransigence of site developers. Unfortunately, I think your proposed solution is indeed sweet but totally unrealistic.Getting a standard changed to solve implementation problems is a no-go. The W3C already operates on near-glacial time scales. The impact of raising implementation (or practice) problems and then convincing a WG to change its specification to match would be even more catastrophic, not to mention likely futile. Every time I try to picture a W3C WG agreeing that it should alter defined behavior to match a vendor's implementation or user practice (or both), I fail. And I triply fail when the vendor in question is Microsoft.It's the perfect Kobayashi Maru situation, only here, I'm becoming fairly convinced there's no way to reprogram the test in order to win. It's starting to look more like the best we can find for is WOPR's conclusion: that the only way to win is not to play.

  3. Originally posted by emeyer:

    I do have to chuckle over the fact that your story about 'display' just about perfectly illustrates why version targeting is generally a good idea

    So.. you target browser versions instead of browsers? 🙂

  4. Steen wrote:"If META X-UA-Compatible gets used on the web, we WILL encounter pages that apply CSS meant for a very specific quirk in IE8, and we will have to do something about it."I am somewhat confused. This would not be an issue, I am presuming, if a CSS IE8 specific quirk was managed via a conditional comment style sheet, correct?Again, presumption is made by me, that a lot of Web content would need to be designed exclusively for IE8 for other browser vendors to worry of such a possible CSS quirk. With all of the issues and problems learned from such a practice for IE6, why would anyone cognizant of best practices design exclusively for a specific browser version?In that same vein, why would a competent CMS develop an application that targets one browser version, only?Sidebar: Hell, I would be happy if blogs all used and allowed the same HTML markup for comment posting.Thanks.

  5. The argument that old sites should just break in newer browsers seems only to be applied to Microsoft, though.

    Eric, I don't know where you see me saying that old sites "should" break in new IEs.. Opera has been the first implementor of WebForms2, we have suffered serious incompatibilities and problems because of this and we feed information and experience back to the WHATWG and the HTML working group to make the spec work better with the content out there. That's the sort of path I'd wish the IE team would follow. It would create detailed documentation on quirks and issues, implementation guidance and improved specs. It doesn't mean they have to release final public versions with half the sites out there broken, some public betas and implementation experience fed back to the working group would go a long way.The holy grail is of course a spec that enhances the web without breaking it. Chris Wilson is right that HTML5 isn't currently such a spec, the question is to what extent it could be one.

  6. thacker: quirks happen. I know pages that work because IE breaks the standard one way and Firefox another and they happen to trigger the "right" bugs in both! Don't ask me how they managed to get into such a state.. And it only takes one popular site with X-UA-Compatible=IE8 that thinks "this browser is not Firefox so it must be IE" and serves us CSS that is meant to generate a specific effect in IE's IE8 mode – and we need to add our own quirky and underspecified approximation of an "IE8 mode". It won't be exactly like IE8 because it would take years of research to get it perfect – and that will in itself cause bugs..

  7. How is meta x-ua-compatible going to get used? I think it would be more like "x-ua-tested-with", with the implicit demand that any visiting user agent had better render exactly like one of the listed uas or else! And it defaults to IE7 too!Microsoft's problem is that they have what amounts to two different customers: the web browsing public at large, and corporate intranet applications. I don't see how they can keep the two groups happy with the one browser. IMO, the best solution in the short term is to have two browsers, one for each group. IE8 and beyond for the web, and a standalone IE6 for the corporates.

  8. Thanks to Anne I came across Henri Sivonen's Almost precedent response to Eric Meyer. This says everything I've been wanting to express on this topic and then some. Go read it!Andrew: I've never really been convinced that the mythical IE-only Intranet Application is the big hard problem. On the contrary I think CSS hacks and quirk workarounds are so widespread that if IE8 came out tomorrow with perfect CSS2.1 support AND was capable of rendering the usual suspects GMail 1&2, Google Docs&Spreadsheets and Yahoo mail perfectly out of the box I'd be shocked and in awe.. 😉

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s