Re: New split-out drafts vs. modular design

On Sat, Jan 9, 2010 at 8:26 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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?

All in all I want to say this:

I'm all for modularity. Both in spec functionality and spec editing.
It's not the only important thing, and not even the most important
thing, but it is definitely up there.

I further do think it that it would be possible to split out things
such Window/History/browser contexts from the HTML spec. However I
think it would be very hard to do so in a way that truly makes the
specs meaningfully independent. I.e. where you could read just one of
the specs and reason about that independently from the other, and
where the amount of complexity added by external cross references is
smaller than the complexity reduced by making each spec contain less
things.

Given that I believe this is so hard I wouldn't ask of Hixie, or any
other editor, to do that amount of work. Nor do I personally have the
time to do it.

If we end up receiving change proposals for ISSUE-94, I hope that
these change proposals will be detailed enough that they make it clear
exactly what parts of the current spec should live in the two
resulting specs. Ideally even provide the resulting split documents so
that they can be reviewed to see if they actually fulfill the intended
goals.

As always, this is of course my personal opinion, not the official
rules for the WG or something I expect that everyone agree with.

/ Jonas

Received on Sunday, 10 January 2010 06:51:31 UTC