Re: Strategies for standardizing mistakes (was: Notes from Monday's meeting with TC39 folks)

On Oct 11, 2009, at 11:48 AM, Mark S. Miller wrote:

> I am only now catching up with this thread. Glad to see so much
> already covered. I'd like to begin by thanking Brendan and Mozilla for
> the courage shown in this message.

You can agree with Brendan's point of view, but whatever the merits, I  
don't think it shows courage to ask the standards to align with what  
Mozilla already does, which is essentially what he's asking.

>
> I agree completely. It is important for standards bodies to use the
> rhetorical power of conformance wisely. Hence the proposed distinction
> earlier in this thread between normative-mandatory and
> normative-optional features. Compatibility constraints already
> encourage browser makers to implement many legacy mistakes. For those
> mistakes they do decide to implement, it is good for standards to
> specify how, so that these mistakes do not suffer pointless
> incompatibilities.

The rhetorical power of conformance has historically proven almost  
relative ineffective on the Web. Authors do what works. Browser  
implementors do what they have to, to match what authors have expected  
will work. Any time you enshrine an optional behavior, you create a  
trap for both Web developers and future browser implementors. That's  
the tradeoff to your claimed "slightly easier to phase out bad stuff"  
argument, and that is the reason why many of doubt the wisdom of a  
normative-but-optional strategy.


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

I think the disconnect you're seeing is this: some weigh the costs of  
optional behavior as greater than the hypothetical benefit of someday  
removing a "bad" feature.  Bad features don't really harm anything but  
our sense of taste.

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

Pages that test document.all generally use it to decide whether to use  
IE-proprietary features. If IE implements enough of the Open Web  
platform correctly, then it will not be harmful and will likely be  
beneficial for them to hide document.all.

>
> 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 don't want to get too deep into this, but I question the claim that  
it's technically compatible with ES5. Yes, it's possible for a host  
object to return any value at any time for a property access. But for  
it to consistently decide this based on the context of the accessing  
code, this essentially means that ES3 [[Get]] (or the ES5 equivalent)  
are getting extra parameters that indicate what kind of expression  
contains the subexpression. I don't think using information that  
should not be available at [[Get]] time is ok, just because you could  
have random behavior which might by chance give the same result. Or at  
the very least, varying behavior based on what code is trying to get  
the value was not considered sufficient to make split-window conforming.

I'm willing to concede that Mozilla's behavior is arguably a smaller  
violation than what WebKit does. But I think the cost is that it's  
significantly more confusing for authors. Mozilla's behavior results  
in examples like this:

var all1;
function foo(x) {
     all1 = x;
}
var all2 = document.all;
foo(document.all);
// all2 now holds undefined, while all1 holds the document.all object

By ES3 / ES5 assumptions, it should be a valid source-to-source  
transform to add or remove the function call around the assignment,  
but with Mozilla's document.all behavior, it is not. For that matter,  
it should be a valid source-to-source transform to put a value in a  
local variable before using it (once), or to replace a variable  
reference with the defining expression (if only used once), but with  
Mozilla's document.all behavior these transforms are invalid.


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

That I agree with, and I think standards-only document.all may be a  
reasonable choice. But I'd like to see some study of how often  
unchecked document.all is used in standards mode vs. quirks mode.  
Apparently Mozilla's experience is that it was mostly quirks mode.

>
>>> Browsers could log in their error console about usage of  
>>> document.all to
>>> discourage authors from using it.
>>
>> This is about as effective as nagging users not to use IE-specific  
>> CSS,
>> i.e., not at all.
>
> Probably true. But neither should we discourage "warning" style
> feedback. We should just not assume it helps any until demonstrated
> otherwise. Warnings are no replacement for more effective mechanisms.

Nothing forbids warnings. But warnings in browsers tend not to be very  
effective. Warnings in developer tools or checkers tend to be more  
effective however, at least for those who choose to use them.

Regards,
Maciej

Received on Monday, 12 October 2009 07:24:11 UTC