Re: Table feedback

Ian Hickson wrote:
> I have reversed the way the algorithm is presented

For what it's worth, I find the headers->data direction easier to follow. As 
an author I guess that's inevitable. I guess it's also inevitable that 
implementors will have the opposite perspective as they are working at the 
opposite end.

Ian Hickson wrote:
> Ben's research was instrumental to the changes made here; his research
> probably had more of an effect on the spec than all the other
> discussions put together. I cannot emphasise enough how much more
> important objective analysis and logical argumentation is compared to
> opinions and assertions.

Woot! :D  I'll start a new funding search after Xmas so that, hopefully, 
you'll be getting more stuff like this from me.

In the new algorithm:

[[[
7. If there is no cell covering slot (x, y) [...] return to the substep 
marked loop."

--  
<http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#header-and-data-cell-semantics>
]]]

I understand this can arise when the cells (<th> and <td> elements) do not 
fill all the slots in a row (<tr> elements):

<http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#processing-model-0>

My understanding is that ATs treat slots with no cell as if they had an 
empty cell. This lets users move through (or along) "gaps" at the ends of 
rows without the row being skipped or the user needing to detour around the 
missing cells.

If this is the case with ATs, slots with no cell should get associations as 
if they were an empty cell? (I have no direct access to ATs to test if this 
is actually the case.)

I'm not sure what should happen to overlapping cells. My guess is that both 
lists of header cells are expected to apply to the overlapping slot. Either 
way, overlapping cells are so rare that I don't recall encountering any 
during my own research.

Ian Hickson wrote:
> [...] it required the algorithm to now make a decision about whether cells 
> are column headers or row headers  [...]
>
> Thus, the algorithm is likely going to support far fewer table types 
> without attributes, which is going to result in a net decrease in the 
> number of tables that are accessible.

Which types are those?

The new definitions in HTML5 look straightforward, intuitive and like 
they'll be reliable. I expect James understands the exact logic Smart 
Headers uses better than I but I think the new logic in HTML5 is, in effect, 
the same.

-- 
Ben Millard
<http://projectcerbera.com/web/study/>

Received on Thursday, 25 December 2008 10:37:21 UTC