- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 12 Oct 2009 06:05:02 +0000 (UTC)
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: HTMLWG WG <public-html@w3.org>
On Mon, 12 Oct 2009, Manu Sporny wrote: > > Here's my definition of a backwards incompatible change as it applies to > this discussion: > > "Any change in HTML5 that, given an HTML5-conformant User Agent, will > cause a previously conformant HTML4 document to no longer be a > conformant HTML5 document." I don't think that definition makes sense. What does the user agent have to do with the conformance of a document? Why would an HTML4 document ever be a conforming HTML5 document? > Now, if one were to have a large number of articles written in HTML4, > migrating those articles to HTML5 isn't as simple as removing the > DOCTYPE at the top of the document. Why would one need to migrate legacy documents to HTML5? The whole point of the backwards-compatibility design is that HTML4 documents will continue to render the same in HTML5-conforming user agents as they did in HTML4-contemporary user agents. > HTML6 may want to make several backwards-incompatible spec changes based > on authoring use in the field such that default parsing behavior matches > real-world usage, in which case a version specifier is needed to ensure > that previously conforming documents continue to be conforming after the > change. If HTML6 needs to do that, then there was an error in HTML5, and we should change HTML5. > How will you know if somebody omits the @version tag on an HTML6 > document if you should parse as HTML5 or parse as HTML6? Assuming HTML6 is designed the same way that HTML5 was, there would be no difference. HTML6's parser would be a superset of deployed HTML5-contemporary parsers, just like HTML5's parser is a superset of the HTML4-contemporary parsers. > If we create a rule now that says anything that doesn't have a @version > attribute will be parsed using the latest rules known to the User Agent, > we're covered. That way leads to there being multiple parsers. That's a terrible place to be, as it leads to spiralling QA costs, engineering costs, and authoring costs. It's imperative that we not end up in that situation. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 12 October 2009 05:54:31 UTC