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

(unknown charset) Re: HTML5 Authoring Conformance Study

From: (unknown charset) Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 23 Mar 2010 14:14:16 +0100
To: (unknown charset) Henri Sivonen <hsivonen@iki.fi>
Cc: (unknown charset) Sam Ruby <rubys@intertwingly.net>, HTMLwg WG <public-html@w3.org>, Maciej Stachowiak <mjs@apple.com>
Message-ID: <20100323141416687820.413ce1e5@xn--mlform-iua.no>
Henri Sivonen, Tue, 23 Mar 2010 13:26:19 +0200:
> On Mar 22, 2010, at 16:34, Sam Ruby wrote:
>> 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.

Google.no has same error. According to Ian's (inside?) info, it was 
unintended. However, if a <center> is used to center everything on the 
page, then there were no need to close it. 

>>>> "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.
> My position is that MUST vs. SHOULD is a distraction as far as the 
> question of what a validator reports as "error" goes.
> If you call Slippery Slope, I call Red Herring.

Some like to play "it is the spec that matters, not the validator".

Here and there, the error and warning messages of Validator.nu links to 
different specs. For example it links to RFC4646 when it comes to 
language tag errors. Why could you not link to an explanation of SHOULD 
and MUST as well?

Speaking about language tags: Earlier this year, I took part in the 
registration of a language variant subtag - 'hognorsk'. This variant 
subtag has as  the *recommended* (aka "should") prefix the primary 
language subtag 'nn'. I wanted to have it registered that 'no' was also 
a recommended prefix. But I gave in when I was reassured that even if 
'nn' was the recommended primary language prefix, it was still not 
illegal to use any other primary language subtag as the prefix.

And yes, it is a literal 'should' in Richard's checking tool. [1] 

But Validator.nu apparently operates according to other rules, and says:

	"Error: Bad value no-hognorsk for attribute lang on
            element p: Variant lacks required prefix."

"Bad value"? No. "Required prefix"? Plain wrong.

Btw, why don't you link to BCP47 
(http://tools.ietf.org/rfc/bcp/bcp47.txt) instead of RFC4646 
(http://tools.ietf.org/html/rfc4646) in the error message?
>>>>> "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
>> :-)
> Perhaps I should have been more clear:
> I am not arguing that we should keep particular pieces of 
> presentational markup as non-conforming. I was saying what value 
> there is in keeping those pieces non-conforming.

But if that was not your argument, then there are others that would 
argue that it should be conforming. There can be valid use case for e.g 
marking up style *without* marking up semantics. In the past I argued 
that e.g. <strike> has a different semantics from <del>. (I probably 
should file that as bug.)

leif halvard silli
Received on Tuesday, 23 March 2010 13:14:52 UTC

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