- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Fri, 18 Feb 2011 22:02:30 +0100
- To: nathan@webr3.org
- Cc: Jeff Jaffe <jeff@w3.org>, Ian Hickson <ian@hixie.ch>, www-archive <www-archive@w3.org>, Ian Jacobs <ij@w3.org>
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