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

Fri Feb 8 08:17:36 PST 2008

On Feb 8, 2008, at 16:51, Jim Correia wrote:

> [I prematurely hit send on the last message. This message augments  
> the last.]

Messages pasted together here.

On Feb 8, 2008, at 16:33, Jim Correia wrote:

> On Feb 8, 2008, at 4:44 AM, Henri Sivonen wrote:
>
>> If the spec had a centrally-prescribed way for authoring tools to  
>> do spec versioning, people would be tempted to suggest all sorts of  
>> version-based conditional behavior in browsers.
>
> People may suggest it anyway. And some browser vendors may even  
> oblige them.

It does seem to me, though, that putting version identifiers in the  
format makes it more likely that people feel it is OK to act on such  
an identifier.

> Meanwhile, without a sanctioned way to clearly identify HTML 5, it  
> has been made difficult for those of us who want to do the right  
> thing because some to avoid some hypothetical wrongness on someone  
> else's part.
>
> (If browser vendors want a version identifier, there's nothing  
> stopping them from inventing one. Or several. It is not as if  
> proprietary browser-specific

Microsoft has even announced that they intend to include a browser  
engine versioning switch (not a HTML versioning switch).

>> I suppose we could add a modeline attribute on the root element if  
>> its content were a non-standard tool-specific configuration  
>> identifier to prevent general consuming apps from performing mode  
>> switching on it.
>>
>> http://lists.w3.org/Archives/Public/public-html/2007JanMar/0433.html
>
> Thanks for the pointer. In that message, for point 4, you wrote:
>
> 	If HTML6 is a superset of HTML5, writing HTML5 and checking with an
> 	HTML6 conformance checker won't be a problem. If HTML6 deprecates or
> 	obsoletes parts of HTML5, then we won't want to make it too easy for
> 	people to keep using the bad stuff without mentioning it to them,  
> will
> 	we?
>
> My experience of having shipping software to users and having to  
> support those users tells me this is going to be a problem. Suppose  
> they are using version 12 of my tool which does HTML 5 conformance  
> checking; checking their documents reports no errors. But they have  
> used elements or attributes which are deprecated in HTML6. They  
> upgrade to version 13 of my tool which supports HTML6, and now  
> checking those very same documents reports hundreds of errors. They  
> won't have read the release notes, or the documentation, or...  
> Instead, they'll write to my technical support address and complain  
> that the conformance checker is broken because yesterday there were  
> no errors in their documents and today there are hundreds.

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.

> 	If someone wants to keep checking against the definitions of HTML5 in
> 	the era of HTML6, I think it is reasonable put the burden of  
> choosing a
> 	different version from a pop-up menu in the conformance checker UI on
> 	the person who wants to do legacy checking.
>
> I agree that it is reasonable that a tool which supports HTML6  
> conformance checking should default to HTML6.
>
> The issue about - deprecated features and surprised users getting  
> errors in previously error-free documents still stands.

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.

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

For text/html, I made the generic facet of Validator.nu sniff the  
doctype by default.

In the case of SVG 1.0 vs. 1.1, though, I think supporting 1.0 based  
on the version attribute would be a total waste of time since 1.1  
mostly adds stuff to 1.0, so I just issue a warning about  
version='1.0' and suggest removing the attribute as the preferred fix.  
I don't support dispatching on SVG baseProfile, because I think device- 
specific profiling is bad for the Web. I have no active plans to add  
SVG 1.2 support, because 1.2 Full is not ready and browser vendors  
seems to be targeting SVG 1.1 (except for the focusable attribute  
which I guess I should add).

> Another usability issue is also the use case of users who work on  
> multiple trees, and need to have mixed conformance checking (without  
> constantly reconfiguring the tool) until such time as they can move  
> their legacy HTML5 documents with deprecated elements over to the  
> HTML6 standard.

This *could* be treated as a general text editor configuration problem  
like the tab settings. I use two spaces per tab with tab expansion for  
Python but four spaces per tab without expansion for RELAX NG Compact  
Syntax. TextWrangler can store these in some magic place in file  
attributes/resource fork. Unless I'm mistaken, Emacs can keep this  
info in a commented modeline near the start of the file. The same  
approach could be used with syntax checker settings. Whether it would  
be too annoying depends on how often users want to deviate from their  
overall settings on a per-file basis.

>> If there are issues we don't foresee now but we see when the  
>> successor of HTML5 is being defined, we can make the successor have  
>> a distinguishing feature at that time.
>
> 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.

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

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

> These tools need to be easy to use, require as little configuration  
> as possible (ideally none). Anything else, in my experience, will  
> frustrate users, and they'll just abandon the tools and not worry  
> about writing conformant documents.

I quite agree.

I try to keep http://html5.validator.nu/ as the no-config UI. However,  
different people have all sorts of configuration wishes which leads to  
feature creep in the generic UI:
http://validator.nu/

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/