Re: legacy of incompetence? [was: a compromise to the versioning debate]

Maciej Stachowiak wrote:
> 
> On Apr 15, 2007, at 1:42 PM, Preston L. Bannister wrote:
> 
>> On 4/15/07, *Dailey, David P.* <david.dailey@sru.edu 
>> <mailto:david.dailey@sru.edu>> wrote:
>>
>>     [snip]
>>     I thought the WG charter had language running counter to this
>>     perspective, but on reanalysis, the closest I could find was:
>>     The Group will define conformance and parsing requirements for
>>     'classic HTML', taking into account legacy implementations;
>>     It would be a bit of a stretch to claim this means we have to
>>     support EVERY peculiar piece of HTML ever successfully rendered in
>>     some browser.
>>
>>
>> Speaking generally - seems there is a distinction that here that needs 
>> to be made, clear to all involved, and muddies the discussion when 
>> missed.
>>
>> One extreme interpretation of the proposed compatibility principles is 
>> that HTML-next describes a parser and interpreter that can handle any 
>> past W3C version or browser variant of HTML.  In this case, version 
>> specifiers become unnecessary (and some of the prior discussion makes 
>> more sense).
> 
> That is exactly the goal that is proposed for this group (although not 
> all vendors may choose to take advantage of it).

To be clear, I don't think anyone is arguing we should document the 
behavior of /all/ past browsers; I guess no one is interested in finding 
out what is needed to make a page that crucially depends on some quirk 
of Netscape 2 work as intended. Instead, I think what people want to do 
is make a HTML specification that, when implemented as part of a 
browser, works as least as well on the existing web as currently popular 
browsers which are based on extensive reverse engineering of other 
browser's behaviour.

Given that premise it's not hard to see why versioning is regarded as a 
poor idea; if there are N different HTML modes needed to make a 
competitive browser, the spec needs to document the behavior of each of 
those N modes, thus making the spec much more complex. Worse, 
implementing N modes in code probably scales the complexity of the 
resulting code rather worse than linearly so increasing the number of 
bugs and accidental inconsistencies between different products. Needless 
to say this makes life worse for authors.

At the moment we have N=2. Chris proposes we have N=[Number of IE 
releases] although possibly N-2 of those would be undocumented.

-- 
"Instructions to follow very carefully.
Go to Tesco's.  Go to the coffee aisle.  Look at the instant coffee. 
Notice that Kenco now comes in refil packs.  Admire the tray on the 
shelf.  It's exquiste corrugated boxiness. The way how it didn't get 
crushed on its long journey from the factory. Now pick up a refil bag. 
Admire the antioxidant claim.  Gaze in awe at the environmental claims 
written on the back of the refil bag.  Start stroking it gently, its my 
packaging precious, all mine....  Be thankful that Amy has only given 
you the highlights of the reasons why that bag is so brilliant."
-- ajs

Received on Monday, 16 April 2007 08:33:34 UTC