Will X-UA-Compatible cause more browser harm than good?

Posted by Dan on Jan 23, 2008 @ 10:53 AM

There's lots of talk today about the new proposed X-UA-Compatible header which is being driven by the WaSP-Microsoft Task Force. The goal of the proposed meta tag header is to provide future compatible for IE and other browsers. The idea is you add a tag to your HTML that locks in browsers to that capability mode:

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

The above tag theoretically would prevent Internet Explorer 9 or Firefox 4 from breaking because of changes to their standards support by making the run just like prior versions.

While the goal is a noble one, I actually see this causing more harm than good. From past experience, something tells me that future products won't get backwards compatibility 100% correct. Since the whole point is to prevent sites from breaking with future releases, what problem have you solved if the browsers going to have bugs rendering in a compatibility mode anyway?

I like the idea that browser vendors (especially Microsoft) are trying to make web development more future proof, but I think there's got to be a better solution.

Categories: HTML/ColdFusion

8 Comments

  • Rob Wilkerson's Gravatar
    Rob Wilkerson
    As I mentioned on thecrumb.com, my problem starts with the motto "Don't break the web". Is that the best we can hope for? What about actually _progressing_ the web? Why not progress the web by default, but allow for backwards compatibility? I need to do more reading/thinking on the issue, but at first blush I'm basically okay with the mechanism, but not with the implementation. It's exactly 180 degrees from correct, I think. Standards by default, backwards compat if you choose.

    And why drag other browsers into this? Why would FF or Opera need this tag? Aren't we just "fixing" IE's mess?
  • Dan G. Switzer, II's Gravatar
    Dan G. Switzer, II
    @Rob:

    While it's primarily an IE problem, every revision of any of the major browsers has introduced *some* changes. The problems generally aren't as drastic as the ones we've seen with IE, but nonetheless, there are changes.

    As John Resig pointed yesterday (http://ejohn.org/blog/sub-pixel-problems-in-css/) there are also issues that every browser has, which isn't specified in any kind of standards doc. In his post yesterday, he was curious to see how various browsers handled objects with at 50% width inside an element with a width of 25px. Since this 50% or 25 is 12.5 and browsers don't typically handle sub-pixel rendering he was wondering what the results would be. As you can see from his post, the browsers all sort of do their own thing.
  • Jeff Price's Gravatar
    Jeff Price
    This will allow for _progressing_ the web. Simply markup your page with <meta http-equiv="X-UA-Compatible" content="IE=Edge" /> and you'll be golden.

    As for FF, Opera and others. I don't believe it to be that much of an issue. First of all FF and IE have been more standards compliant from the start, so they don't have significant quirks/hacks that folks use to render a page correctly. Second, they haven't been THE browser for most of this decade Yes, alternate browsers are gaining significant market share but you can't ignore that from 2000 until 2006, IE was the big boy in town with 90% market share. Should Microsoft just "break" every site that was developed when IE6 was king?
  • Rob Wilkerson's Gravatar
    Rob Wilkerson
    Good point. As I said, I need to do more thinking about this, but using your example I think MS's solution is kind of like driving a finishing nail with a sledgehammer. That's just my gut reaction. Other browsers have managed to progress without "breaking the web". The minutia may change, but on the whole the impact of those changes has seemed minimal - perhaps largely because they adopted a standards-centric approach early in the transition.
  • Rob Wilkerson's Gravatar
    Rob Wilkerson
    @Jeff -

    Yeah, but it forces me, as a developer trying to work on the progressive edge, to _do_ something to stay there. Why not progress by default and allow for a fallback position?
  • Jeff Price's Gravatar
    Jeff Price
    Ack! "First of all FF and IE" should be FF and Opera! Grr!
  • Dan G. Switzer, II's Gravatar
    Dan G. Switzer, II
    @Jeff:

    The problem with the "IE=Edge" is that you risk failing into the same problem we have now. If you end up having to write "hacks" for IE8 in order for it to work correct and IE9 fixes the problem, you're IE=Edge would end up breaking things. The only way to supposedly ensure that the site doesn't break when IE9 is released is to use the "IE=8".

    Also, the one thing I've failed to see any comments on is what happens when you want to upgrade the site for IE9, but also want it to work for IE8? What happens if you've verified your site works fine with both versions? You could use the "IE=edge" case, but what happens if IE10 breaks stuff?

    I'm just not sure this solution is forward thinking enough or that it really tackles the issue at hand.

    I think I'd almost just prefer to see conditional commenting be part of the spec (and introduce conditional commenting to CSS as well.) Having been doing web development professionally since 1994, the one thing I've learned is that we can't assume the behavior of future browsers. It just doesn't seem like the X-UA-Compatible header provides enough granular control.
  • Jim Priest's Gravatar
    Jim Priest
    John Resig has a good post on his blog today: http://ejohn.org/blog/html5-doctype/

    This just seems like a slippery slope to start going down...

Comments for this entry have been disabled.