Re: summary attribute compromise proposal

On Aug 4, 2009, at 3:29 PM, Roy T. Fielding wrote:

> 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.

Can you cite a reference for someone saying that? I think the case  
against summary is not that it fails to have any use whatsoever, but  
rather that there is some evidence that, on balance, as practiced, it  
does not promote good accessibility outcomes.

> 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.

WG consensus (or valid decision process if consensus can't be found)  
is needed for any decision. There is no "default to old spec version"  
exception in the W3C Process.

>
>>> 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.

I don't believe you have demonstrated that. Even in your example, a  
<caption> that's hidden from visual but not UAs via CSS would satisfy  
the use case. Further, even if you demonstrated that there are no  
alternatives in one particular use case, this would not demonstrate  
there are no alternatives for any use case, nor would it refute the  
case that the construct is error-prone. That being said, maybe a lot  
of the people who find summary problematic will see your example and  
reverse their position. Personally, I'm not holding my breath.


> 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.

Is it an error to advise authors to use CSS layout instead of layout  
tables, even though CSS can't necessarily replicate every layout that  
is possible with tables?

>
> 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.

You're welcome to make such proposals separately. I'm not sure all of  
those specific examples would get consensus. (I do think <canvas> with  
no fallback should be a warning or error.)

Regards,
Maciej

Received on Tuesday, 4 August 2009 22:46:11 UTC