- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 20 Oct 2009 10:34:04 +0300
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/
Received on Tuesday, 20 October 2009 00:34:04 UTC