[whatwg] X-UA-Compatible, X-* headers, validators, etc.
hsivonen at iki.fi
Sun Oct 11 23:57:04 PDT 2009
On Oct 10, 2009, at 08:20, Maciej Stachowiak wrote:
> I think the HTML5 requirement should be changed to allow any header
> in the Permanent Message Header Field Registry. Effectively, this
> would require either an RFC or an Open Standard. This seems just as
> good for HTML5's purposes as requiring an RFC.
I disagree unless we really want to enable http-equiv as a way of
specifying browser-only HTTP header equivalents that intermediaries
OTOH, if we want to enable only pragmas that the HTML layer must
recognize for backwards-compatibility, enumerating the permitted
values is quite reasonable.
As for X-UA-Compatible specifically, when Microsoft did it, it was
decried as a bad thing. Why does it become a good thing when Google
I can see one crucial difference: In IE8 without Chrome Frame (when
your domain isn't blacklisted), X-UA-Compatible is a mechanism for
opting into a legacy engine. As long as being able to implement the
legacy complexity is advantageous in use retention/acquisition, sites
opting into legacy IE behavior enable a lock-in to IE. chrome=1 is
more similar to IE=Edge than opting into a legacy IE.
However, another way of viewing this is that if user switched from IE
to Chrome proper (or Firefox or Safari or Opera), *other* sites would
be less able to use IE-only code. However, both IE=Edge and chrome=1
let users *also* keep the hard-to-clone legacy complexity for *other*
sites. If this creates a situation where IE+Chrome Frame is the most
compatible browser, the outcome isn't necessarily good for the overall
health of the Web, since the IE part would still lock the user into
Windows and even within Windows out of Gecko or Presto.
I guess it's too early to tell if Chrome Frame will have an overall
positive impact (making authors write to the multi-vendor
interoperable platform without having to write a special code path for
one vendor) or whether it'll have an overall negative impact either
strengthening IE or leading authors to write WebKit-only code (or even
hsivonen at iki.fi
More information about the whatwg