Re: New split-out drafts vs. modular design

On Sun, Jan 10, 2010 at 12:50 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

I do agree with your statement. It's a fair concern.

I'm the author of the bug and Issue 94. As such, I will be submitting
a change proposal, but there may be others. My proposal won't be
formatted as the HTML5 spec is formatted, but it will be detailed
enough to, hopefully, address your concerns, and meet the change
proposal template requirements.

If it is not, I expect it will be rejected, and rightfully so.

>
> / Jonas
>
>

Shelley

Received on Monday, 11 January 2010 01:18:49 UTC