Re: table headers - clear description of problem

HI Ian,

On Aug 25, 2008, at 2:58 PM, Laura Carlson wrote:

>
> Ian wrote:
>
>> If that is the problem with the headers issue, then there isn't a  
>> problem
>> as far as I can tell. Just the normal issue of implementations not  
>> yet
>> being complete, and issue that will hopefully go away as  
>> implementors add
>> support for HTML5.
>
> PFWG's advice stated,
> "AT have small markets; they can only afford easy algorithms. The
> reason that 'headers' got picked up rapidly and 'scope' didn't was in
> part the following peformance comparison: The screen reader had a
> table cell in its sights, and had received a 'hunh?' query from its
> user. It needed to contextualize this table cell. To answer this query
> by 'scope' the AT would have to search the table for TH cells (often
> misused for styling) and then check the 'scope' on each. If the author
> used 'headers' there was an attribute on the object at hand pointing
> to a short list of what more to say".
>
> Also:
> "A disability constituency currently uses and depends on this feature:
> anyone offering to remove it should be expected to demonstrate that
> the replacement works better and is in service. Dropping 'headers'
> because 'scope' could afford the same semantics in 'most of the cases'
> is a wrong decision; now or, taken in isolation, for the future. The
> headers/id technique provides functionality today. If it is to be
> worked out of the system, it should not be an abrupt drop. Transition
> it out with something better in an orderly and graceful manner."
> http://lists.w3.org/Archives/Public/public-html/2007Jun/0145.html
>
> Grandfather it into the spec until it can be demonstrated that the
> HTML5 replacement works better and is in service.

Taking a more forward looking approach, there are several problems  
with the current HTML5 draft and James Graham/Ben Millard's approach.

  1) neither adequately account for the need to have headers  
associated with data cell that are also data cells (key data cell that  
should be queryable of their own associated headers as well as serving  
as associated headers for other data cells)
  2) neither deal with the ambiguities of scope and the fact that  
scope can easily lead to errant header associations when using the  
'colgroup' and 'rowgroup' keywords (see the wiki for more[1])
  3) the HTML5 draft fails to provide support for the headers  
attribute which can often make table authoring simpler than relying on  
scope or other cumbersome structural changes to the table
  4) neither support the use of the headers attribute for hierarchical  
headers where a subsection of the table can rely on the header  
association algorithm to associate data cells with the first (lowest)  
level of headers while pointing those headers to the next hierarchical  
level of headers and so on. This facilitates a much simpler way to  
author complex tables than using scope or headers attributes  
everywhere. Also my understanding is that this approach is already  
supported by at least some AT though not specified in HTML4.

Henri on IRC mentioned the goal of "making simple things easy and  
complex things possible" with regard to the HTML5 tables[2]. However,  
up until now the goal has been to make really easy things easy and  
anything more complicated impossible.

Take care,
Rob

[1] <http://esw.w3.org/topic/HTML/TableHeaderCellScope>
[2]: <http://krijnhoetmer.nl/irc-logs/whatwg/20080825#l-485>

Received on Monday, 25 August 2008 12:30:02 UTC