- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Mon, 29 Aug 2011 13:35:34 -0400
- 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 UTC