- From: Sam Ruby <rubys@intertwingly.net>
- Date: Mon, 22 Mar 2010 10:34:42 -0400
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: HTMLwg WG <public-html@w3.org>, Maciej Stachowiak <mjs@apple.com>
On 03/22/2010 09:51 AM, Henri Sivonen wrote: > 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". My position is that MUST is not appropriate. I understand but don't entirely agree with your position that a SHOULD is not appropriate. However, there may be other means to achieve this same effect: a means of opting in (some people use DOCTYPEs for this, I'm less enthusiastic about that approach), options on the validator UI, separate specifications that people can made their own determination as to whether such specifications are "applicable specification". Again, my position is simply that a MUST is not appropriate for any circumstance where there may exist valid reasons in particular circumstances to ignore the specific requirement. >>> "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). Again, I don't believe that either of those rise to the level of MUST. I also think this link is appropriate here (I think you will agree with the sentiments expressed there): http://lists.w3.org/Archives/Public/public-html/2009Feb/0127.html :-) - Sam Ruby
Received on Monday, 22 March 2010 14:35:17 UTC