State of the art for children selectors (*:... / **:...)

[AtmoFX]

The documentation makes it clear "children can't override styles given to them by the parent", the reason being that "children rules are generated after the regular ones and they have the same specificity"

On the topic, I find the following issues / PR:

• [Dec 2017] Feature proposal: children variant #277
• [Jun 2020] Children selectors #1984
• [Nov 2021] Add children variant #6086
• [Dec 2023] Add * variant for targeting direct children #12551
• [Jul 2024] Reduce specificity of * variant #14056
• [Nov 2024] Increase specificity of * and ** variants #14920 (edit)

where I learned several solutions (changing specificity with :where, making use of @layer) have been considered too, each with their own downside. The above limitation was accepted when the selectors were introduced in v3 as a possibly temporary thing, until the release of v4 (released Jan 2025).

Yet, it seems v4 still carries the limitations + I suppose what was a breaking change in v3 has now become a breaking change in v4 too.

1. From the wording of the documentation, it looks like the children classes appearing below the regular classes is a deliberate decision, even though the first message I found, 6 years before the PR, clearly mentions it should be the opposite. I wonder what the rationale was to do it the "incorrect" way?
2. Is there any workaround for the generated CSS to allow override of a children rule? Maybe a selector I missed?
3. Is the reordering of rules something that is being considered, especially if the answer to 2. is "No"?

---

AFAICT, nobody has identified a downside to just outputing the children rules before the regular ones, in the sense that it would behave like we expect in every case, and this reordering was mentioned since the very beginning.

For context, I have created an example with descendent, child and state selectors and it really looks to me like ordering the rules is all it takes to get the expected result. The reordering of rules being (I think) the minimal possible change of precedence between rules, it is most likely the safest solution, assuming I am not missing anything.

[anntnzrb]

The * variant uses :is(& > *) (specificity 0,1,0) which prevents children from overriding parent styles - this was intentionally reverted in PR #14920 to match v3 behavior. Use arbitrary variants with :where() for overridable children:

<!-- Instead of *:flex (cannot be overridden) -->
<div class="[&>*]:where:flex">
  <div class="grid">I can override!</div>
</div>

Or create a custom variant: @custom-variant child (:where(& > *));

[AtmoFX]

Right, I had already mentioned earlier discussions identified downsides in alternative solutions such as :where, without explaining what that is.
But my point, really, was that the main solution to this problem (outputting child/descendent classes before regular rules), recommended from the very start (#277, written right into the initial message), does not appear to have anyone saying "doing so will break something because of ..."¹

As the output order is the last (i.e. least important) criterion in the CSS cascading order, this would be the solution with the smallest possible impact on the stylesheet.

Of course, I'm open to being given an example where changing the output order would create an issue¹ but I strongly doubt it.

---

¹ I am excluding from "break something" / "issue"a case where changing the output order, with no change in the HTML/JSX/... code, modifies the appearance of existing website.
The whole GOAL of reordering output is to change the appearance of websites for the same given input and in this context, I call that "correcting" instead of "breaking".
For the sake of discussing about issues, it should be limited to cases where a rendering that was possible before would become impossible to get after the change.