Re: New split-out drafts vs. modular design

> ... timeframe to implement behavior somewhat compatible with that of 
> ...

The presence of and continued tuning of <embed> is enough to show all 
that

>  We can only hope to describe the behavior clearly as much as we 
> can.

I think this goes along with the to be continued html5 schema 
discussion because from one end the deteiled validatable html 
structures and datatypes can be specified for application/xhtml+xml 
using typical xml schema along with recommended runtime behaviors in 
the standard. If the user code is correct in authortime then we should 
get a correct runtime DOM. So we have a set of rules that apply when 
everything is OK.
For text/html then the vocabulary is directly derived from the xhtml 
schema(s) with compensatory or historical behaviors/structures/usages 
described as necessary to maintain the history and convenience trail. 
That is a set of rules that apply when everything is or may not be OK 
but is within some limits or slightly different definition of OK, or 
when the host is going to make a guess.

> and a third spec explaining how the two interact?

Intersect, maybe? at the borderlines between alive and whatever else 
comes after or before.  .

Thanks and Best Regards,
Joe



----- Original Message ----- 
From: "Boris Zbarsky" <bzbarsky@MIT.EDU>
To: "Larry Masinter" <masinter@adobe.com>
Cc: <public-html@w3.org>
Sent: Saturday, January 09, 2010 8:26 PM
Subject: Re: New split-out drafts vs. modular design


> 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 05:43:49 UTC