Safari doesn’t render ::before as said by https://drafts.csswg.org/css-pseudo/#generated-content: “… as if they were immediate children of their originating element …”. The result is: some of the ::before content runs into the (not-)parents area. Just as if the “parent” was set to relative positioning with an margin left, the ::before positioned absolute, but the reserved space to the left of the “parent” isn’t calculated correctly (sometimes?). I found this with this css: :where(article, section, footer, [popover]) { max-block-size: 90vb; ul { display: inline flex; gap: 0 1ch; flex-flow: row wrap; margin: 0; padding: 0; list-style-type: none; } li { display: inline flex; position: relative; } li { &:not(:last-of-type)::after { position: absolute; left: 100%; padding-inline: 0 1.5ch; content: ","; } &[alt]::before { content: attr(alt) ":"; display: block; font-size: 50%; font-stretch: condensed; } } } Result: the alt-attribute lays for approx. 2 characters behind it’s “parents” content. This thing is handled correctly by Firefox. But that’s not an “1:0” for it, more likely an “63:64”.
Could you please attach a standalone HTML document that shows the bug?
Ooops! While hunting another bug (FYI: https://developer.apple.com/forums/thread/745708) I missed “the meaning of relative/absolute” … Sorry for that! Of course you want to see “the real fun”? Here ist some of it: <head> <style> * { box-sizing: border-box; margin: 0; padding: 0; } body { /* max-block-size: 90vb !important; LOL: MAX! */ display: grid; grid-template: "h h h" 10vb /* 10 + … */ "m m a" 80vb /* 80 + … */ "m m a" 10vb /* 10 > 100! */ / 20vi auto 20vi; gap: 0.25lh 0.5ch; header { grid-area: h; inline-size: 100%; block-size: 100%; background-color: lime; } main { grid-area: m; background-color: rgb(from yellow r g b / 0.25); } aside { grid-area: a; inline-size: 100%; block-size: 100%; display: inline-flex; background-color: ivory; } counter-reset: total; /* LOL! What a joke! Counters! */ } ul { display: inline; color: white; background-color: rgb(from black r g b / 0.8); & > ul { background-color: rgb(from white r g b / 0.8); } flex-flow: column; li { display: inline flex; font-size: 2rem; list-style-type: none; &[alt]::before { content: attr(alt) ":"; color: red; } &::after { content: "[" counters(total, "①") ":" counters(subcount, "②") "]"; color: cyan; padding-inline: 0.5ch; font-size: 1rem; } &:not(:last-child)::after { /* nice: doesn’t disturb the above! */ content: ", "; font-size: revert; color: lime; } counter-increment: total, subcount; } counter-reset: subcount; } </style> </head> <body> <header>Showtime!</header> <main>Main thing.</main> <aside> <ul> <li>L. 1</li> <li alt="α">L. 2</li> <li> <ul> <li>L. 3</li> <li alt="β">L. 4</li> </ul> </li> <li>L. 5</li> </ul> </aside> </body>
<rdar://problem/131735186>
I changed comment 02 into JSfiddle here - https://jsfiddle.net/qbung8y1/ I am unable to find error / bug - Chrome Canary 128, Firefox Nightly 130 and Safari 17.6 looks same to me. Might be doing something wrong here. @Karl - can you double check please?
Hello! And: sorry! Did you notice my “Oops” (https://bugs.webkit.org/show_bug.cgi?id=276304#c2)? Yes, there is a problem (one?). But I “ran into blindness” while hunting the counters. So I didn’t think about the (in this place) silly positioning. Well, maybe you’re talking about counters. My english is poor, so I might misunderstand something. Of course you’re interested in this: https://bugs.webkit.org/show_bug.cgi?id=271526 ?
I am confused. What is the state of this bug?
Created attachment 471939 [details] rendering in safari, firefox, chrome > @Karl - can you double check please? This needs a reduced test case. I don't understand what the bug is about too. I also see no rendering differences in between Safari, Firefox and Chrome. Let's close. Steve, Thanks for the bug report! 1. Usually to make it easier to understand bugs, it's always better to have a very simplified test case. Attachments are better 2. To make a screenshot of the differences seen in between browsers. If you have a simplified test case illustrating the difference, we will gladly reopen.