Re: draft on versioning and HTML

I thought I'd provide some examples to illustrate Henri's points, which I wholeheartedly agree with.

On Thu, 04 Jun 2009 09:15:48 +0200, Henri Sivonen <hsivonen@iki.fi> wrote:
> 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.

Examples:

  HTML 5 versus HTML 4.01
  CSS 2.1 versus CSS 2.0


>   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.

Examples:

  CSS 2.1 versus "CSS3".
  The XMLHttpRequest Object versus XMLHttpRequest Level 2


>   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.

Not really sure what examples to give here. For everyone who deals with the mess that is quirks vs almost standards mode vs standards mode this is common sense.


> 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.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Friday, 5 June 2009 10:20:29 UTC