[webkit-dev] Table hit testing

[David Hyatt]

On May 20, 2010, at 3:18 PM, David Hyatt wrote:

> On May 20, 2010, at 3:07 PM, David Hyatt wrote:
> 
>> If we could properly detect those degenerate cases, then you could probably get away with binary search, but until we do that, I don't think you can.
> 
> Here's an example:
> 
> <STYLE>
> TD:hover { color: green }
> </STYLE >
> <TABLE border="1">
> <TR><TD>1 <TD>2 <TD>3
> <TR><TD>4 <TD rowspan="2">5 <TD>6
> <TR><TD colspan="2">7 <TD>9
> </TABLE>
> 
> In this example, cell 5 and cell 7 actually overlap and share a position in the grid.  You can see that hit testing works properly and gives cell 7 precedence over cell 5 (e.g., if you're in overlapping background areas of the cell, then cell 7 wins).

This is all coming back to me now.

When two cells occupy the same position in the grid, only one of them gets stored at that position.  The current code puts the first cell encountered into the grid. This means if you ask what cell is present in row 3 and column 2 of the above example, you'll get back cell #5.

This actually makes the grid unsuitable for hit testing and is why I hadn't converted nodeAtPoint over to use the grid yet.

The grid needs to be fixed so that it records all of the cells present at a given position.  If it did that, then you could binary search as long as there are no overflowing cells, since you'd then be able to see all the cells that actually occupy a given grid position.

The paint method uses the grid and actually has a repaint bug, since if you make the repaint rect tight enough, it won't think it has to paint the second and subsequent cells that occupy a given grid position.

dave
(hyatt at apple.com)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100520/4e2bf3cf/attachment.html>