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

On 17 February 2011 04:09, Nathan <nathan@webr3.org> wrote:

> living
>  the always being worked on draft
> dev
>  the heavy lifting and testing has been done, time for early adopters
>  and implementers to use and mature it (say, it's been implemented in
>  one or two browsers and tests are written).
> beta
>  adopting, other than bugs, a mature feature which is being adopted
>  (say, it's in 60% of browsers, tutorials and demos written, general
>  developers are aware of the feature and want to use)
> stable
>  adopted, widely implemented and supported features (standardized you
>  could say)

Can you please clarify one point in what you're suggesting - for the
stable track (and possibly others), there would be some kind of
timestamped and/or version-numbered snapshots in place..?

Regarding software lifecycles, things like the Ubuntu approach to
releases work well - in particular the biannual stable release offers
a convenient schedule for users to keep reasonably up-to-date while
being fairly safe bug-wise (and be confident about the compatibility
of package updates).

But the criteria for a 'stable' release of a spec seem rather
different. In particular, if implementation by vendors is one of the
factors, how that is measured becomes pretty significant.

To take a devilish line, the W3C is answerable to its membership (many
vendors), so the specs it produces will favour them over other
demographics. When a browser vendor does their own thing, they are
obviously favouring themselves. Having the rubber stamp for a 'stable'
spec being implementation by most of the browsers (i.e. maybe 4 or 5
vendors), we get the worst of these worlds. Amongst other things, it
would elbow out any chance of innovation in the space from any
companies outside of the inner circle.

At the other end of the scale, at the 'living spec' end, what
safeguards are there to prevent a single vendor setting the agenda
with the features it has in the pipeline? While this would be
different behind the scenes than a browser vendor doing their own
thing and leaving others to have to reverse-engineer to keep pace, the
net effect would be the same. As well as being un-levelling the
competition playing field among the browser vendors, this would also
disadvantage developers outside of the browser space. While they are
an indispensable part of the Web toolkit (the massively predominant
human interface with the Web), it should be remembered that browsers
are only part of a larger system. I don't think browsers are a niche
in the market sense, but they may be causing specialisation towards a
(fragile) niche in the evolutionary sense.

Cheers,
Danny.

-- 
http://danny.ayers.name

Received on Friday, 18 February 2011 21:03:03 UTC