Re: Re-registration of text/html

Henri Sivonen, Wed, 10 Mar 2010 07:12:54 -0800 (PST):
> "Leif Halvard Silli" <xn--mlform-iua@målform.no> wrote:
>> Henri Sivonen, Wed, 24 Feb 2010 15:20:22 +0200:
>>> On Feb 21, 2010, at 11:35, Julian Reschke wrote:
>>>> On 21.02.2010 10:09, Ian Hickson wrote:
>> 
>> My view/questions differs from that of Julian w.r.t. what 
>> [t]he problems are.
>> 
>>>> What's important is whether the new text/html will allow existing 
>>>> HTML4 content to stay valid;
>>> 
>>> There are really multiple cases there:
>>>  1) Should pre-existing valid HTML4 continue to be valid HTML4? (I'd
>>>     say yes.)
>>>  2) Should pre-existing valid HTML4 be valid HTML5? (I'd say it 
>>> doesn't need to as far as precedent goes. Valid HTML 3.2 is never 
>>> valid HTML4.)
>> 
>> The goal of HTML5 is version-less HTML? Or is it only HTML5 and
>> onwards that will be version-less? 
> 
> I think the goal should be that authors/tools target contemporary 
> HTML, i.e. the newest spec. It's still possible that an old document 
> was valid according to then-contemporary HTML spec.
> 
> That is, I think it's uncontroversial that HTML 2.0 and 3.2 are no 
> longer contemporary. It's possible that documents that were authored 
> when HTML 3.2 was contemporary were valid according to 3.2 then.
> 
> It doesn't follow that the HTML5 spec or now-current tools should 
> make any particular effort to support authoring according to a legacy 
> spec.

When I first read about HTML5 and during the discussions after this WG 
was started, I often heard that one goal was to preserve HTML for the 
future. To make sure that we will be able to parse today's documents in 
the future. 

What is behind the hype slowly dawns on me ... 

I am first and foremost confused by Ian's statements about the unity of 
'text/html' with HTML5.

If we had simply said that "when using text/html, then the syntax must 
be text/html parser compatible", then OK. This what the text/html RFC 
says *now*. 

But to indicate that anything served as text/html *is* HTML5, is 
confusing.

>> Why does Validator.nu offer to validate HTML4 documents as HTML5 
>> documents? Why does it offer to validate text/html XHTML1 documents as
>> HTML5? Etc.
> 
> To ease migration.

I am not sure I understand ... The DOCTYPE is a syntax version 
indicator. And some kind of error message telling that "the only thing 
you need to fix in order to comply to HTML5, is to remove the DOCTYPE", 
seems much more fruitful if the goal is *transition*. So I agree that 
it should be possible to say "please validate my document as if it was 
HTML5, despite what the DOCTYPE says". If that is all you had offered, 
then OK. However, Validator.nu treats such documents as valid HTML5.

There are many other doctypes you could have included. For instance the 
doctype for XHTML11 documents. Why not accept any doctype that triggers 
standards mode? Do we even need HTML+RDFa? Can we just validate 
XHTML+RDFa documents and see if it "matches"? ;-)

>> The problem that I see is that HTML5 defines a parser and that the 
>> current version of the HTML5 spec draft says that the HTML5 parser 
>> should ignore the @profile attribute.
> 
> The *parser* doesn't ignore @profile any more than it ignores @href. 
> It's up to the upper layers of the UA to ignore stuff that the parser 
> just puts into the DOM.

Sorry, I should have been more stringent about discerning between 
"parser" and "user agent" - those two are closely related to me ...

Because, like Julian said, the spec draft says that "User agents should 
ignore the profile content attribute on head elements".

>> But may be there will arrive vendors that say "we do also support
>> HTML4 
>> - we do not limit ourself to the HTML5 compromise" ?
> 
> Seems unlikely given the economics of developing HTML clients.

This depends entirely on what one means. There are quite a few parts of 
HTML4 which it is not particularly costly to support - if one happens 
to disagree with the fate that HTML5 defines for them.

>>> Do you believe in ever obsoleting specs? Does your concern about 
>>> HTML4 extend to HTML 2.0? If not, why not?
>> 
>> Except for the very doctypes themselves of those specs, are there 
>> things in HTML32 and HTML2 that did not make it to HTML4?
> 
> HTML 2.0 <NEXTID> at least.

This was mentioned, yes.
 
>> As one can see, the RFC's wording about compatibility with "the 
>> Web"/preparedness for "the Web" is not congruent with what section
>> 12.1  in the HTML5 draft [which] says:
>> 
>>  ]]This document is the relevant specification. Labeling a 
>>       resource with the text/html type asserts that the 
>>       resource is an HTML document using the HTML syntax.[[
>> 
>> The wording "HTML syntax" has a link pointing to 
>> <http://dev.w3.org/html5/spec/syntax.html#syntax>, which indicates
>> that it is meant that the document uses _HTML5 syntax_.
> 
> This philosophical question could be avoided by stating that 
> documents labeled "text/html" must be processed according to HTML5.

This sounds more reasonable. But I don't understand the focus on 
version 5. Stating that documents labeled 'text/html' must/will be 
processed according to the HTML parsing rules, of which HTML5 is the 
latest version, seems more accurate.
-- 
leif halvard silli

Received on Wednesday, 10 March 2010 18:47:29 UTC