csswg-drafts
csswg-drafts copied to clipboard
w3c
[css-tables] Hit testing of table rows.
Consider this test-case (live):
<!doctype html>
<style>
table {
border-spacing: 100px;
border: 1px solid #ccc;
}
tr {
border: 1px solid #ddd;
background-color: blue;
}
td {
border: 1px solid #eee;
background-color: red;
}
</style>
<table>
<tr>
<td>A</td>
<td>B</td>
<td>C</td>
</tr>
</table>
<script>
document.addEventListener("click", function(e) {
console.log(e.target);
});
</script>
When you click in between the cells, right now all browsers log the <table>.
<tr>s also draw no backgrounds (though that's interoperable and more risky to change, and might make sense given how cell backgrounds are painted). But not hit-testing the <tr> when it does have a layout box and geometry (you can see that using getBoundingClientRect() etc) seems fairly weird tho.
Given it's interoperable, it might be worth at least specifying this (though maybe there's some appetite to change this?)
cc @bfgeek @FremyCompany @smfr
I think it's even more strange that with td { background: transparent } you can see the blue background from the row. But document.elementsFromPoint(120, 120) says [ td, table, body, html ], not including the row even if you can explicitly see it.
It's like rows get pointer-events: none or something.
Anyways, if we add hit-testing for table rows, probably should also add hit-testing for row groups, columns and column groups, according to this model: https://www.w3.org/TR/CSS22/tables.html#table-layers
Table rows do not draw their own backgrounds and borders, cells do. This is why it seems that the table row is there, but it's not.
Hit testing is not special, in theory: the root cause is that table rows currently do not have boxes (per CSS 2.1).
I have no strong opinion on whether table rows should have a real box or not (although I lean on "they should, even if they don't draw anything") but given they do not have boxes, it seems logical that they don't hit-test right now.
Now, the horrible part is that table-rows have so much behaviors that normally require them to have a box (like transform or position working on them) that it might be worth changing the behavior here and say that rows should have a box (breaking away with 2.1).
I doubt anyone depends on the click behavior between cells. I would rather let this behavior flow from our decision to (or not to) pretend table rows do not generate boxes.
Table rows clearly have to have boxes, since they have geometry. In all browsers getBoundingClientRect etc works on them.
Well, getBoundingClientRect support is a peculiarity. Both EdgeHTML and Blink have special codes for table tracks, I am afraid. Probably Webkit too, even though I haven't had feedback from anyone at Apple to confirm.
I am trying to convince @bfgeek that giving a box to table rows is the easiest way to get rid of this extra code, but so far he has resisted this, and getBoundingClientRect on table-tracks and table-track-groups in Blink is implemented through a special code that copies "special values", not through a box. (If I understood that correctly).
If you want to support me in my efforts to convince Ian to lean into it, and just make boxes for them, you have my warmest encouragement :)
🤔 Although, now that I think of it, maybe Ian's comment was only about table-column elements, and not table-rows.
Blink seems to create LayoutNGTableRow boxes (anonymous if necessary) and LayoutNGTableCol (only if there is an element with display: table-column).
Yeah columns - however we may make these fragments still - we'll see.
When I first saw this issue I quickly made a patch which removes the logic to exclude rows/sections here: https://chromium-review.googlesource.com/c/chromium/src/+/3933123
I didn't get to looking at all the failures - https://test-results.appspot.com/data/layout_results/linux-rel/1154279/blink_wpt_tests%20%28with%20patch%29/layout-test-results/results.html
Likely the issue is visibility:hidden not propagating into anonymous objects.
But we likely aren't compat constrained here, and if there was appitite I'd be happy to try and make tables less special in this regard.
Ian
