- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 22 Mar 2010 15:51:20 +0200
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: HTMLwg WG <public-html@w3.org>, Maciej Stachowiak <mjs@apple.com>
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