W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: New split-out drafts vs. modular design

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 09 Jan 2010 23:26:22 -0500
Message-ID: <4B4956EE.5060105@mit.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:57 GMT