Re: summary attribute compromise proposal

On Aug 4, 2009, at 2:47 PM, Maciej Stachowiak wrote:
> On Aug 4, 2009, at 2:37 PM, Roy T. Fielding wrote:
>
>> On Aug 4, 2009, at 1:50 PM, Maciej Stachowiak wrote:
>>> On Aug 4, 2009, at 1:43 PM, Julian Reschke wrote:
>>>
>>>> Maciej Stachowiak wrote:
>>>>> No, I mean a summary attribute being present at all, regardless  
>>>>> of its value. What do you think should be the validator  
>>>>> behavior for that case?
>>>>> ...
>>>>
>>>> Unless the validator develops sufficient intelligence so that it  
>>>> can tell a good summary value from a bad one, it should stay  
>>>> silent.
>>>
>>> I think silence is not an approach that will get buy-in from  
>>> people who think summary is problematic.
>>
>> We have no need for their buy-in.
>
> If we don't have broad buy-in, then we don't have consensus, in  
> which case we need to resolve the issue in another way, such as a  
> vote. I'd rather find a resolution that everyone can live with, but  
> if we can't do that, then so it goes.

But the same people said that they would be satisfied by a reasoned
argument that shows it is useful and distinct from other HTML5 mark-up.
So either there is no need for a compromise or those people intend to
stand by their personal opinion in spite of both the reasoned argument
and the actual needs of others.  In either case, the appropriate action
by the editor is to make no change to the existing HTML language,
since WG consensus only necessary to make a change to the previously
agreed definition of the language in HTML4.

>> The opinion that summary is not usefully distinct from all other
>> forms of caption mark-up has been proven wrong.  Do you disagree?
>> If so, then refute my argument.  If not, then there is no need to
>> find a compromise of opinions and Ian should fix the offending text
>> before it is published as a WD.
>
> I think your example is a plausible use case, and I have no wish to  
> argue against it. My proposal doesn't take the position that  
> summary is never useful. It takes the position that authors should  
> be advised to consider alternatives to what we have learned is an  
> error-prone construct. I don't think your use case refutes that  
> position.

My use case refuted that position because it demonstrates that
there are no alternatives.  It would therefore be an ERROR for a
validator to warn that the author should seek out alternatives
when those alternatives clearly do not exist.

If the WG insists on placing a warning on the use of @summary, then
I will insist on placing a warning for any use of javascript,
canvas, and whatever-replaces object/embed.  Those features offer
far more potential for error-prone constructs that might be more
accessibly implemented using other HTML elements.  I don't think
that's why we have validators, but if we are going to be pedantic
about opinions regarding language features then at least
we should be consistent.

....Roy

Received on Tuesday, 4 August 2009 22:29:44 UTC