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 hsivo...@iki.fi http://hsivonen.iki.fi/
