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

[Henri Sivonen]

On Oct 12, 2009, at 20:48, Alex Russell wrote:

> On Sun, Oct 11, 2009 at 11:57 PM, Henri Sivonen <hsivonen at iki.fi>  
> wrote:
>> 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 disagree both with the assertion that MSFT's original proposal was
> "bad" and also that there's some different standard that should be
> implicit based on who's doing it.

OK. I think it's fair to say that there were others who thought that  
what MS is doing with engine versioning is bad.

>> 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.
>
> You're basing this assumption on the follow chain of events:
>
>   1.) many browsers jettison compatibility with proprietary or
> deprecated technology

More to the point, I assume that the anything-but-IE mostly-standards- 
based browsers are now significantly distanced from IE in terms of API  
compatibility. Where significantly means that there are sites that  
have code paths for IE and anything-but-IE.

That is, the other browsers haven't jettisoned IE APIs but have never  
had the full IE character in terms of supported APIs.

>   2.) enterprises upgrade their browsers, finding that old sites no  
> longer work
>   3.) enterprises find that they have incentive to upgrade their
> sites to modern standards
>
> This doesn't represent some large chunk of "the problem". Instead,  
> we see that:
>
>   1.) many browsers jettison compatibility with proprietary or
> deprecated technology
>   2.) enterprises understand this, so they actively resist deploying
> new renderers
>   3.) renderer exclusivility in the browser market causes adverse
> selection against web developers, shifting costs to them, distorting
> the market for renderer features and reducing developer ability to
> adopt new browser features sooner, even on new projects

To address this problem of intranet (or partner extranet) sites  
constraining enterprises from moving away from having the IE 5.5  
engine (in the form of IE quirks mode) installed, you don't need to  
give public Web sites the ability to stick to an old IE engine. You  
only need to give the IT dept. the option to blacklist intranet and  
partner extranet host names so that they get the IE 5.5 engine.

X-UA-Compatible over-solves the problem by allowing public Web sites  
to buy into the intranet way of doing things. This is bad for the  
health of the public Web and unnecessary for addressing the intranet  
issue.

There'd be an additional benefit from choosing IE 5.5 vs. Open Web  
engine based on a hostname blacklist only: The engine would be known  
before issuing the HTTP requests. This way, if the browser has decided  
to use an engine that exhibits Open Web traits instead of IE 5.5  
traits, the browser could set the User-Agent header to a value that  
doesn't have the substring "MSIE" and advertises Open Webish substring  
like Chrome's UA string. This would make the not-IE-5.5 engine  
actually participate on the anything-but-IE code paths instead of the  
IE-only code paths--therefore actually enabling the jump from the old  
world to the new.

>> 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.
>
> You're making a value judgement about what's good for the web based on
> an instantaneous view. What's to keep *any* renderer from holding the
> web back in the same way that NN4 once did

Note that NN4 was eventually eradicated. It's no longer part of the  
browser choice dynamics. In the case of NN4, people had to make an all- 
or-nothing choice and eventually made the right choice.

The X-UA-Compatible model makes IE 5.5 stick around indefinitely, so  
browsing solutions that don't provide an engine with full IE 5.5  
traits are disadvantaged indefinitely. (This is similar to OOXML  
having the mystery parts where you need to emulate ancient word  
processor behaviors without the spec telling you how. The mystery  
parts are deprecated but the legacy still weighs in favor of the  
implementation that implements the mysteries.)

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