Re: Spec organizations and prioritization

On Thursday, 22 March 2012 at 18:52, Jeff Jaffe wrote:

> On 3/22/2012 8:51 AM, Marcos Caceres wrote:
>  
>  
> Much of what I would have said has have already appeared elsewhere on  
> the thread: notably by Dom and others. A few other comments.
>  
> It is true that I was describing advantages in the CSS approach.
I'm not part of that WG, so I can see where the advantages might have been over CSS 2.0 and 2.1… but I fail to see widely applicable benefits. The Webapps WG already works on reasonably sized specs, but every spec has its own challenges.     
> It is  
> not true that I was disagreeing with the approach of the WHATWG HTML spec.

Sorry, I was not meaning to imply that you were. I was just citing that as an example of what I personally think as a fast progressing spec that is monolithic.  
  
> > Some specs, like HTML5, make sense as a monolithic spec: breaking it up into lots of "modules" would just be "make work".
>  
>  
> There are tradeoffs between being broken up and being monolithic. I was  
> not advocating anything as a universal solution. I do believe, however,  
> that there could be more modularity for the HTML spec. As pointed out  
> elsewhere on the thread, that actually has already resulted in parts  
> being separated.

Yes. A this can be seen as valuable from an IPR perspective.   

> > As a point of comparison: look at the interop in HTML5 feature sets and the size of the HTML5 spec relative to other "modules" and that might give you an indication of speed and progress… HTML5, for its size and scope, has move at a pretty amazing speed by anyone's measure (and retained extremely high quality).
>  
> I don't doubt that HTML5 has moved at a pretty amazing speed. I'm  
> gratified that we are targeting 2014 for REC (although I worry about  
> what will happen with a second last call).

My money is still on 2022 :)    
> We have to be careful about generalizing the conclusion. One thing that  
> has helped with HTML5 is that we have a single prolific editor who has  
> his head around the entire spec despite its size. That would not  
> necessarily be reproducible for all specs.

True.   
> It is also the case that despite outstanding work on HTML 5, Hixie often  
> reminds me that on some measures we are actually well behind where we  
> should be. The last version of HTML to reach REC got there years ago.  
> I think we all agree that we need to get successive versions of HTML to  
> REC faster. For HTML 5 we are using time boxing to force ourselves to  
> get there. There are other proposals on the table - such as annual  
> snapshots - each of which have their own pluses and minuses.

Agree.   
> It was pointed out elsewhere on the thread that although the community  
> has made amazing progress with HTML 5, we are still criticized on some  
> interoperability issues - since features are advancing at different  
> speeds within different products.

If you mean W3C products (i.e., specs and their features), then fair enough. If you mean browsers, then it's up to the market to decide what to prioritise to remain competitive (or to de-prioritise, if it makes sense for features that would yield little return on investment - or to simply not implement something for strategic reasons).

Received on Thursday, 22 March 2012 19:07:06 UTC