- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 21 Feb 2010 14:21:17 -0800
- 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. Adam
Received on Sunday, 21 February 2010 22:22:19 UTC