- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Thu, 4 Jun 2009 10:15:48 +0300
- To: www-tag@w3.org
> http://larry.masinter.net/versioning-html.html I think there are three major points that the draft fails to address: 1) The draft seems to assume that incompatible changes between spec text in spec version N and spec version N+1 are what matter. This isn't so. What matters are incompatibilities with existing content and prospective implementations. If spec version N says something that's incompatible with existing content if implemented, it's quite OK for spec version N+1 to adopt a stance that contradicts spec version N but is compatible with existing content. Such a change doesn't cause any real problem. In fact, pretending that implementations of spec version N+1 had to alter their behavior for content labeled as being written to spec version N would lead to unhelpful complexity. Specifically, the formalism in Appendix III needs to be considered in the context of what is deployed--not in the context of what is specified. Basically, when writing spec version N+1, the spec writers should assume that spec version N may be nonsense and instead go see what actually got deployed. 2) The draft seems to assume that if there's a language spec for version N, implementations implement it fully, and when spec version N +1 comes along, implementations move to implementing N+1 fully. This is not the case on the Web. User Agents implement specs piecemeal and may ship a partial implementation of spec version N+1 before having completed all features of spec version N. Since the actual compatibility issue is between existing content and implementations and not between spec revisions, trying to base version indicator-based behavior alteration on spec versions is a futile exercise. Trying to base version-based behavior alteration on implementation versions is a harmful exercise: see http://dev.opera.com/articles/view/opera-ua-string-changes/ and http://ln.hixie.ch/?start=1201080691&count=1 for different aspects of trying to do version with implementations version indicators. 3) The draft seems to assume that it's sometimes OK to make changes that would cause so much incompatibility without a version indicator- based behavior change that a version indicator-based behavior change in implementations is needed. I think assuming this is the source of most problems in versioning discussions. It is *not* OK to make such changes even if it means that the language remains inelegant on a given point to eternity. Future revisions of the language spec and its implementations have to be constrained to making only changes that don't break a substantial part of existing content. When you feel you need a version indicator-based behavioral switch, you are probably about to break a substantial part of existing content. If you feel you can ship the change in a mainstream browser without a version indicator-based behavioral switch, you probably aren't breaking too much of existing content and the change may be justified. The whole quirks vs. standards mode switch shouldn't be seen as a precedent to replicate but as a learning experience of something that should never be repeated. P.S. Algol is not really relevant, because people who operated Algol compilers had the power to tweak the programs. The Web is a completely different environment, because users of browsers can't practically tweak the input the browser gets from a site. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Thursday, 4 June 2009 07:16:27 UTC