W3C home > Mailing lists > Public > public-html@w3.org > January 2008

Re: ISSUE-20 (table-headers): Improvements to the table-headers algorithm in the HTML 5 spec [HTML 5 spec]

From: James Graham <jg307@cam.ac.uk>
Date: Mon, 28 Jan 2008 23:13:49 +0000
Message-ID: <479E61AD.2020004@cam.ac.uk>
To: Ben 'Cerbera' Millard <cerbera@projectcerbera.com>
CC: HTMLWG <public-html@w3.org>

Ben 'Cerbera' Millard wrote:
>
>> Raised by: James Graham
>> On product: HTML 5 spec
>> [...]
>> The algorithm to establish cell-header relationships in the absence 
>> of specific scoping for header cells can probably be improved in line 
>> with suggestions in the following urls:
>> <http://lists.w3.org/Archives/Public/public-html/2007Sep/0134.html>
>> <http://projectcerbera.com/blog/2007/11#day09>
I have now updated the code Table Inspector code (Web interface [1],  
svn [2]) to add a "smart *span" algorithm (just called "Smart Headers") 
which works along both table axes, takes account of the scope attribute 
and the headers attribute. I am getting close to the stage where I will 
write the behavior up formally in an appropriate level of detail for 
Hixie/Hyatt to draft spec text from (assuming we get some agreement that 
this approach is worth pursuing as a replacement for the existing spec 
for associating header cells with data cells). Therefore I'm 
particularly interested in feedback about cases where the algorithm 
breaks down.

Some random details:

@headers is supported. The attribute's value is split on whitespace and 
each resulting token is used as an id for getElementById on the subtree 
rooted at the <table> element. If a match is found that header is 
associated with the cell. If no match is found the token is ignored. If 
any headings are found from @headers, no other header associations are 
applied to that cell (I believe this is necessary for the few legitimate 
@headers use cases)

@scope is supported. The possible values are:

row - the smart *span algorithm is only applied across each row spanned 
by a header to determine which cells it associates with.  No column 
associations are made.
col - as for row but down columns
rowgroup - headers apply to all cells in their rowroup that on the same 
row or column as, or below and to the right of, the header
colgroup - headers apply to all cells in all the colgroups the header 
spans that are in the same row or column as, or below and to the right 
of, the header

With the smart span algorithm, rows or columns containing only headers 
do not get associated with other headers on that row/col unless the 
header had a specific @scope set.
Headers are never headed by other headers with smaller *span (actually 
this is not quite what is implemented at present but that's a bug). This 
is so wide headers that span the whole table are not associated with 
every individual column header, for example (see [3] for an example of 
the importance of this)

Some questions:
Should scope=row/col override the smart algorithm and just apply to all 
cells to the right/below a given header?
How should colgroup/rowgroup work? What do people actually want to use 
those values for? I don't have a clear idea of when they are still 
needed with the smart algorithm.
Should a missing id in @headers cause the whole value to be ignored and 
the ordinary algorithms to apply?

Some notes on conformance:
Since this is sure to come up again, I may as well state here that I 
think there is a case to be made that @headers be made conforming with 
the proviso that it SHOULD NOT (in the RFC2119 sense) be used if the 
author can achieve the same effect by other means. This has several 
advantages:
a) It allows the small number of use cases that require @headers to be 
supported in HTML at little cost to the client
b) It strongly discourages authors (particularly those who care about 
accessibility since they tend to be unusually conscientious about 
sticking to standards) from using @headers except when absolutely 
necessary -- a positive thing for end users because evidence suggests 
@headers is a particularly fragile markup construct that often results 
in the wrong information in the UA.
c) It allows enough wiggle room that he use of @headers to serve content 
to legacy clients that cannot understand more author-friendly syntaxes 
is allowed.


[1] http://james.html5.org/tables/table_inspector.html
[2] http://html5.googlecode.com/svn/trunk/tables/
[3] 
http://james.html5.org/cgi-bin/tables/table_inspector.py?uri=http%253A%252F%252Fsitesurgeon.co.uk%252Ftables%252Ftides%252Fminimal.html&source=&algorithm=smartheaders
Received on Monday, 28 January 2008 23:14:10 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:29 UTC