1813676 - Can't z-order an absolutely positioned child behind table cell background, because nsTableFrame paints all backgrounds together.

Status: NEW

(Core :: Web Painting, defect)

Description

[Brandon McConnell]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36

Steps to reproduce:

It looks like percentage (%)-based sizes for absolute-positioned children under sticky elements are sized according to the closest "relative" parent's height and ignore the sticky parent's height, whereas other browsers use the sticky element's height.

Interestingly, all three "major" browsers display this styling differently.

Screenshots for Safari, Chrome, and Firefox:

– Chrome: https://bug-245496-attachments.webkit.org/attachment.cgi?id=462511
– Firefox: https://bug-245496-attachments.webkit.org/attachment.cgi?id=462512
– Safari: https://bug-245496-attachments.webkit.org/attachment.cgi?id=462510

Reproduction URL: https://play.tailwindcss.com/tjDRHWiftz

This example uses Tailwind, but using the inspector, it should be clear what each class does. Specifically, pay mind to the line where thead appears and the classes applied which affect the ::before pseudo-element. In Safari, it clips the much more than only that percentage of the thead.

The intention was to make the pseudo-element 50% of its parent's height (the thead), represented by the before:h-1/2 class, and then I use the complex clip-path class to shave off the sides of the pseudo-element.

** Also, make sure to widen the preview to desktop size, as the responsive mobile experience does not suffer from the same issue. Thanks!

WebKit Bug: https://bugs.webkit.org/show_bug.cgi?id=245496

Actual results:

The percentage height of the child element does not get sized based on the percentage of its absolute-positioned parent's height.

Expected results:

The percentage height of the child element should be sized based on the percentage of its absolute-positioned parent's height.

Comment 1

[Daniel Bodea [:danibodea]]

I do not possess the knowledge to properly confirm this report as a defect as there are no clear steps to take in order to reproduce it, but I will confirm it based on the technical discussions in the same bug reported to webkit. It appears that Chrome may be the one browser having the correct behavior of the 3.

This bug appears to appertain to the CSS component, but if incorrect, please set it to a more appropriate one.
Moreover, it was reproduced in Mac OS, but it may also affect other OSes.

Please NI me for more QA investigations if needed, but please provide clear steps to reproduce.

Comment 2

[Brandon McConnell]

Upon further investigation, it appears that Firefox sizes the element properly. The issue with Firefox's rendering is actually not the sizing but the z-index layering.

Because the thead::before pseudo-element uses z-index: -20;, it should display behind the thead, not in front of it, as demonstrated in this screenshot: https://bug-245496-attachments.webkit.org/attachment.cgi?id=464619

Here is a much simpler example using pure CSS which can be used for inspecting and testing: https://codepen.io/brandonmcconnell/full/poZxVyR/eed0f1933bced0e2978d6a135e72ecc8

Here are screenshots comparing this new example between the three major browsers:

– Chrome: https://i.imgur.com/9TDYiYb.png
– Firefox: https://i.imgur.com/YI01ram.png
– Safari: https://i.imgur.com/vticbqC.png

Comment 3

[Emilio Cobos Álvarez [:emilio]]

Table painting is a huge historical mess. Whether abspos sort along the same static context as table cells is a bit undefined IIRC. We draw all the table cell backgrounds together (see this), so that explains why you can't z-order your way out of it.

Re-titling, please correct if I got it wrong.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:tnikkel, could you have a look please?

For more information, please visit auto_nag documentation.