Re: Strategies for standardizing mistakes

On Oct 11, 2009, at 11:52 PM, Anne van Kesteren wrote:

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

Let's separate Mark wanting to avoid document.all specification as  
bizarre, from the position we came to at the ad-hoc meeting with  
Cameron, of optional normative specs for document.all and perhaps a  
few such hacks.

Those of us advocating optional normative WebIDL sectioning to support  
such hacks are not in favor of endless reverse-engineering and market  
competition to discover how such hacks (or similar enough hacks) work.

On the other hand, there is no way we will standardize everything in  
the IE \/ non-IE union-semantics, we all know this. So the long tail  
will never be fully addressed, and it would do a disservice to web  
developers and users, if not to implementors, to try to specify  
"everything" or even 80% of everything (good old Pareto).

If we can avoid looking backward too much, we may find a better way  
forward that does not cost as much and that simplifies the APIs that  
web developers actually have to use to make modern, cross-browser- 
compatible content.

Ajax libraries long ago relieved devs from having to use document.all  
directly.

So of course, browser vendors still care about the long tail and  
compete for users who expect long-tail pages to work. But again this  
is a trail of tears, which can easily consume all our time without  
being anywhere near "done". Meanwhile, the opportunity costs grow.

How do we decide what IE compatibility hacks to standardize? I don't  
know if there's a rule of thumb. We can proceed based on what major  
vendors emulate, intersecting and comparing approaches. But whatever  
we do, we should (a) watch the clock (opportunity costs); (b) try to  
use quirks mode, since IE-only content is almost always quirky.


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

Mozilla's quirks mode support, again:

https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior

It is not possible to fold all of this into our standards mode  
support. It would be a mistake to do so even if possible, because it  
would overcomplicate the standards picture (even if not understood,  
i.e. unintentional or accidental usage) for web developers.

I think you (and Simon) and I must disagree on my belief that browser  
implementors have to pay a price in mode complexity in order to reduce  
the complexity of standards mode and allow quirks to be retired  
(unpredictably, but this is not possible if they are folded into  
standards mode).

/be

/be

Received on Monday, 12 October 2009 17:31:23 UTC