[whatwg] X-UA-Compatible, X-* headers, validators, etc.

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  
ignore.

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  
does it?

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  
Chrome-only code).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 11 October 2009 23:57:04 UTC