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

Re: Bug 7034

From: James Graham <jgraham@opera.com>
Date: Mon, 22 Mar 2010 23:13:25 +0100 (CET)
To: Sam Ruby <rubys@intertwingly.net>
cc: James Graham <jgraham@opera.com>, Henri Sivonen <hsivonen@iki.fi>, HTMLwg WG <public-html@w3.org>
Message-ID: <alpine.DEB.2.00.1003222204410.10534@sirus>

On Mon, 22 Mar 2010, Sam Ruby wrote:

> On 03/22/2010 11:28 AM, James Graham wrote:
>> On 03/22/2010 03:51 PM, Sam Ruby wrote:
>>> On 03/22/2010 10:10 AM, Henri Sivonen wrote:
>>>> On Mar 22, 2010, at 15:59, Sam Ruby wrote:
>>>>> So what is the rationale for this restriction?
>>>> I'll let Hixie respond to the question.
>>>>>> When you talk about interop issues, do you mean actual interop
>>>>>> issues with software deployed today (even if that software might
>>>>>> fade away in the future) or interop issues in a future scenario
>>>>>> where every piece of software conforms to the spec?
>>>>> If there are valid reasons to ignore a particular item, then a MUST
>>>>> is not appropriate.
>>>> If you push "valid reasons" hard enough, you can just do
>>>> s/MUST/SHOULD/g and then validator UIs can label SHOULD violations as
>>>> "errors".
>>> Fallacy alert:
>>> http://en.wikipedia.org/wiki/Slippery_slope#The_slippery_slope_as_fallacy
>> I don't believe this is a fallacy. I write testcases in HTML all the
>> time. Often in doing so I have valid reasons to ignore particular
>> conformance requirements in the HTML specification — because, for
>> example, I am testing the behavior of non-conforming documents —
>> including those that are needed if authors want to achieve interoperable
>> behavior in current UAs. When doing so I typically understand the full
>> implications of what I am doing. Therefore per a literal reading of
>> RFC2119 all author requirements ought to be SHOULD requirements.
>> On the other hand, it is clear that RFC2119 was not really intended for
>> expressing authouring conformance requirements. Various parts of the
>> specification talk about vendors and implementations but nothing talks
>> about authors. Given this, the incongruence between the precise RFC2119
>> definition of the keywords and the way that they are used to express
>> authoring requirements is rather unsurprising. So, from a spec-lawyer
>> point of view the only way forward I see is to throw out the reference
>> to RFC2119 and write some other document that defines the terms used for
>> expressing normative criteria in the spec.
>> However I think this is silly and misses the point.
>> The only people who care about they way these terms are used are spec
>> lawyers. I don't think that rewriting RFC2119 so that it more obviously
>> applies to documents rather than implementations would have any
>> noticable effects on document authors. In particular I see no difference
>> between the validator reporting a RFC2119-style MUST as an error and
>> whatever the replacement would be in a new document (even if it was
>> closer to RFC2119-SHOULD); all that matters is that an error is flagged.
>> I also believe that the current terms are relatively well understood and
>> that the benefits of giving a consistent and relatively simple story to
>> authors outweigh the benefits of being precisely accurate, especially
>> when that accuracy is only appreciated by spec lawyers.
> Whee!  Let's take a statement out of context and debate that.  No, on second 
> thought, let's not.  Start here:

I am really unsure what statement you think I took out of context. You 
accused Henri of invoking a fallacy which it seems to me he did not. It 
seems to me that you are arguing that we should take RFC2119 literally 
for authoring conformance requirments. I don't believe this is possible 
since RFC2119 was clearly aimed at implementation requirements, not 
author requirements. If you were to try and take it literally I believe 
that all authoring MUSTs would inevitably become SHOULDs since there are 
circumstances in which an author, in full knowledge of the consequences, 
may wish to send any arbitary stream of bytes as text/html.

Given this, it seems that there are three logical options:

1. Change all authoring-related MUSTs to SHOULDs in the spec
2. Stop referring to RFC2119 for authoring related matters. Replace it 
with another document that is actually designed for document conformance 
requirements and rewrite the conformance criterion in terms of that 
3. Stop trying to take RFC2119 literally for authoring conformance 
requirements (i.e. give up on arguments like "Not only is this an 
incorrect application of RFC2119 [...]") and instead focus on what we 
actually want to achieve functionally.

I prefer option 3 even though it is clearly the least good from a 
spec-lawyer point of view.

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7034#c32
> "Not only is this an incorrect application of RFC 2119, as a strategy, it is 
> entirely self-defeating.  Specs that contain such requirements will be 
> willfully, flagrantly, and widely violated.  Furthermore, such requirements 
> that have no basis in interop issues and describe situations that either 
> authors or tools will commonly violate cause validators to produce volumes of 
> spurious issues that only serve to obscure real problems."
> Key. words. : "entirely". "self-defeating".

I agree that there is value in carefully considering the advantages 
conferred by having particular authouring conformance requirements. My 
point, as I have already said, is that focusing on RFC2119 is a 
distraction from the real issues.

I also think that implicating nevertheless-interoperable behaviour for 
authors ignoring conformance requirements is over-simplistic. It is 
certianly not uncommon to send different markup to different browsers, 
suggesting that authors are willing to make deliberate use of 
non-interoperable features when convenient.

> I submit as evidence:
> http://html5.validator.nu/?doc=http%3A%2F%2Fwww.sina.com.cn%2F
> Care to disagree?

Philip already noted that there exist real surprises for authors who 
habitually place unescaped ampersands in attribute values. I would suggest 
that one purpose of conformance requirements is to help authors avoid 
sharp edges in the language – features that have well defined, but 
surprising, behaviour. On this basis it is hard to justify making 
ampersands in attributes conforming.

I also note that sina.com.cn seems to be something of an outlier in terms 
of the number of errors.

> I happen to believe that flagging all non-explicitly closed non-void elements 
> is something that would be far more useful to authors of content intended to 
> be served as text/html than flagging the use of unescaped ampersands in URIs 
> is.
> Care to disagree?

I don't see why it is an either/or choice. You could certianly make a case 
that optional end tags are a sharp edge of the langauge. Do you also 
believe that the validator should flag missing <tbody> tags?
Received on Monday, 22 March 2010 22:14:30 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:13 UTC