Bug 240961 – `position: relative` doesn't work as expected on table row

• Component: Tables
• Status: NEW

[Benoît Rouleau]

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!

[Radar WebKit Bug Importer]

<rdar://problem/94294819>

[MattC]

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.

[Benoît Rouleau]

@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?

[MattC]

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.

[Karl Dubost]

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

[Karl Dubost]

Benoit,
Is there a website currently which can't use this because of this bug?

That's indeed bad.

[Karl Dubost]

I wonder if it's related to Bug 188775.

[Benoît Rouleau]

(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.

[Fabien Basmaison]

(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.

[Adrian Roselli]

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.

[Karl Dubost]

Thanks Adrian,
This helps to understand too.

[MattC]

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.

[Anthony Ricaud]

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.

[Benoît Rouleau]

Uh oh. The bots are here.

[Benoît Rouleau]

Some good table improvements/fixes in Safari 18.4 (https://share.cleanshot.com/QRnmkrg2). Hopefully, this one is addressed soon.

[Moubeen awan]

We had the same problem which we mentioned here: Hopefully they will resolve it soon: https://bugs.webkit.org/show_bug.cgi?id=291407

[Karl Dubost]

*** Bug 291407 has been marked as a duplicate of this bug. ***

[Moubeen awan]

Great work you did, can you please let me know when it will be fixed. @Karl

[Karl Dubost]

This was fixed on Chrome on May 22, 2021 by their new Table Layout engine. 
https://issues.chromium.org/issues/40386053


This is described by 4.2. With a table-internal as containing block

> If an absolutely positioned element’s containing block is generated by a table-internal, the containing block corresponds to the area starting at the top left corner of the the area that would be assigned to the box during layout but whose size is computed to be the one of the area that would be assigned to the box during layout if all tracks were considered visible (irrespective of visibility being set co collapse on some boxes), not including borders and paddings as appropriate.
— https://drafts.csswg.org/css-tables-3/#abspos-boxes-in-table-internal

[Moubeen awan]

(y) So will the safari change the Table Layout engine?

[Adrian Roselli]

Yet another author has to rely on CSS hacks to work around this bug:
https://www.oidaisdes.org/table-with-clickable-rows.en/

Any timeline on getting this fixed in Safari / WebKit?