Re: [csswg-drafts] [css-pseudo] `::before(<ident>)` / `::after(<ident>)`: A possible path forwards for multiple gencontent pseudos? (#13860)

@chriscoyier 
> Just wanted to note a thought I had about the placement of the pseudo-elements. It would be neat if they matched the `insertAdjacentHTML` JavaScript API.

I think pseudos *outside* the element would be much harder. Also, [internal consistency (within CSS) trumps external consistency (with JS)](https://www.w3.org/TR/design-principles/#consistency) so being consistent with `::before`/`::after` beats being consistent with a JS API (which wasn't even designed properly in a WG — it was shipped hastily by MSFT and then standardized post-hoc).

@emilio 
> My gut feeling is that this would tank performance linearly with the amount of identifiers you define.
> 
> If you define 3 of these "parametric pseudos" in order, you're basically forcing the engine to resolve 6 more styles per element, for all elements.

Wait, what? Why not 3? Defining a `::before(foo)` doesn't *also* create an `::after(foo)`. They are separate (and I suspect in most cases the intersection won't be too big).

Also, the alternative is not having nothing, it's doing it with HTML elements, but yeah, those are not per element for all elements... But do they really need to be there for all elements? Creating them lazily when they first get a non-`none` `content` value seems like a good optimization *anyway*.

> The other potential issue is that we probably wouldn't want `::before(foo)` rules to match generic `::before` rules, but given things like `*, *::before, *::after { box-sizing: border-box }` are so common, that probably means we want `::before(*)` or so as well...

That's an excellent point. Yes, we'd need a separate `::before(*)`/`::after(*)` for these. Though I don't think it's MVP, it _can_ ship later.




-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13860#issuecomment-4413020613 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 9 May 2026 16:41:20 UTC