Created attachment 459789 [details] Example HTML file showcasing the issue When trying to absolute-position an element relative to the nearest `position: relative` table row (`tr`), it skips the `tr` and positions it relative to the next ancestor with `position: relative`. In the example HTML file provided, it positions it relative to the document because there is no other ancestor with `position: relative`. Open this file in Safari, Chrome, and Firefox, and you'll see that Safari is the only one that has this issue. Thank you!
<rdar://problem/94294819>
The workaround is to put position:relative into a grandparent instead of the <TR> parent element. In my case this was the table <TABLE> element. This worked fine.
@MattC, the `<table>` element contains all the rows. What if you want something to be positioned to the top or bottom of a specific row?
Benoit, You are correct that this workaround would surely not work in all cases. In my case I only needed the position:absolute after the table's first table row.
Created attachment 469981 [details] rendering in safari, firefox, chrome Tested on Safari Technology Preview 188 19619.1.2.1.1 Firefox Nightly 125.0a1 12524.2.19 Google Chrome Canary 123.0.6311.0 6311.0
Benoit, Is there a website currently which can't use this because of this bug? That's indeed bad.
I wonder if it's related to Bug 188775.
(In reply to Karl Dubost from comment #6) > Benoit, > Is there a website currently which can't use this because of this bug? > > That's indeed bad. Thank you for looking into it. I'm not sure I understand your question. As a web developer, I have often wanted to position an element relative to a table row, but I've had to use hacky workarounds because of this bug. So I can't link you to a website in production that is broken because of it. The main use case for me is a link that spans the whole row.
(In reply to Karl Dubost from comment #6) > Is there a website currently which can't use this because of this bug? Adding to what Benoît describes, we also would like full-width links on a row, and have styles effects on the whole row when hovering it. The current implementation needs to style each cell of the row individually, with all the CSS tweaks necessary to handle overlapping styles between cells.
I continually run into cases where developers want an entire row in a table to be "clickable" for a single checkbox and, since table rows are not interactive elements and that flags automated accessibility tools, they convert the tables to ARIA grids. The simple way to address this (and not make an inaccessible experience for screen reader users via a mis-placed `grid` role) is by expanding CSS generated content. However, that approach falls down without proper support for `position: relative`. Instead, an author must provide a `width` on the generated content, which can easily expand well past the bounds of the table. I walk through the pattern here: https://adrianroselli.com/2023/11/dont-turn-a-table-into-an-aria-grid-just-for-a-clickable-row.html With a demo (that is tweaked to not break in Safari): https://adrianroselli.com/demos/non-clickable-rows-that-are-clickable/index.html So, in short, there may be few sites who follow this pattern because of this bug and I know there are sites that incorrectly use `grid` roles and which may do so partly as a function of this bug.
Thanks Adrian, This helps to understand too.
While position attributes offer a lightweight prototyping technique for visualization, they may not be the best choice for production. In my case, the right justified close icon was finally relocated to a new display-conditioned table element.
Seems like this is covered by some WPT tests: https://wpt.fyi/results/css/css-position?label=master&label=experimental&aligned&q=position-relative-table And therefore related to bug 203449.
Uh oh. The bots are here.