Re: summary attribute compromise proposal

Julian Reschke On 09-08-06 14.17:

> Sam Ruby wrote:
>> Julian Reschke wrote:
>>>
>>> For instance, the spec still states:
>>>
>>> "The summary  attribute on table elements was suggested in earlier 
>>> versions of the language as a technique for providing explanatory 
>>> text for complex tables for users of screen readers. One of the 
>>> techniques described  above should be used instead."
>>>
>>> ...which I think is the wrong thing to do if one believes that 
>>> @summary *does* have a special purpose for screen readers, which none 
>>> of the alternatives have.
>>
>>  From RFC 2119:
>>
>>   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.
>>
>> Perhaps this could be reinforced by adding the word "often" after the 
>> word "should".
> 
> I don't think that citing RFC 2119 is helpful here :-) Here's my 
> response...:
> 
> --- snip ---
> 6. Guidance in the use of these Imperatives
> 
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.
> --- snip ---


In that regard: the draft says that UAs MAY present @summary. I 
wonder if this is *predictable* enough? SHOULD seems righter.

The reason for not saying MUST are:

* to avoid duplication: if one of the new recommended methods have 
been used, and the UA is able to identify and support those.
* that some tables in fact are layout tables.
-- 
leif halvard silli

Received on Thursday, 6 August 2009 12:39:32 UTC