[html5] Identifying HTML 5 documents? (vs. alternate flavors)

[Jim Correia]

On Feb 8, 2008, at 11:17 AM, Henri Sivonen wrote:

> Yeah, I try to mitigate this issue with Validator.nu by not handing  
> out badges when validation passes and by documenting that I intend  
> to fix bug. Though if I guess correctly what your product is, you  
> don't hand out badges, either.

I'm not in the business of handing out badges either :-). I just  
present the author with a list of things which the checker has  
identified as problems that I think the author ought to fix.

> Considering the current transition at hand, the problem is that  
> HTML5 obsoletes a lot of frequently used stuff based on principle  
> rather than based on hard data about harm. So the theory isn't  
> working now. The theory works with if the language only expands over  
> time (like CSS has done so far) and only contracts for an  
> *extremely* good reason.

So it sounds like this is reinforcement for the point that just  
checking everything as if it were HTML5 is not practical, and may not  
be so for its successor either.

(There are things which HTML5 doesn't deprecate, which I'd love to see  
deprecated. But that's a whole separate can of worms.)

> I'm not quite ready to give up on the theory yet, though. I'd prefer  
> to make the transition from HTML 4.01 Transitional to HTML5 fit the  
> theory by making HTML5 more permissive and thereby set a precedent  
> for the HTML5 to HTML6 transition:
> http://lists.w3.org/Archives/Public/public-html/2008Jan/0305.html
> http://lists.w3.org/Archives/Public/public-html/2008Feb/0043.html

Agreed - especially about allowing the legacy encoding syntax.

>> After reading through the message you pointed through, as well as  
>> others found via searching, it sounds as though we've been around  
>> this block a time or two by now and that the spec authors are  
>> rather inflexible about this point (and no new arguments have  
>> swayed them)?
>
> Not so far, no. See from
> http://krijnhoetmer.nl/irc-logs/whatwg/20080205#l-232
> onwards.

OK, so it sounds like the discussion is, and has been, ongoing.

For future reference, is this list appropriate for issues like this,  
or should the discussions be taking place somewhere else?

>> Having a distinguishing feature at this time would make it possible  
>> to build tools which failed more gracefully when feed a document  
>> from a newer spec, as well as simplify the issue of checking  
>> conformance for a tree of mixed documents.
>>
>> Suppose an HTML5 conformance checker were fed an HTML6 document. If  
>> there were a way to distinguish the two based on version, the  
>> conformance checker could say "This document declares conformance  
>> to HTML6, but we only know how to check conformance for HTML5"  
>> rather than generate a bunch of error messages for new elements/ 
>> attributes.
>
> Yes, that's a practical issue. Some people have expressed concern  
> that HTML5 documents are invalid according to the W3C Validator,  
> which, of course, is a silly concern when expressed *against* HTML5,  
> because it is expected that tools predating HTML5 don't validate it.

Yes. My point here is that it would be a lot better for the tool to  
say "Hey, I don't know what this is." rather than having it  
misleadingly say "This is invalid."

>> To be clear, I'm not approaching this solely from the point of view  
>> of the technical aspects of the specification. I'm approaching it  
>> from the point of view of wanting to put useful tools in the hands  
>> of users that they can use today, on their legacy documents, and  
>> carry them forward to HTML5 (and beyond.)
>
> I'm approaching this from the point of view of making tools useful,  
> too. I want Validator.nu to be useful. However, I'd prefer to  
> address this issue by allowing frequently used legacy stuff as  
> conforming to mitigate the issue of making previously conforming  
> things non-conforming and thus lessen the perceived need for a  
> versioning switch.

That would solve on particular use case which could lessen the need  
for a version switch. Without it, checking an HTML5 document against  
HTML6 where HTML6 has deprecated the foobaz attribute is going to be a  
huge exercise in frustration. You'll get manu errors about deprecated  
use of the foobaz attribute, with more important errors lurking in  
their midst. (This is not unlike the compiler warning situation, which  
is why many people have a no warnings build policy.)

Jim