W3C home > Mailing lists > Public > public-html@w3.org > March 2010

Re: HTML5 Authoring Conformance Study

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 22 Mar 2010 02:11:53 -0700 (PDT)
To: Sam Ruby <rubys@intertwingly.net>
Cc: HTMLwg WG <public-html@w3.org>, Maciej Stachowiak <mjs@apple.com>
Message-ID: <225402781.5749.1269249113729.JavaMail.root@cm-mail03.mozilla.org>
"Sam Ruby" <rubys@intertwingly.net> wrote:

> google.com:

(Note that these results are actually for google.fr or google.fi for html5.validator.nu (hosted in France) and validator.nu (hosted in Finland) respectively. google.com insists on redirecting based on a IP-to-country mapping.)

> the script tag is not unclosed, the html and body tags are unclosed. 
> HTML5 has many elements which do not require close tags.  It even has
> many tags that are entirely optional.  Both of these tags are entirely
> 
> optional, but apparently if present must be explicitly closed.  What 
> operational interop problem does this solve?

The message wasn't about lack of </body> or </html> but about the lack of another end tag. (</center>? I didn't verify.) The problem being solved is that the author may not have intended to keep the element open all the way to EOF.
 
> facebook.com:
> 
> How is this a "bad doctype"?  What operational interop problem does it
> solve to identify this doctype as non-conforming?  I thought the HTML5
> strategy was that the web is to be considered as non-versioned.

html5.validator.nu says:
"Warning: Obsolete doctype. Expected <!DOCTYPE html>."

It's not an error per HTML5.

The generic facet of validator.nu (not html5.validator.nu) requires a non-obsolete doctype when the validator is in the HTML5 mode. I suppose this could be viewed as a validator misfeature. 

> baidu.com:
> 
> What interop issues are solved by requiring script elements to come 
> before </body>?

You can't actually put a script as the next sibling of the body element node. This error solves the problem of alerting authors that the parser doesn't generate the tree that the source appears to generate if you aren't an expert in HTML5 parsing rules.

"Maciej Stachowiak" <mjs@apple.com> wrote:
> For what it's worth, I don't personally see the value in making  
> presentational elements and attributes an error.

Making presentational attributes and elements errors has the value of getting political buy-in from people who've spent a decade saying that presentational markup is bad.

If we make <font> not to be an error, some people will flip the bozo bit on us. We can't please everyone simultaneously on the topic of presentational markup.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Monday, 22 March 2010 09:12:27 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:59 UTC