- From: James Graham <jg307@cam.ac.uk>
- Date: Mon, 16 Apr 2007 09:33:28 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: "Preston L. Bannister" <preston@bannister.us>, "Dailey, David P." <david.dailey@sru.edu>, Alexander Graf <a.graf@aetherworld.org>, public-html@w3.org
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