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

On Sun, Oct 11, 2009 at 11:57 PM, Henri Sivonen <hsivonen at iki.fi> wrote:
> 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.

It's already done. That horse has left the barn.

> 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. The approach is valuable in the real
world where fixed investments actually *do* cause market distortions.
MSFT's original proposal had merit (although I dislike the solution
they eventually shipped).

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

Hixie's favored approach is very likely to have the effect new
renderers are adopted more slowly because of these dynamics.

> chrome=1 is more similar to IE=Edge than
> opting into a legacy IE.

Yep. Regardless, we're pretty far afield. The question I'd like to
understand the group's thinking on is: can the http-equiv meta variant
be brought into line with real-world usage by the HTML 5 spec?

> 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? That's a question of
market dynamics, not the intent of individual actors. I want a web
where we're not beholden to the whims of *any* individual
organization. Chrome Frame is designed to hasten the arrival of that
future and the behavior of IE=Edge and chrome=1 are an important part
of that change. I'll argue strongly that both are important in
delivering a web that is compatible, more future-proof (the assumption
with both is that things WILL change), and less silo'd as a result of
the assumption that things will continue to change. The baseline is a
temporary artifact of the transition to a better, faster-evolving
world.

Regards

> 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 Monday, 12 October 2009 10:48:02 UTC