W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

[whatwg] Early feedback on header association algorithm

From: Henri Sivonen <hsivonen@iki.fi>
Date: Sat, 22 Nov 2008 15:50:21 +0200
Message-ID: <A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>
On Oct 29, 2008, at 19:43, Aaron Leventhal wrote:

> 1. On this part:
>        "If there is a header cell in the table <http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#concept-table 
> > whose corresponding |th <http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-th-element 
> >| element has an ID that is equal to the value of id, then assign  
> the first such header cell in tree order to the data cell. "
> I don't want to implement a special local table only  
> getElementByIdInTable. I'd rather have this reworded to something like
> "If there is an element in the document with a corresponding ID (via  
> getElementById) equal to the value of /id/, and it is a header cell  
> in the current table, then assign it to the data cell."


While implementing a special lookup method is something that one would  
want to avoid, using getElementById has two problems:

  1) It makes the association brittle under copy and paste. Consider a  
case where a page author creates a table with internal id references  
and then a maintainer duplicates the table and edits the contents of  
the copy table. Now the table coming later in the document order is  
inaccessible but this brokenness is unobvious to a person who isn't  
accessing the page with AT.

  2) It makes the reporting of table relationships not form a coherent  
table. Consider a program that instead of allowing the user to  
traverse the table an arc at a time tries to pull all the arcs from  
the accessibility API and reconstruct the table in its own process  
space. If there are arcs between tables, the result is not a table  
structure at all.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
Received on Saturday, 22 November 2008 05:50:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC