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

[whatwg] Early feedback on header association algorithm

From: Aaron Leventhal <aaronlev@moonset.net>
Date: Tue, 02 Dec 2008 09:39:06 +0100
Message-ID: <4934F42A.703@moonset.net>
Maybe there is a deeper problem if copy & paste doesn't work right 
because of IDs?

Or maybe there should be a node.getDescendantById() method?

I don't know. It just seems odd to implement something special here for 
that.

- Aaron

On 11/22/2008 3:06 PM, Henri Sivonen wrote:
> On Nov 22, 2008, at 15:50, Henri Sivonen wrote:
>
>> 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.
>
>
> Oops. I didn't read the text I quoted properly. Sorry. #2 was already 
> dealt with.
>
> However, wouldn't testing if the cell is in the current table already 
> go a long way towards the complexity of implementing 
> getElementByIdInTable?
>
Received on Tuesday, 2 December 2008 00:39:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:46 UTC