On Oct 12, 2009, at 20:48, Alex Russell wrote:
On Sun, Oct 11, 2009 at 11:57 PM, Henri Sivonen <[email protected]>
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
[email protected]
http://hsivonen.iki.fi/
