W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

From: Aryeh Gregor <ayg@aryeh.name>
Date: Mon, 29 Aug 2011 13:35:34 -0400
Message-ID: <CAKA+Ax=SnQFPXnv=+_M4g=JZ0QGuSGzL8gBU5hcEE5a0DAnDUg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: James Graham <jgraham@opera.com>, public-webapps@w3.org
On Fri, Aug 26, 2011 at 12:48 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> The point is that if it's just a chapter in a larger spec, how do I
> know that there isn't other important information in the larger spec
> that I have to read in order to get a understanding of the full
> feature.

The same applies if it's a standalone spec.  Microdata is an example
of a spec with so many dependencies on HTML5 that having it in its own
spec is kind of silly:

http://dev.w3.org/html5/md/Overview.html#dependencies

A lot of features just aren't orthogonal.  DOM mutation events are a
great example of something that's tightly coupled to DOM operations,
such that everything DOM-related needs to account for them, and it
makes little sense to have them in a separate spec from DOM Core.
Things like Traversal and Range could be in separate specs, but
they're related enough and short enough that having them in Core also
makes sense to me, and I think we should just go with whatever the
editor finds most convenient.  If they delay LC or we want them to
progress faster for patent policy reasons, that's a separate story.

I do think the HTML5 spec is ridiculously large and could use with
being split up into several mostly independent chunks.  A spec
shouldn't be so large that you don't want to close the tab because it
takes too long to reopen.  But it also shouldn't be so small that you
have to keep a dozen different tabs open to figure out anything
nontrivial.  CSS3 specs are far too small.  I think DOM Core is
currently in a reasonable middle ground where it's still fair to add
more material to it if it's relevant, just not an excessive amount
more.

> I'm not talking about authors, I'm talking about browser vendors. As
> someone looking to implement a spec, I'm very interested in knowing
> which parts of the spec has consensus and which ones doesn't.

This is a separate issue.  New features and old features have to go in
the same drafts regardless, for sanity's sake.  If we want to mark
them up clearly, we have to do this whether they're in a big spec or a
small spec.
Received on Monday, 29 August 2011 17:36:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT