W3C home > Mailing lists > Public > public-html@w3.org > February 2010

Re: Counter change-proposal for ISSUE-4 (html-versioning)

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 21 Feb 2010 14:21:17 -0800
Message-ID: <5c4444771002211421s27a2a888w6e7af53259248610@mail.gmail.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: HTML WG <public-html@w3.org>, Larry Masinter <masinter@adobe.com>
On Sun, Feb 21, 2010 at 2:07 PM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
> On Sun, Feb 21, 2010 at 1:08 PM, Adam Barth <w3c@adambarth.com> wrote:
>> The primary remaining rationale for having a version indicator is that
>> we might find such a version indicator useful in the future (even
>> though we agree that this eventuality is unlikely).
> I don't understand this rationale.  Suppose we decide we want HTML6 to
> be backward-incompatible -- i.e., to allow authors to create documents
> that legacy UAs will simply reject, rather than processing them
> incorrectly.  Why can't we just make up something then to achieve
> that?  For instance, use a different file extension and MIME type.  Or
> require that the first four characters be "<!--", and that HTML6 UAs
> ignore any content before the first "<!--", so anything prior can be
> used as fallback.
> It seems like an explicit version indicator now would give only slight
> benefit over the status quo, even *if* breaking compatibility were
> ever necessary (which seems extremely unlikely).  We should make sure
> that we'd be able to deal with extremely unlikely future scenarios,
> but we don't have to be able to do so elegantly.

I believe you can find the Larry's perspective on this question in his
change proposal.  Paraphrasing, he's worried that some folks might
have workflows that require valid HTML5 documents and that changing
those workflows after we arrive in this situation in a future version
of HTML could be costly.  My argument is that the expected present
value of those costs are extremely low.

Received on Sunday, 21 February 2010 22:22:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:58 UTC