Created attachment 462510 [details] safari Interestingly, all three "major" browsers display this styling differently. 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. is this the spec, or a bug? Attaching screenshots for Safari, Chrome, and Firefox.
Created attachment 462511 [details] chrome
Created attachment 462512 [details] firefox
@Brandon - Can you attach any test case or URL to reproduce this issue? Thanks!
<rdar://problem/100519589>
@Ahmad Sorry for the huge delay, but I've finally managed to reproduce this in a more concise example for all three major browsers: This example uses Tailwind, but using the inspector, it should be clear what each class does: https://play.tailwindcss.com/tjDRHWiftz 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`.
** Also, make sure to widen the preview to desktop size, as the responsive mobile experience does not suffer from the same issue. Thanks!
Created attachment 464619 [details] WebKit Trunk vs FX Nightly 111 vs Chrome Canary 111 (In reply to Brandon McConnell from comment #6) > ** Also, make sure to widen the preview to desktop size, as the responsive > mobile experience does not suffer from the same issue. Thanks! Yes - I am able to reproduce this bug now and this is the output, I get based on WebKit trunk. Thanks for sharing test case. Appreciate it!
Created attachment 464621 [details] safari vs chrome with outline So interesting trying to reduce the test case. This will be hard because the layout is quite over-done, mixing pseudo-selector, position absolute and sticky and flex and grid and reset css, and other things. All of that inside an iframe. At least the iframe by itself has no impact on the layout. Also both firefox and safari have issues, so it could be that chrome has a bug and the layout benefits of this bug. Putting an outline helps to see what is happening with the boxes. we can see that on both side the rounded corners are not visible because something is hiding the edge on both sides. That could be because of ::before, ::after style. For example could the clip path be one of the issues. ``` .before\:\[clip-path\:polygon\(0\%_1px\,0\%_100\%\,0\.5rem_100\%\,0\.5rem_1px\,calc\(100\%_-_0\.5rem\)_1px\,calc\(100\%_-_0\.5rem\)_100\%\,100\%_100\%\,100\%_1px\)\]::before { content: var(--tw-content); -webkit-clip-path: polygon(0% 1px,0% 100%,0.5rem 100%,0.5rem 1px,calc(100% - 0.5rem) 1px,calc(100% - 0.5rem) 100%,100% 100%,100% 1px); clip-path: polygon(0% 1px,0% 100%,0.5rem 100%,0.5rem 1px,calc(100% - 0.5rem) 1px,calc(100% - 0.5rem) 100%,100% 100%,100% 1px); } ``` If I change the clip-path to be ``` .before\:\[clip-path\:polygon\(0\%_1px\,0\%_100\%\,0\.5rem_100\%\,0\.5rem_1px\,calc\(100\%_-_0\.5rem\)_1px\,calc\(100\%_-_0\.5rem\)_100\%\,100\%_100\%\,100\%_1px\)\]::before { content: var(--tw-content); clip-path: polygon(0% 1px,0% 100%,0.5rem 100%,0.5rem 1px,100% 1px,100% 100%,100% 100%,100% 1px); } ``` aka removing the calc to be 100% I suddenly get the full box on the right side. PS: the 3 vertical dots SVG inside the button element would benefit from a `height: 100%`
Thank you, Ahmad! I really appreciate your help in looking into and resolving this. Safari and Firefox have slightly different issues, though I think Chrome is the one doing it correctly here, with my knowledge of pseudo-elements. 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. So yes, while it is the `clip-path` doing the hiding of those sides, the hiding is intentional. The real issue here is the height not being the intended 50% of its parent in either Safari or Firefox. Here is an image that demonstrates what the height of the `::before` pseudo-element was intended to be in this case and appears in Chrome: https://i.imgur.com/JoZhLoO.png
Mozilla bug reported: https://bugzilla.mozilla.org/show_bug.cgi?id=1813676 — Also, can we please have the assignee shifted from Nobody to Ahmad so that we don't lose track of this bug?
(In reply to Brandon McConnell from comment #10) > Mozilla bug reported: https://bugzilla.mozilla.org/show_bug.cgi?id=1813676 > > — > Also, can we please have the assignee shifted from Nobody to Ahmad so that > we don't lose track of this bug? Hi Brandon, I am not working on this right now and my skill-set is still newbie level. :-( It would be better handled by someone familiar with CSS or Layout & Rendering code. :-)
Ah, I see. Ahmad, is there any way we could get this bug prioritized since it affects standard CSS layout rendering in production browsers?
Upon further investigation, it appears that Firefox also sizes the element properly, but Firefox's main rendering issue here is actually the z-index layering. In that regard, it appears Safari has both issues— the sizing and the layering, as Safari appears to (a) layer the pseudo-element in front and also (b) size it not based on a percentage of its sticky parent, but its grandparent, the `table` itself. 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 – Safari: https://i.imgur.com/vticbqC.png – Firefox: https://i.imgur.com/YI01ram.png
It seems bug 258372 slightly makes it better and make us match behavior of Firefox, which again is not ideal but still better than current IMO. Will attach screenshot of local build with the fix from bug 258372 for reference.
Created attachment 466794 [details] Matching Firefox after bug 258372 patch on WebKit ToT Using Test case: https://codepen.io/brandonmcconnell/full/poZxVyR/eed0f1933bced0e2978d6a135e72ecc8
@Ahmad is there any more internally on this to bring this up to speed with Chromium?
Created attachment 470707 [details] rendering in safari, firefox, chrome Safari Technology Preview 191 19619.1.6.3 Firefox Nightly 126.0a1 12624.3.25 Google Chrome Canary 125.0.6392.0 6392.0