W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2009

Re: Strategies for standardizing mistakes

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 12 Oct 2009 08:52:06 +0200
To: "Mark S. Miller" <erights@google.com>, "Brendan Eich" <brendan@mozilla.org>
Cc: "Simon Pieters" <simonp@opera.com>, "Maciej Stachowiak" <mjs@apple.com>, "Cameron McCormack" <cam@mcc.id.au>, public-script-coord@w3.org
Message-ID: <op.u1odc4fg64w2qv@anne-van-kesterens-macbook.local>
On Sun, 11 Oct 2009 20:48:04 +0200, Mark S. Miller <erights@google.com>  
> For those features that we wish to encourage web content to continue
> to use, whether originally mistakes or not, it makes sense to make
> these features normative-mandatory. The effect for normative-mandatory
> is to raise the deterrence on a browser maker beyond that imposed by
> normal compatibility pressures. If they don't implement it, they
> cannot claim conformance with the standard. Existing pre-html5 DOM use
> of catchall "getter" properties are in this category.
> For those features that we wish to discourage, and whose courageous
> removal by browser makers -- however unlikely -- should be applauded,
> we should go no farther than normative-optional. Compatibility
> pressures will still likely keep most of these mistakes around
> forever. But we shouldn't second guess the future in too much detail.
> If de-facto use and deployment change to where some browser makers
> would otherwise be willing to retire a feature, the threat of the
> "non-conformance" label could well stop them. In that case, the
> standards body would have subtracted value from the world.
> Frankly, by either of these criteria, I find the discussion of
> document.all bizarre.

So maybe not everyone is of the opinion that normative-optional is a great  

It seems bad for the long of the tail of the Web with unmaintained pages;  
it will create the need to reverse engineer other browsers again because  
they might not support a feature and therefore a page works better in them  
(authors do the weirdest things) or they only support it in quirks mode as  
you later find out when you removed the feature entirely. Optional  
features are bad in my opinion.

> The legacy hack motivating this issue is due to
> some webpages testing falsiness of document.all in order to detect
> whether they are on IE. However, the prior proposal was to mandate
> that document.all be falsy, even though it is truthy on IE, which is
> why those webpages test it. If the standard mandates falsy, then IE
> would have the choice of either not conforming or effectively lying --
> essentially claiming to these pages that it is not an IE browser.

Which is what IE has been moving towards already by removing support for  
various CSS quirks only they support and in line with something they  
recently proposed on www-style; regarding the removal/renaming of various  
proprietary CSSOM extensions that were up for standardization so they  
would not be detected as IE on those pages anymore.

So I'm not at all convinced this would not be in line with what the IE  
Team would want.

> It took me a while, and verbal conversations with Brendan, to
> understand what Mozilla does about document.all. Not only is it (just
> barely) technically compatible with ES5, it is code-based, not
> object-state-based, and so can depend on whether the code is strict or
> not. Again, I applaud Mozilla's courage in retiring document.all
> bizarreness from the behavior of strict code and non-quirks mode
> frames.

I have to say I do not really see the advantage.

>>> In general I think we should try to minimize the number of differences
>>> between rendering modes. Having differences add implementation  
>>> complexity
>>> and QA cost.
>> My sincerely blunt reaction: too bad. Having legacy crap in standards  
>> mode tends to perpetuate it. The greater good favors complexity for  
>> implementors and QA on this front. It's not as if undetected  
>> document.all emulation is easy to implement or QA!
> Agreed again. The job of standards bodies should not be only to help
> the de-facto process converge on agreed crap faster. It should also be
> to gently encourage agreement on decisions that are marginally less
> crappy -- to the degree that this is feasible within the legacy
> compatibility pressures.

I agree with the sentiment, but I do not think that hiding things behind a  
mode or version switch is in any way the right solution. I suppose we can  
do it for document.all, I do not really care, but setting more precedents  
for versioning schemes on the Web is dangerous and should be avoided when  
possible in my opinion.

Anne van Kesteren
Received on Monday, 12 October 2009 06:53:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:01 UTC