Re: Please explain the role of the W3C in the continuing development of HTML

On Wed, 2011-02-16 at 00:31 +0000, Nathan wrote:

> Ian Hickson wrote:
> > On Tue, 15 Feb 2011, Nathan wrote:
> >> Ian Hickson wrote:
> >>> On Tue, 15 Feb 2011, Nathan wrote:
> >>>> The W3C timeline and model of releasing major versions "5" "6" is 
> >>>> far too slow, whilst the WHAT WG Living Standard is a constantly 
> >>>> moving target that the common web folk simply can't keep up with.
> >>>>
> >>>> It would be great to see the two approaches balanced such that 
> >>>> announcements are made like "HTML has just been updated, features 
> >>>> a,b have been added, bugs h,j,k have been fixed and z has been 
> >>>> deprecated".
> >>> Why do people want a specification of HTML with known bugs but without 
> >>> those bugs being fixed as soon as possible? Wouldn't referring to a 
> >>> specification with known bugs be harmful to interoperability?
> >> Indeed, perhaps I haven't been clear, I'm suggesting that if bugs h,j,k 
> >> have been fixed and are ready to push to the rec, then agree they are 
> >> fixed and push them, not to wait 18 months until features a,b are also 
> >> ready to be pushed.
> > 
> > So what you're really describing is a situation where we have two living 
> > standards, one with new features and one with only features that are 
> > widely implemented? I guess that could make sense; having one for people 
> > who only want to use features that are widely implemented, and one for 
> > people who are implementing the features or on the bleeding edge.
> 
> [the important message is in the last few paragraphs]
> 
> Yes, something like that, it's (unsurprisingly) comparable to the common 
> software development lifecycle, like that of the browsers, for example 
> google chrome, a dev channel, a beta channel, a stable channel, and 
> where none of those channels exactly matches a major revision number 
> (for very long, at least). I'd suggest that there are definitely at 
> least 3 channels for HTML and web apps specifications, for example if 
> you consider websql and indexeddb, both of those would have a dev 
> channel, and a beta channel, but neither of them has a stable channel yet.
> 
> This setup is extremely common, and appears to work for the web 
> community on an opt in basis, for example my mother uses the stable 
> channel of chrome, my partner uses the beta, and I use both the beta and 
> the dev channel for different purposes.
> 
> HTML and the long term "living" standards need the same setup, you want 
> and need the dev channel (and you're own canary/working/untested 
> channel), I want the dev and the beta channel, a large proportion of the 
> web, and w3c member orgs want and need the stable channel.
> 
> > The W3C does not provide this (and to my knowledge, has no plans to -- in 
> > fact the W3C process doesn't have a mechanism in place for this kind of 
> > thing currently).
> 
> Neither the WHAT WG or the W3C provide the above, the W3C is in fact 
> somewhat closer to the model because it has all the channels but still 
> follows an older (and much slower) "WD/LC/CR/PR/REC" model, which is 
> somewhat similar to the alpha, rc1, rc2 type release cycle in the 
> software world, whilst the WHAT WG effectively only offers the 
> dev/canary channel as a "living standard" with notes as to the stability 
> of features.
> 
> > The WHATWG spec kind of provides this, in that each section is labeled 
> > with how stable it is by an annotation in the margin. We could publish two 
> > specs, though, removing all the new fetures from one of them... would that 
> > help? They'd still be living standards, not specs with a cycle, but we 
> > could omit less stable features from one of the specs. Not sure how useful 
> > it would really be, people seem to have had no trouble using the features 
> > from "HTML5" long before any aspect of the relevant specs have been 
> > labeled as finished at the W3C.
> 
> Sorry to pop everyones bubble here, but middle 80% of the web (read as 
> nearly every developer working in a web design/development agency) is 
> uncatered for by both W3C and WHAT WG, they're all saying "where's HTML 
> 5" and waiting for new features, some of which (not all) they could 
> already be using today - for them the same scenario could continue when 
> "HTML 6" is being developed. The 10% at the only very stable please end 
> of the spectrum is handled by W3C (and they don't appreciate the WHAT WG 
> release cycle), and WHAT WG handles the other 10% at the bleeding edge 
> end of the spectrum (and they don't appreciate the W3C release cycle).
> 
> WHAT WG, your living standard cutting edge developer version will always 
> exist, and by definition has to, so that 10% you cater for always will 
> be catered for regardless.
> 
> W3C, your stable far from cutting edge version will always exist, and by 
> definition has to (because there's always an old stable version 
> somewhere), so that 10% you currently cater for always will be catered 
> for regardless.
> 
> Now, what I'm saying here, is where's the release cycle for the 80% of 
> the web? the majority, the people like me.?
> 
> That's the request and the void that needs filled - please, all of you 
> in HTML land, work it out soon, whatever concessions have to be made. 
> Even if the current status-quo of "HTML 5" LC through to REC in 2014 
> stays, and the "Living Standard" stays, at least get a semi stable beta 
> channel up there on /TR/, updated quite regularly (3 month rule please) 
> and point to it from all angles as a reference for the rest of us.


I'd like to understand your view of the 80% a bit better.  I would like
W3C to address this group, and in my view they are indeed well addressed
by having a more agile process with releases that are far more frequent
than today.  But I don't think that the 80% will suffice with something
that is only semi stable - and I don't think that 80% needs something
every 3 months.  So I would like to understand your thinking on this
point a bit more.


> 
> Hope this mail finds you all well :)
> 
> Best,
> 
> Nathan