Re: HTML5 Authoring Conformance Study

On Mar 22, 2010, at 15:28, Sam Ruby wrote:

> On 03/22/2010 05:11 AM, Henri Sivonen wrote:
>> "Sam Ruby"<rubys@intertwingly.net>  wrote:
>> 
>>> google.com:
>> 
>> 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.
> 
> "may not have intended".  Given that this is google.com, I find it unlikely that this was unintentional.  RFC 2119:
> 
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.

The MUST vs. SHOULD distinction isn't useful when implementing a validator that exposes a SAX-like taxonomy of messages. Furthermore, I don't believe users would be helped by using UI terms like "MUST violation" and "SHOULD violation" instead of "error".

>>> 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.
> 
> So.... there may exist valid reasons in a particular circumstance to ignore this particular requirement?

I can't think of any serious non-contrived reasons. The contrived reason I can think of is augmenting content by doing stream concatenation (adding stuff after </html>), but tree-based markup is by its nature ill-suited for stream concatenation.

>> "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.
> 
> Name the individual.  I'm not being facetious.

If you want concrete names, I believe you'd need make <font face> conforming, publicize the change and observe the blogosphere.

However, if conjecture from analogy is good enough, see
http://lists.w3.org/Archives/Public/public-html-comments/2010Feb/0024.html
http://lists.w3.org/Archives/Public/public-html-comments/2008Aug/0005.html
for disapproval of less reviled elements that are perceived to be presentational (though the disapproval might not go far enough to constitute flipping the bozo bit).

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

Received on Monday, 22 March 2010 13:51:55 UTC