Re: function and impacts (was: @scope and @headers reform)

Laura Carlson 2008-09-24 01.38:

> James wrote:
> 
>> I trust the direction concerns will be addressed if you continue to
>> raise it for the HTML WG agenda.
> 
> How would the smart headers algorithm work on:
> 
> http://juicystudio.com/wcag/tables/altcomplex.html


How does it work with the /actual/ HTML 5 draft algorithm?

 
> In this example, a th in the middle of the table doesn't seem to work
> - no matter how clever the span algorithm is.
> 
> If the user chooses to put aggregate information at the end, putting
> headers in the middle of a table causes problems.


As long as one can put @headers on TH or on TD with @axis, then it 
does not necessarily create problems.  However, yes,  I must admit 
that using @headers/@id here have some advantages over using 
whether <TH> or <TD axis=""> that I did nto think of.

One really has two choices: Either one users the HTML 4 general 
algorithm, and prioritize to have as simple attribute usage as 
possible, up until and including the "Running Costs" columns. And 
then merely use primitive headers="" on the three last columns. (I 
have done that now. See below.)

Or one users @scope, and prioritize the over all table, and mark 
up that part in the middle with headers/id - like in Gez original.

 
> In this case, what is it a header for? The whole row? The whole
> column? Both would be wrong. The cells are labels with their own
> headings, and should be marked up with a td.

Exactly, that's a problem.

Hm. It seems as if the Table Inspector has an error here: It does 
not include the scope from the leftmost Partner Portal cells in 
its header interpretation. As a result, I had to reperform my 
tests, and I must now admit that the original table is much more 
optimal when it comes to  use of attributes than I realized.

It even seems as if @scope is a very good approach for this table. 
E.g it avoids that "Partner Portal" becomes the heading of 
"Partner Portal 2". (I am now discussing with the HTML 4 
algorithmi in mind.)

I have remade the table once more. It now users 44 hierarchical 
attributes. Same number as in Gez's table. (Perhaps I could have 
dropped a few of those attributes, though.)

Unless the HTML 5 algorithm is updated with the conten of the HTML 
4 algorithm, such a solution will not be possible in HTML 5.

http://www.malform.no/html5/juicy-fewer-attributes
http://tinyurl.com/juicy-simplfied-algorithm-HTML

I'll leave it to others to defend the Smart algorithm. However, 
you have convinced me that using @headers/@id, in order to avoid 
both <th> and <td axis="">, can be really important.

Thus I think that headers="data-cell" has a role to play, even 
without @axis.

[ snip ]

> A Two Step Solution is Proposed in the Wiki [1]
> 
>    1. Reinstate headers/id AND their functionality into the spec by
> specifically stating that headers are allowed to reference a td.
> Reword the current definition of the headers attribute so that each of
> the space separated tokens must have the value of the ID value of a th
> or td element. See the ACTION 72: @headers rewrite deliverable [2].
>    2. Introduce a new type of table cell which automatically acts as
> both a header and a data cell without any explicit accessibility
> attributes or without any explicit associations (as the editor
> proposed in bug 5822) [3] . Note: This step doesn't help describe
> irregular tables and it doesn't work right now with AT, whereas
> headers/id does.

 > [3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822#c14

Regarding step 2: That new type of table cell seems to have much 
similarity with how <td axis=""> cells works.  (Whether @axis 
cells "already works", or not, in existing AT software, is another 
question that perhaps some knows?)

Bt it is clear that if the basis is @scope and if the general 
heading association algorithm of HTML 4 is killed off, then one 
needs @headers/@id, including headers="data-cell" to do "irregular 
tables".
-- 
leif halvard silli

Received on Wednesday, 24 September 2008 05:04:20 UTC