Re: Summary of Thursday's IRC conversation about @summary

Henri Sivonen wrote:
> On Jun 8, 2009, at 16:41, Shelley Powers wrote:
>
>> Henri Sivonen wrote:
>>> On Jun 8, 2009, at 15:11, Shelley Powers wrote:
>>>
>>>> Henri, your reasoning is a little flawed here.
>>>>
>>>> A statement has been made that the attribute isn't being used, but 
>>>> then you're saying that authors are expending effort on the 
>>>> attribute, which is the same as saying, it is being used. Which is 
>>>> it? Is it being used, or not?
>>>
>>> If authors put *something* in the attribute but either AT heuristics 
>>> suppress the attribute or users disregard the attribute, it is being 
>>> used but is not useful.
>>
>> The majority of uses of summary are blank, appropriately so, because 
>> the majority (all, from what I've found so far) of uses where the 
>> summary is blank are in tables used for layout. It's difficult to 
>> define either usefulness or lack of same in this scenario. But the 
>> fact that AT heuristics disregard the attribute in these cases would 
>> seem to be useful, if we judge usefulness based on doing what they 
>> should properly be doing.
>
> Indeed, summary="" as a sign of a layout table seems useful assuming 
> that it is better supported by existing software than 
> role=presentation, but I wouldn't count summary='' as an example of 
> the attribute being used to give a longer-than-caption summary of a 
> data table.
>
I'm sorry, I'm not sure what your argument is here.
>>>> Then the argument is given that those who want to keep the summary 
>>>> attribute have to perform research far beyond anything being done 
>>>> with any other aspect of HTML5,
>>>
>>> Well, personally, I'd have been convinced by something like asking a 
>>> few screen reader users to find out if they found table summaries to 
>>> be a net benefit. I guess I'll have to trust the 3 opinions Steve 
>>> relayed, although I still don't comprehend where the useful 
>>> summaries are found when the data I can check (Philip's data) shows 
>>> a mountain of bad summaries--not a mixed mountain where the bad 
>>> could be pruned automatically out leaving a pile of good ones. 
>>> (Unless, of course, a summary such as "Calendar" counts as a good 
>>> summary despite not being the kind of summary that a summary is 
>>> supposed to be per best-practice examples.)
>>>
>> Calendar with links is useful and is also in the list.
>
> My point is that summary="Calendar" doesn't seem to conform to how 
> summary is supposed to be used properly. (It's a short caption rather 
> than a long summary of contents.)
>
>> Again, referencing my earlier argument, how many good uses of TABLE 
>> can you find in the list?
>
> Very, very, few other than the blog sidebar calendars. (I found two 
> before giving up.)
>
> Which raises the question: If @summary is almost always used on layout 
> tables instead of data tables, is it solving the problem that it is 
> supposed to solve: providing a summary for complex data tables?

Henri, your argument's logic is flawed. The majority of table usage is 
for table layout, so it's not surprising that the majority of summary 
usage is on tables being used for layout. Your logic states:

Most HTML tables are being used for layout.
A certain percentage of HTML tables have an associated summary.
Therefore, summary isn't solving the problem it is supposed to solve, 
which is provide a summary for complex data tables.

Non sequitur
>
> Obviously, tables are used "incorrectly" so often that it makes more 
> sense to develop ways to deal with the incorrect use on the client 
> side (detect layout tables and linearize them for AT use or for 
> small-screen mobile use) than to try to "educate" the whole world not 
> to use layout tables. I don't conclude that the solution to use of 
> tables for layout is education.
>

What does this have to do with @summary? I agree, disregard the table 
components when parsing a layout table.

Um, good luck with that.
>> Seems that we have a lot of education to do across the board. That's 
>> where providing good examples and descriptions in the HTML5 
>> specification (and associated primer) would go a long way to ensure 
>> proper use of @summary. We also need to work on educating developers 
>> for the more popular content management systems, such as Drupal and 
>> Wordpress, in how to incorporate @summary and CAPTION properly when 
>> creating modules or plug-ins that generate HTML content. Not to 
>> mention authoring tools, like Dreamweaver.
>
> Why hasn't all this already happened given that @summary has been in 
> HTML 4 for a decade? How long is it going to take?
>
How long is it going to take people to use tables correctly? How long is 
it going to take people to stop writing JavaScript that opens big, 
gaping holes in their applications? How long is it going to take, until 
companies stop inserting so much crap in their pages that it breaks 
Firefox every time I visit the pages? How long until dial up is gone? 
How long until broadband usage is ubiquitous? How long will it take 
Microsoft to implement SVG?

How long until people stop using IE6?

Believe it or not, ten years is not all that long. You're viewing 
internet time as one immersed in the workings of the web, and overly 
influenced by the speed of new web technology development. The majority 
of people using the internet--those not using Twitter--have a more 
realistic view of the web, and its evolution.

Let's leave the land of "what ifs" and "why nots" and return to cold, 
hard facts.

The premise behind removing @summary is that it is "harmful". I've not 
seen one case put forward that proves, beyond a doubt, that @summary is 
"harmful".

 
>> As an aside to this discussion, not specifically addressing anything 
>> you wrote Henri, one other argument that has been put forth is that 
>> the text needs to be visible, in order to ensure that the field is 
>> used correctly. That one makes me a little uncomfortable. When I read 
>> this argument, it seems, to me, to have an underlying philosophy that 
>> a field designed specifically for those who can't see is not 
>> inherently useful. That may not be the intent of the argument, but I 
>> have a feeling an argument like this will end up biting the W3C in 
>> the butt.
>
> No, that's not the argument. The argument is that if the sighted 
> maintainer of the page reviews only 'visible' parts of the page, the 
> 'invisible' parts get out of sync when the page is maintained.
That may be the impetus behind the moves, but do not discount how others 
outside of this decision process will perceive these moves.

As for the reality of the claim, to repeat the salient point of this 
discussion:

The premise behind removing @summary is that it is "harmful". I've not 
seen one case put forward that proves, beyond a doubt, that @summary is 
"harmful".


Shelley

Received on Monday, 8 June 2009 14:53:40 UTC