Re: ISSUE-55: Re-enable @profile in HTML5 (draft 1)

On Tue, 13 Oct 2009, Manu Sporny wrote:
> 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 you have red tape that ensures you use the latest best practices, then 
yes, you'd have to remove rev="" and profile="" as well as change the 
DOCTYPE. This affects a very small portion of the authoring population, 
though; a small-enough portion that it's an acceptable cost.

(Also, if you're just generating pages automatically, then removing the 
profile="" and rev="" attributes would be relatively easy, so I don't 
think it's a big problem.)


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

We didn't fix HTML4 because it was a lost cause. A better example would be 
CSS3 vs CSS2.1. Even though CSS2.1 is "done", we still fix it when we find 
problems, rather than just have CSS3 contradict it.


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

I don't think it's a good idea to assume that HTML6 will be designed in a 
way that makes a version="" attribute useful either.

To answer your original question, "How will you know if somebody omits the 
@version tag on an HTML6 document if you should parse as HTML5 or parse as 
HTML6?": In the highly unlikely situation of the HTML6 designers deciding 
to do like the XHTML2 designers did that they could break backwards 
compatibility, then they can introduce a new versioning mechanism 
specifically to distinguish HTML6 documents from HTML1-5 documents. Then, 
the omission of such a mechanism would be a flag to use HTML5's rules.


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

I think that's bad for all the same reasons. Just have one parsing model, 
doing otherwise increases implementation, testing, and authoring 
complexity more than necessary.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 13 October 2009 22:44:41 UTC