Bug 240961 - `position: relative` doesn't work as expected on table row
Summary: `position: relative` doesn't work as expected on table row
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tables (show other bugs)
Version: Safari 15
Hardware: All All
: P2 Major
Assignee: Nobody
URL:
Keywords: BrowserCompat, InRadar
Depends on:
Blocks:
 
Reported: 2022-05-26 10:29 PDT by Benoît Rouleau
Modified: 2024-06-29 12:58 PDT (History)
13 users (show)

See Also:


Attachments
Example HTML file showcasing the issue (627 bytes, text/html)
2022-05-26 10:29 PDT, Benoît Rouleau
no flags Details
rendering in safari, firefox, chrome (211.12 KB, image/png)
2024-02-19 17:27 PST, Karl Dubost
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benoît Rouleau 2022-05-26 10:29:06 PDT
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!
Comment 1 Radar WebKit Bug Importer 2022-06-02 10:30:14 PDT
<rdar://problem/94294819>
Comment 2 MattC 2023-11-03 11:41:03 PDT
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.
Comment 3 Benoît Rouleau 2023-11-03 12:28:37 PDT
@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?
Comment 4 MattC 2023-11-03 12:43:57 PDT
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.
Comment 5 Karl Dubost 2024-02-19 17:27:14 PST
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
Comment 6 Karl Dubost 2024-02-19 17:34:05 PST
Benoit,
Is there a website currently which can't use this because of this bug?

That's indeed bad.
Comment 7 Karl Dubost 2024-02-19 17:35:38 PST
I wonder if it's related to Bug 188775.
Comment 8 Benoît Rouleau 2024-02-19 17:56:53 PST
(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.
Comment 9 Fabien Basmaison 2024-02-20 04:25:43 PST
(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.
Comment 10 Adrian Roselli 2024-02-20 09:57:25 PST
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.
Comment 11 Karl Dubost 2024-02-20 19:08:59 PST
Thanks Adrian,
This helps to understand too.
Comment 12 MattC 2024-02-21 04:56:10 PST
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.
Comment 13 Anthony Ricaud 2024-02-27 13:35:22 PST
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.
Comment 15 Benoît Rouleau 2024-03-20 10:01:37 PDT Comment hidden (obsolete)