Bug 276304

Summary: ::before ist more a piece of “::behind”
Product: WebKit Reporter: stevestasteislost
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: ahmad.saleem792, bfulgham, karlcow, simon.fraser, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: Safari 17   
Hardware: Unspecified   
OS: macOS 13   
Attachments:
Description Flags
rendering in safari, firefox, chrome none

Description stevestasteislost 2024-07-07 23:17:56 PDT 
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”.
Comment 1 Simon Fraser (smfr) 2024-07-08 10:25:15 PDT 
Could you please attach a standalone HTML document that shows the bug?
Comment 2 stevestasteislost 2024-07-08 13:49:43 PDT 
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>
Comment 3 Radar WebKit Bug Importer 2024-07-14 23:18:13 PDT 
<rdar://problem/131735186>
Comment 4 Ahmad Saleem 2024-07-15 08:19:59 PDT 
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?
Comment 5 stevestasteislost 2024-07-15 08:32:25 PDT 
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 ?
Comment 6 Simon Fraser (smfr) 2024-07-15 13:33:15 PDT 
I am confused. What is the state of this bug?
Comment 7 Karl Dubost 2024-07-22 18:18:50 PDT 
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.