[whatwg] HTML 5 : Misconceptions Documented

[Lachlan Hunt]

Mike Wilson wrote:
> Ian Hickson wrote:
>> On Sat, 17 Jan 2009, Mike Wilson wrote:
>>> So I wonder what is your process 
>>> for determining if a "quirk" should be included in HTML5 or not?
>> It basically boils down to "did Web browser vendors find that if they 
>> didn't implement it, enough people complained to justify spending the 
>> resources to implement it after all?".
> 
> Ah, so your process is really to look at if browser vendors
> historically have added special handling for individual quirks
> and then mimic "popular" solutions in the spec?

For some things, yes.

> Now I am just being curious ;-) but how on earth do you find
> all quirks (and if they have been specially dealt with) - is it
> up to reports on the mailing list or are you reading source 
> code? :-)

Some things are known based on experience, because they occur so 
freqently in practice.  But in general, when trying to spec a particular 
feature, a lot of time is spent testing and reverse engineering it using 
a variety of techniques including black box testing, reviewing past bug 
reports or even looking at the source code of the open source browsers.

For some examples of this, take a look at these articles
http://ln.hixie.ch/?start=1037910467&count=1
http://ln.hixie.ch/?start=1137799947&count=1
http://ln.hixie.ch/?start=1155195074&count=1
http://ln.hixie.ch/?start=1158969783&count=1
http://ln.hixie.ch/?start=1161042744&count=1
http://ln.hixie.ch/?start=1161121410&count=1

> And do you generally find concensus among the non-MS vendors or
> are there many quirks that are only worked around in a single 
> browser, and how do you handle that?

If possible, we try to spec the behaviour that has the most 
interoperability among the browsers. i.e. If 3 out of 4 browsers do A, 
and the the other does B, and there's no significant evidence of 
compatibility problems with A, then the spec is likely to define A.

If there's no interoperabiliy at all between the browsers (i.e. All 
browsers do something completely different), then we have a little more 
freedom to pick the most sensible alternative, taking into account any 
compatibility issues with real world content.

>>>> The idea is to make it so that browsers don't feel forced to 
>>>> add _any_ non-standard behavior (other than experimental
>>>> innovations using vendor-prefixed names and stuff).
> 
> Do you think this will happen with the current popular browsers, 
> ie will they actually remove existing code that implements 
> workarounds that don't make it into HTML5?
> Or will they employ some "legacy vs HTML5" mode switching where
> their custom workarounds are only in legacy mode?

If the spec omits something that we implement and there's evidence to 
suggest that we need to keep it for compatibility, then we'll try to get 
that added to the spec.  If it's something minor that no other browser 
does and it doesn't appear to be needed for compatibility with anything, 
then we're more likely to drop it.  There will not be, at least in 
Opera, Firefox or Safari, new modes added beyond the existing no quirks, 
limited quirks and quirks modes.

> I guess what I am really thinking about is whether there will
> ever be a "strict to standard" HTML5 implementation, or a
> reference implementation, that stays exactly on what is written
> in (or easily interpolated from) the HTML5 spec...?

There won't be any implementation considered to be the reference 
implementation. But the hope is that all implementations will eventually 
converge on implementing things in the same way, and that the spec will 
match.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/