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 15:51:20 +0200
Cc: HTMLwg WG <public-html@w3.org>, Maciej Stachowiak <mjs@apple.com>
Message-Id: <65CDD1DB-BC5B-4AC1-BAAF-CDB68E2A3D56@iki.fi>
To: Sam Ruby <rubys@intertwingly.net>
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
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
Received on Monday, 22 March 2010 13:51:55 UTC

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