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/
