- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 13 Oct 2009 09:07:16 -0400
- To: HTMLWG WG <public-html@w3.org>
Ian Hickson wrote: >> 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. Here's a scenario that demonstrates why one would want to migrate legacy documents: >From time to time, I work for a number of government agencies that are mired in red tape. One of these pieces of red tape, a website deployment checklist, states that we must generate valid HTML documents from our back-end systems. We have a ton of HTML4 content that uses @rev and @profile (correctly). There is talk that some HTML5 features (such as <video>) should be used in the next revision of the system, so we are in a bit of a situation. We can't just change the headers of the HTML4 documents we generate (the content of the documents were hand authored over 10 years ago) because @rev is now non-conforming and we can't deliver a system that doesn't allow the person overseeing the contract to check the box labeled "Documents are valid HTML". That's an example of why one would need to migrate legacy HTML4 documents to HTML5... it's not a rendering issue, it's a validation issue. > If HTML6 needs to do that, then there was an error in HTML5, and we should > change HTML5. At that point, I expect that we wouldn't change HTML5 for the same reasons we're not changing HTML4 now... but then again, that's talking about what /might/ happen in the future, and either one of us could be right about that. >> 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. I don't think it's a good idea to assume that HTML6 will be designed in the same way as HTML5. Just like it wouldn't have been a good idea to assume, in 1999, that HTML5 was going to be designed in the same way as HTML4. >> 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. Yes, agreed. I certainly agree that having multiple parsers would be a nightmare... and I think that if we had @version, it should be used very sparingly and after a great amount of debate and exploration of alternatives as outlined in this thread. At the moment, the technical problem we're attempting to solve would result in a simple if statement in the RDFa processors: if(version["RDFa"] == "1.1") {...} else {...} Just because we support @version doesn't mean that it is automatically going to lead to spiraling QA/engineering/authoring costs. If we are not careful, it may lead to that... but the mere existence of @version doesn't mean that we'll end up in that situation. That being said, I'm probably going to drop the @version tag from HTML5-EPB. The new proposal may do something like features="RDFa 1.1", with specifying the version of HTML specifically prohibited. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: The Pirate Bay and Building an Equitable Culture http://blog.digitalbazaar.com/2009/08/30/equitable-culture/
Received on Tuesday, 13 October 2009 13:07:47 UTC