Bug 240961

Summary: `position: relative` doesn't work as expected on table row
Product: WebKit Reporter: Benoît Rouleau <benoit.rouleau>
Component: TablesAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Major CC: anonymousert2120+5, aroselli, contact, dev, karlcow, matt, rik, simon.fraser, webkit-bug-importer, yivarak978, zalan
Priority: P2 Keywords: BrowserCompat, InRadar
Version: Safari 15   
Hardware: All   
OS: All   
Attachments:
Description Flags
Example HTML file showcasing the issue
none
rendering in safari, firefox, chrome none

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)
Comment 16 Jekkerdes 2024-03-28 11:24:56 PDT
I'm investigating an issue (Bug 240961) where the position: relative property seems to be malfunctioning when applied to table rows. This is causing unexpected behavior. I'll delve https://www.linkedin.com/pulse/5-best-personal-statement-writing-services-experts-review-mary-walton-8cq5e deeper to pinpoint the exact cause and determine a solution.