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

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