- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 09 Jan 2010 23:26:22 -0500
- To: Larry Masinter <masinter@adobe.com>
- CC: "public-html@w3.org" <public-html@w3.org>
On 1/9/10 8:05 PM, Larry Masinter wrote: > The problem is not that HTML5 is described in a single spec, > the problem is that the WhatWG design for the Web Hypertext > Application Platform is not modular enough. The thing is, the really non-modular parts aren't being designed by WhatWG. They already exist, and are non-modular. They're largely the result of ease-of-implementation decisions in Netscape 2 and 3, the IE team's attempts in the IE3/4/5/6 timeframe to implement behavior somewhat compatible with that of Netscape 2/3/4 on top of a totally different underlying architecture, and the reverse-engineering that has been done since by the developers of Netscape 4, Gecko, Webkit, Opera, and to some extent IE 7 and 8. It would be awfully nice if during the design of Netscape 2's document.write feature the interactions with dynamic insertion of <script> elements with DOM methods or with XMLHttpRequest load events were considered, but neither of those things existed at the time. It would be nice if the interaction with the parser were considered when the DOM was being designed and specified, but it was treated as an implementation detail at the time. So here we are now, trying to finally write a spec for behavior that every single web browser has to have to not break all over the place on websites... and because of that we have no control over how intertwined and nasty the behavior is, unless we want a spec that can't actually be implemented by UAs that need to be compatible with existing content. We can only hope to describe the behavior clearly as much as we can. I'm not convinced that the current text does the best possible job of it, but I haven't been able to create anything better myself so far, nor have I seen anyone else succeed at doing so. > It may well be that there are implementation considerations > that cross modularity boundaries, but those should be > exceptions, and would best be placed in an implementor's > guide, not threaded ad hoc into multiple specifications. I'm not sure I follow this, actually. Is the proposal, for my concrete example above, that we should have one spec describing document.write as a DOM call, one spec describing the parser, and a third spec explaining how the two interact? -Boris
Received on Sunday, 10 January 2010 04:26:57 UTC