draft on versioning and HTML

Thank you, Larry.  I expect this will be one of the primary subjects of
discussion at the F2F.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Larry Masinter <masinter@...>
Sent by: www-tag-request@...
06/01/2009 01:07 PM
 
        To:     "jar@..." <jar@...>
        cc:     "www-tag@..." <www-tag@...>, (bcc: Noah
Mendelsohn/Cambridge/IBM)
        Subject:        draft on versioning and HTML


I started working on bringing together all of the previous posts on
Versioning and HTML into a document:
 
http://larry.masinter.net/versioning-html.html
 
I reformatted the “Jonathan Formalism” and added it as an Appendix, should
include Acknowledgement, need to add Editors, etc.
 
Larry
--
http://larry.masinter.net
 

> 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@...
http://hsivonen.iki.fi/

Larry:  might I encourage you to at least mail this to the W3C archive, or
better yet, check it into the TAG CVS space (I don't care much whether you
use a dated entry or /doc).   This will get us a W3C-managed URI, backup,
etc., and perhaps a clearer indication for IP purposes that this is work
being done in conjunction with your TAG participation.  I think it would
also make sense to put down your name as author, a date, etc.

If you'd like me to take care of that for you, let me know.  Thank you.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Larry Masinter <masinter@...>
Sent by: www-tag-request@...
06/01/2009 01:07 PM
 
        To:     "jar@..." <jar@...>
        cc:     "www-tag@..." <www-tag@...>, (bcc: Noah
Mendelsohn/Cambridge/IBM)
        Subject:        draft on versioning and HTML


I started working on bringing together all of the previous posts on
Versioning and HTML into a document:
 
http://larry.masinter.net/versioning-html.html
 
I reformatted the “Jonathan Formalism” and added it as an Appendix, should
include Acknowledgement, need to add Editors, etc.
 
Larry
--
http://larry.masinter.net
 

Noah, under the assumption that Larry is away for a while, I will take the
liberty of putting this in W3C URI space, and doing some additional work
on it, as it's related to my outstanding action.

Best
Jonathan

On Thu, Jun 4, 2009 at 4:57 PM,  <noah_mendelsohn@...> wrote:

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@...> wrote:
Examples:

  HTML 5 versus HTML 4.01
  CSS 2.1 versus CSS 2.0


Examples:

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


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/

On Jun 5, 2009, at 13:19, Anne van Kesteren wrote:
[...]
>> 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.

Here's a relevant example (that I've mentioned on www-tag before):

HTML5 has only a single HTML parsing-level behavior difference in the  
quirks mode, i.e. a behavior difference based on a 'version  
indicator'. (All the other differences are in the DOM APIs and in  
CSS.) The single behavior difference (whether <table> closes an open  
paragraph) is not an incompatible change from any HTML *spec* to  
another: all HTML specs from HTML 2.0 through 3.2, 4.0, 4.0bis, 4.01  
to 5 agree on what the behavior should be (<table> closes paragraph).  
Yet, we have this case of "versioning" because browsers (starting with  
IE1) didn't behave per spec, content grew to assume browser behavior  
and now we can't adopt the IE1 behavior wholesale, because the  
incompatible specified behavior got enshrined in a prominent demo,  
which made browsers to do things differently per mode, which in turn  
may by now be assumed by existing content, before people working on  
browsers and specs realized that it makes more sense to change specs  
that to change interoperable implementations or, worse, change  
implementations but only subject to a version indicator.

http://hsivonen.iki.fi/last-html-quirk/

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

One of the API differences I meant above is the case-sensitivity  
differences of getElementByClassName() which is fallout from case-
sensitivity differences is class selectors in CSS which is fallout  
from taking reality-challenged specs as immutable. That is, the whole  
thing could have been avoided if instead of introducing a quirks vs.  
standards difference, browser developers had insisted on changing  
specs to make class selectors match ASCII-case-insensitively one  
existing content was past to point of the quirks mode having to do  
ASCII-case-insensitive matching.

While some of the quirks are really quite counterintuitive considering  
the general CSS model, in the case of class selectors, making the  
selectors ASCII-case-insensitive across the board wouldn't have caused  
any worse inelegance to the system than making element selectors match  
ASCII-case-insensitively. Thus, making class selectors different  
across modes didn't really buy the Web community anything particularly  
valuable but introduced complexity.

P.S. Strictly speaking, the spec that should have been adjusted early  
in retrospect was HTML 4.01--not CSS--since CSS delegates case-
insensitivity to HTML.
--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

As requested, now in w3.org URI space at this location:

http://www.w3.org/2001/tag/doc/versioning-html

I will edit it there going forward.

Jonathan

On Thu, Jun 4, 2009 at 5:27 PM, Jonathan Rees <jar@...> wrote: