- From: Sam Ruby <rubys@us.ibm.com>
- Date: Fri, 30 Nov 2007 10:33:22 -0500
- To: Ian Hickson <ian@hixie.ch>
- CC: "public-html@w3.org WG" <public-html@w3.org>
Ian Hickson wrote: > On Thu, 29 Nov 2007, Sam Ruby wrote: >> Why is "the" (as in one and only) specification the only document in >> which this information can make it onto a W3C site? I've seen several >> specifications which are spread across volumes. Can't different volume >> in a series be in different states at any given time? > > There are a few reasons, but primarily the parts are too interconnected. > (For example, the offline stuff has to integrate with the navigation stuff > and the parsing stuff, which has to integrate with the scripting stuff, > and soon enough you've brought in most of the current spec.) Care to elaborate? From a quick scan of the current draft, the only occurrences of the word "offline" are in section 4.6. I have no problem believing that that section would depend on navigation, parsing, and scripting stuff; what I am curious to see to what extent the reverse is true. > There's also the lack of resources. There is such a high overhead to > editing a spec that the cost of editing two specs of size x is actually > higher than the cost of editing one spec of size 2x. This wouldn't be > necessarily a big problem if we had editors, but we don't -- we are > already desperately short on editors to work on CSS3, setTimeout, Web DOM > Core, CSSOM, DOM3 Events, Keyboard Events, a 3D Canvas API, etc. If we > suddenly magically had ten fulltime experienced Web specification editors > volunteer tomorrow, we _still_ would be short on editing resources. Not all of those items are equal. Let me take two from your list, hopefully identifying extremes: setTimeout and 3D Canvas API. I agree that splitting setTimeout would increase the overall workload. Furthermore, I see it as entirely possible that it would not only increase the entire workload of the working group, but that it could also lead to increasing the workload for the people working on the base document. The second statement is not necessarily true, but is enough of a possibility that the very idea of splitting this out deserves to be scrutinized. I also agree that splitting a 3D Canvas API out would increase the overall workload. However, I see it as extremely unlikely that doing such would result in a net increase in the workload of the editors working on the base document. I've got experience in working in all-volunteer contexts, and from my experience: that's a good tradeoff. Furthermore, there is another key difference between these two. If setTimeout isn't spec'ed, that's an indication that the spec isn't complete. If a 3D Canvas API isn't spec'ed, that's an indication that that features is ready for standardization. Now, before the above paragraph is misconstrued as me being "against" a 3D Canvas API, as has recently has occurred, let me make two things clear: it seems plainly obvious to me that there is considerable support for a 3D Canvas API, enough so that it would surprise me greatly if nobody stepped forward to help out. And secondly, I believe that creating a viable ecosystem for extensions doesn't curtail innovation, it enables it. "Centrally designed protocols start out strong and improve logarithmically. Evolvable protocols start out weak and improve exponentially. It's dinosaurs vs. mammals, and the mammals win every time." -- http://www.shirky.com/writings/evolve.html > So far we've tried taking four things out of HTML5. We have one success > story, XMLHttpRequest. The Window interface was taken out, put into its > own spec, and neglected to the point where it was blocking work on HTML5 > and I had to reinclude it (a lot of work), setTimeout was taken out and > had nowhere to go so it's been rotting in a section at the end of HTML5, > and the alternative style sheet selection API was taken out of HTML5 and > moved to CSSOM where it is currently dying of neglect as well. (setTimeout > and the alternative stylesheet stuff may have to be brought back into > HTML5 so that we can at least get interop on these features, even if this > isn't the ideal place for them.) > > I agree whole heartedly that it would be great if we could just have a > bunch of tiny specs that are self-contained and well maintained. In > practice, though, this hasn't worked. I truly wish it would. With such a small sample size, the only thing you can reasonably determine here is that these samples were not suitable for splitting out. Also, with open source projects, you don't attract developers by defining tasks that nobody wants to work on and ask for volunteers. I suspect that the same thing applies here. - Sam Ruby
Received on Friday, 30 November 2007 15:38:55 UTC