Will X-UA-Compatible cause more browser harm than good?
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:
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.
1064 Views
Send
Print
Comments (8)
Comments
And why drag other browsers into this? Why would FF or Opera need this tag? Aren't we just "fixing" IE's mess?
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.
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?
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?
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.
This just seems like a slippery slope to start going down...