Re: draft on versioning and HTML

On Jun 5, 2009, at 13:19, Anne van Kesteren wrote:
[...]
>> Specifically, the formalism in Appendix III needs to be considered in
>> the context of what is deployed--not in the context of what is
>> specified. Basically, when writing spec version N+1, the spec writers
>> should assume that spec version N may be nonsense and instead go see
>> what actually got deployed.

Here's a relevant example (that I've mentioned on www-tag before):

HTML5 has only a single HTML parsing-level behavior difference in the  
quirks mode, i.e. a behavior difference based on a 'version  
indicator'. (All the other differences are in the DOM APIs and in  
CSS.) The single behavior difference (whether <table> closes an open  
paragraph) is not an incompatible change from any HTML *spec* to  
another: all HTML specs from HTML 2.0 through 3.2, 4.0, 4.0bis, 4.01  
to 5 agree on what the behavior should be (<table> closes paragraph).  
Yet, we have this case of "versioning" because browsers (starting with  
IE1) didn't behave per spec, content grew to assume browser behavior  
and now we can't adopt the IE1 behavior wholesale, because the  
incompatible specified behavior got enshrined in a prominent demo,  
which made browsers to do things differently per mode, which in turn  
may by now be assumed by existing content, before people working on  
browsers and specs realized that it makes more sense to change specs  
that to change interoperable implementations or, worse, change  
implementations but only subject to a version indicator.

http://hsivonen.iki.fi/last-html-quirk/

> Not really sure what examples to give here. For everyone who deals  
> with the mess that is quirks vs almost standards mode vs standards  
> mode this is common sense.

One of the API differences I meant above is the case-sensitivity  
differences of getElementByClassName() which is fallout from case-
sensitivity differences is class selectors in CSS which is fallout  
from taking reality-challenged specs as immutable. That is, the whole  
thing could have been avoided if instead of introducing a quirks vs.  
standards difference, browser developers had insisted on changing  
specs to make class selectors match ASCII-case-insensitively one  
existing content was past to point of the quirks mode having to do  
ASCII-case-insensitive matching.

While some of the quirks are really quite counterintuitive considering  
the general CSS model, in the case of class selectors, making the  
selectors ASCII-case-insensitive across the board wouldn't have caused  
any worse inelegance to the system than making element selectors match  
ASCII-case-insensitively. Thus, making class selectors different  
across modes didn't really buy the Web community anything particularly  
valuable but introduced complexity.

P.S. Strictly speaking, the spec that should have been adjusted early  
in retrospect was HTML 4.01--not CSS--since CSS delegates case-
insensitivity to HTML.
--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/