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

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.


On Fri, Oct 9, 2009 at 11:56 AM, Brendan Eich <brendan@mozilla.org> wrote:
> On Oct 9, 2009, at 1:47 AM, Simon Pieters wrote:
>
>> On Thu, 08 Oct 2009 20:39:02 +0200, Maciej Stachowiak <mjs@apple.com>
>> wrote:
>>
>>>> Are you open to making undetected-document.all emulation depend on an
>>>> HTML standards vs. quirks mode switch?
>>>
>>> I think that would be a reasonable option, if that's enough to get the
>>> bulk of the compatibility benefit and if other implementors are on board.
>>
>> What's the benefit?
>
> Keeping document.all out of standards documents so it is not perpetuated by
> accident or intentionally. With the Web, if something "works" it will
> happen. In ten years' time we will have content using document.all but it
> should be shrinking. It's impossible to say when or whether it goes away but
> it is likelier to be more widespread, all else equal, if we don't confine it
> to quirks mode.
>
> FYI, when we implemented undetected document.all emulation, we did it only
> for quirks-mode documents.
>
> https://developer.mozilla.org/en/DOM_Implementation_and_Scriptability#The_Mozilla_DOM_vs._the_IE_DOM

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.

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

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.


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


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


-- 
    Cheers,
    --MarkM

Received on Sunday, 11 October 2009 18:48:38 UTC