Crowley Code! 
 (Take 12)

Please don't X-UA-Compatible me like that 2008/01/22

The echosphere is making quite a stink about Microsoft's proposed X-UA-Compatible header to explicitly match HTML pages to rendering engines.  There are two possible outcomes, assuming Microsoft goes ahead and implements this HTTP disaster.  More likely is that we will be roughly where we are now, with special cases to make IE do what we want and other browsers just working reasonably correctly by themselves.  Less likely is that the Redmond dream will be realized and every browser will become a time capsule of rendering engines ready to happily consume whatever 1997 garbage you can throw at it.  Oh yeah, if you add the header to all of those ancient pages.

For maximum effect, X-UA-Compatible requires the support of the other browser vendors, otherwise it is just another Microsoft hack with a pretty mask on (read: no regular expressions).  (Aside: The ideal solution to problems like the old broken box model would have been to fix it immediately instead of six years later.  I can't help but think that X-UA-Compatible would never have been proposed had that bug not persisted for so long.) In this best-case scenario the cynic in me still sees ignorant developers either omitting this header or setting it only for IE, leaving other browsers to do ..  something.  If the header is set for all of the major vendors (and we'll just assume that those major vendors will still be the only major vendors down the road) then I must admit, browser bloat is the biggest concern we have.  I for one don't want my Firefox to get any bigger.  Just imagine the new and exciting memory leaks!

In the (I think) more likely case of Microsoft pushing ahead with this feature alone then developers have the slight advantage of being able to code to one version of IE instead of several, in addition to Firefox/Webkit/Opera.  This may prove to be useful in fixing those sites that IE7 broke.  But seriously, why haven't those already been fixed?

Ultimately, it all comes down to what browsers do if that header isn't sent or they aren't paying attention to it at all.  It sounds like Microsoft is content to leave everything its IE7 state forever unless told otherwise but I doubt anyone else will be keene on the idea.  Microsoft is a much bigger fan of backwards-compatibility than Apple (think Classic Mode) or Mozilla (each new version of Firefox breaks all of my extensions) so I expect to see these others defaulting to their cutting-edge browser unless told to retard themselves.  This most-important point of the whole feature is summed up best by Jeremy Keith, "Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7." I'm a desktop software developer by day and wish I could say to Windows, "Make this app work just like an out-of-the-box Windows XP installation." I can't because having such a ridiculous level of backwards-compatibility ultimately makes software too big and unwieldy — it hurts you in the long run.  I hope, when framed in the desktop version that the insanity here shows through.

My final thought on the matter is that the best thing Microsoft can do for the future is to push IE7 out to everyone.  Like pulling off band-aids, it's best to do these things fast and deal with the consequences all together.  Fixing the IE box model should not take seven years.  Get it over with and move forward without the hacks.

Elsewhere:

Comments (6)

  1. Clever title, clever diction within the post aimed probably at me and like 4 other people, and content I wholeheartedly agree with. What more could a boy ask for?

    Mihasya — 2008/01/22 8:08 pm

  2. After thinking for 5 minutes this morning, I've decided this is a (semi-)good thing.  Many companies won't upgrade IE because it breaks internal apps.  If they could put a little header in the app and then be able to upgrade IE to the latest version, that will be to everyone's benefit.

    What I don't like is the defaulting to IE7 behavior.  They aren't the only ones making this choice though.  Perl 5.10 works like Perl 5.8 unless you say "use 5.010" (or various variants on that theme).  Perl learned a lot of lessons migrating from 5.8 to 5.10 and came to the same conclusion as Microsoft has about defaulting to an old version.  This catering to the ignorant/lazy is unfortunate, but necessary.

    David Hall — 2008/01/23 5:42 am

  3. @David,

    There's a difference between the Perl case and the rendering engine case. With Perl, in essence, the implementation is the specification. Excluding various edge cases and bugs, if your code compiles in Perl 5.8 it is valid Perl code. I think the Perl monks have a much stronger argument -- they have a responsibility not to break old (valid) code with a new release. When they realized that this was limiting their ability to continue developing the language (after 5.8 was released) they solved the problem by adding a feature to the language (use 5.010).

    This has already happened in HTML land. We're already specifying which version of HTML we want to use with DOCTYPE headers, and the default behavior (like with Perl) is to use a historical rendering engine if no DOCTYPE is provided. The problem is that Microsoft keeps releasing new crappy browsers that don't properly implement the standards. The result is that there's a lot of code out there that claims to be XHTML 1.0 Strict (for example) but isn't because it has a bunch of hacks and workarounds for IE.

    The reality is, by implementing this tag browser vendors would be encouraging developers to code to browser implementation instead of coding to the various specifications.

    Mike Malone — 2008/01/23 3:26 pm

  4. @Mike: I'm not sure how this encourages people to code to browser implementation any more than IE shipping with broken standards support encourages people to code to browser implementation.  If you say you want to have A-grade support for IE, you end up coding in the end for their implementation.  (I guess there's a difference with people who start and end in IE, which is what I would define as coding for browser implementation, but I don't see how this encourages that).

    I actually think this will decrease the complexity of hacking IE in some ways.  Before this, when IE8 would be released, you'd have to have browser conditionals for people still on IE7 and conditionals for people on IE8.  What this will allow is you leave the IE7 conditionals until IE8 is sufficiently adopted that you can switch from IE7 to IE8 conditionals.  In the end, if I was still a web developer, this makes my life much, much easier (and if I'm a designer, I don't get calls from old clients when my forward-compatible, standards-compliant site breaks because IE8 introduced a new bug).

    David Hall — 2008/01/23 9:58 pm

  5. btw. my true feelings on this issue is that I'm glad I now write code that just runs on an IBM Blue Gene, because that doesn't have all the same issues as the internet.

    David Hall — 2008/01/23 10:03 pm

  6. I agree with Mike. Why would you want to cater to different browser implementations, when there is specification written on how to write the code correctly?

    IE will slowly die out as people's scorn increases for Microsoft (I hope).

    Andrew Mager — 2008/01/27 1:58 pm

Richard Crowley?  Kentuckian engineer who cooks and eats in between bicycling and beering.

I blog mostly about programming and databases.  Browse by month or tag.

To blame for...


© 2009 Richard Crowley.  Managed by Bashpress.