Re: retention of summary attribute for TABLE element

At 09:32 +0100 UTC, on 2007-06-11, James Graham wrote:

[...]

> ; according to [1] @summary is
> present on about 2.5% of tables

As it makes no sense to provide a summary attribute with 'lay-out tables', it
seems to me you'd have to only consider tables that actually contain tabular
data. I wouldn't be surprised if only 1 in every 500 tables contains tabular
data. So unless this was taken into account, that 2.5% is a useless number
for this discussion. The relevant number must be much higher. (If we are to
rely on Google's stats at all.)

[...]

> + backward compatibility requirements rather than HTML4 directly. It
> seems like some of the problems could be solved automatically e.g.
> saying how many rows and columns are in the table. Is this not the case?

Agreed. The more the UA does the work, the better. Easier for authors and
thus fewer mistakes, and a more  consistent behaviour/UI for the end user.
Not to mention that this would work for every table, not just those that the
author bothered to provide the extra's for.

However, as long as there is so much abuse still of tables for lay-out
purposes, it might be impossible for a UA to know when to provide such
autocalculated data and when not to. Until that can be solved, we'll probably
have to continue to rely on authors providing this sort of data explicitly,
and provide them them with the means (through attributes like summary,
headers, etc. or better) to do so.

> If this can be done, the remaining problem sounds like it could be
> solved either through <caption> or another mechanism for associating
> text that is, by default, displayed in visual UAs with the table.

If the intention is to provide an alternative to "users who cannot see
relationships at a glance", then requiring that *alternative* to be provided
as visible data will get in the way of those users who don't need it. The
result will be that authors will not provide that information at all, or
abuse the element or attribute in question. (Consider requiring ALT text to
always be visible. It would only make authors abuse ALT.)

I agree that the concept of 'invisible' data has serious problems. It would
be great if we could solve those. But I don't think that simply requiring all
data to be visible is a solution. I have higher hopes that improved authoring
environments can do some good.

I mean, what exactly does "(in)visible" mean? My imptression is that it isn't
uncommon anymore for authors realise that it makes sense to set navigation
menus to display:none in print Style Sheets. On a conceptual level, that data
is then just as invisible as ALT text or a summary attribute are in the
average GUA. The only difference is that common tools as used by authors
today show them that data by default.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Thursday, 21 June 2007 07:15:44 UTC