[Webkit-unassigned] [Bug 136818] [AX] Improve AccessibilityTableCell columnHeaders and rowHeaders functions.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Sep 16 03:48:41 PDT 2014


https://bugs.webkit.org/show_bug.cgi?id=136818





--- Comment #9 from Andrzej Badowski <a.badowski at samsung.com>  2014-09-16 03:48:42 PST ---
(From update of attachment 238124)
View in context: https://bugs.webkit.org/attachment.cgi?id=238124&action=review

>> Source/WebCore/accessibility/AccessibilityTableCell.cpp:140
>> +    if (scope == "row" || scope == "rowgroup")
> 
> It seems like this will invalidate the existing logic
> if ("rowgroup" && isTableCellInSameRowGroup(tableCell)

I don't think so, because the existing logic: if ("rowgroup" && isTableCellInSameRowGroup(tableCell)) is checked at the beginning of the function rowHeaders and only then is invoked function isRowHeaderCell. This last function is a more general purpose.

>> Source/WebCore/accessibility/AccessibilityTableCell.cpp:145
>> +    while (parentNode) {
> 
> this should be written as a for loop. 
> also, you're getting the parentNode at a bad time, because when the parentNode() returns 0, you'll then crash on the next line
>    if (parentNode->hasTagName(...

You're right with "at a bad time".

>> Source/WebCore/accessibility/AccessibilityTableCell.cpp:146
>> +        parentNode = parentNode->parentNode();
> 
> what is the provenance of this logic? Is there something in the spec that says a cell in a tfooter or body is a row header?

Please note that this decision takes place at a time when it is already known that this cell had no another markings on rowheader.
I think it is worth at this point exclude the scope of two types: "col" and "colgroup".
It remains a situation in which the cell must be resolved th type with no support in the specification.
It seems logical that such a cell in the thead (header across the table) is column header. 
Also for me it was logical that since in the table was separated tbody area, this is an area on rows of data. th element will probably be at the beginning of a row as the first cell or the first cells.
I imagine the situation that in the summary of table, for which a good place seems to be tfoot, the first th cell will be logically rowheader. 
I think that to have columnheader in tfoot / tbody, it must be specially marked. 
Likewise, I think that if the author put in the code html th tags inside rows within tbody or tfoot and he did not identify them extra, it has the right to expect to qualify them in any way.

As a simple illustration for the above sentences I quote the code and the appearance of a table taken from the attached test, supplemented by tfoot:
<table id="table1">
  <thead>
  <tr>
    <th>No</th>
    <th>Country</th>
    <th>Capital</th>
  </tr>
  </thead>
  <tbody>
  <tr>
    <th>1.</th>
    <td>Poland</td>
    <td>Warsaw</td>
  </tr>
  <tr>
    <th>2.</th>
    <td>Russia</td>
    <td>Moscow</td>
  </tr>
   <tr>
    <th>3.</th>
    <td>Ukraine</td>
    <td>Kiev</td>
  </tr>
  </tbody>
  <tfoot>
   <th>All</th><td>3 countries</td><td>3 capitals</td>
  </tfoot>
</table>

No    Country    Capital
1.    Poland    Warsaw
2.    Russia    Moscow
3.    Ukraine    Kiev
All    3 countries    3 capitals

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list