- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 5 Jun 2009 14:39:25 +0300
- To: Anne van Kesteren <annevk@opera.com>
- Cc: www-tag@w3.org
On Jun 5, 2009, at 13:19, Anne van Kesteren wrote: > I thought I'd provide some examples to illustrate Henri's points, > which I wholeheartedly agree with. > > On Thu, 04 Jun 2009 09:15:48 +0200, Henri Sivonen <hsivonen@iki.fi> > wrote: >> I think there are three major points that the draft fails to address: >> >> 1) The draft seems to assume that incompatible changes between spec >> text in spec version N and spec version N+1 are what matter. This >> isn't >> so. What matters are incompatibilities with existing content and >> prospective implementations. [...] >> 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@iki.fi http://hsivonen.iki.fi/
Received on Friday, 5 June 2009 11:40:09 UTC