Re: summary attribute compromise proposal

Maciej Stachowiak wrote:
> On Aug 5, 2009, at 4:16 PM, Ian Hickson wrote:
>> On Wed, 5 Aug 2009, Maciej Stachowiak wrote:
>>> Thus, I hope you will reconsider.
>> I've updated the spec to do what you proposed.
> Thanks. I read over your changes, and as far as I'm concerned, the new 
> spec text is in line with my compromise proposal.
> For anyone who would like to check, here's how summary is now defined in 
> the <table> section: 
> <> 
> And the only remaining mention in the "conforming but obsolete features" 
> section is a brief note indicating that the summary attribute gives a 
> warning: 
> <>. 
> I think this is the best arrangement we can get in terms of a compromise 
> that both sides can live with. I understand people have concerns with 
> various aspects. But I personally do not think I can push the proposal 
> much in either direction without completely losing the support of one 
> side or the other. So I strongly urge everyone to take time and consider 
> whether this is something they can live with. If anyone wants to ask for 
> more concessions, then I don't think I could lend my support such an 
> effort.

I appreciate the work that has been put into getting here, which is 
clearly better than what we had before.

Is it good enough? I don't think so.

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.

Furthermore, the spec still lists @summary under "obsolete but conforming".

BR, Julian

Received on Thursday, 6 August 2009 10:10:29 UTC