Fix :active being outranked by :hover in a media query - #1789
Open
alexcarpenter wants to merge 1 commit into
Open
Fix :active being outranked by :hover in a media query#1789alexcarpenter wants to merge 1 commit into
:active being outranked by :hover in a media query#1789alexcarpenter wants to merge 1 commit into
Conversation
Combining `"@media (hover: hover)"` with `:active` on the same property meant `:active` never applied, because two separate mechanisms both favored the hover rule: - Specificity: the class name was repeated once per at-rule, so the hover rule was `.x.x:hover` (0,3,0) against `.y:active` (0,2,0). Specificity beats source order, so `:active` could not win regardless of insertion order. - Priority: `@media` scored 200 while `:hover` to `:active` was only 130 to 170, so at-rules outranked pseudo-classes in the flat sum and hover+media (3330) also sorted after active (3170). An at-rule now refines a state instead of outranking it. The per-at-rule class repetition is gone, so every rule for a property carries the same specificity, and at-rule priorities are scaled below the gap between adjacent pseudo-class ranks so they only break ties between rules sharing a state. `defineConsts` at-rules arrive as `var(--hash)` placeholders and were falling through to the default property priority of 3000, spanning three pseudo-class ranks. They now rank as at-rules. Resulting order: default < default@media < :hover < :hover@media < :active < :active@media Fixes facebook#1788
|
@alexcarpenter is attempting to deploy a commit to the Meta Open Source Team on Vercel. A member of the Team first needs to authorize it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1788
Problem
Combining
"@media (hover: hover)"with:activeon the same property means:activenever applies:This is the pattern documented in Combining conditions, so the expected result is that pressing wins over hovering.
The root cause is that StyleX gives at-rules specificity. In CSS they contribute none. Two mechanisms flow from that, and both favored the hover rule:
Specificity — the class name was repeated once per at-rule, so the hover rule was
.x.x:hover(0,3,0) against.y:active(0,2,0). Specificity beats source order, so:activecould not win regardless of insertion order.Priority —
@mediascored 200 while:hover→:activewas only 130 → 170, so at-rules outranked pseudo-classes in the flat sum and hover+media (3330) also sorted after active (3170).Before:
Divergence from native CSS
The same divergence shows up in a much simpler case. This plain CSS:
gives red, blue in dark mode, and green on hover in both modes, because
button:hover(0,1,1) outranks the media query'sbutton(0,0,1). Verified in Chrome.The StyleX equivalent did not:
Hovering in dark mode stayed blue. The doubled class is StyleX manufacturing specificity that the cascade does not give at-rules.
Change
An at-rule now refines a state instead of outranking it.
generate-css-rule.js— dropped the per-at-rule class repetition, so every rule for a property carries the same specificity andpriorityalone decides the winner. At-rule priorities are summed and divided by 1000, keeping them below the gap between adjacent pseudo-class ranks, so an at-rule only breaks ties between rules sharing a state.property-priorities.js—defineConstsat-rules arrive asvar(--hash)placeholders and were falling through to the default property priority of 3000, which spans three pseudo-class ranks. They now rank as at-rules.Resulting order:
After:
Equal specificity throughout, order decided by
priority. Verified in both the@layerand:not(#\#)output paths.Priorities stay in their existing range, so the
Math.floor(priority / 1000)contract used for CSS layers (babel-plugin/src/index.js) and runtime specificity levels (stylex/src/inject.js) is unaffected.Compatibility
Any cascade fix changes which rule wins, so this is worth calling out explicitly. Two surfaces:
Within StyleX — a bare at-rule no longer beats a pseudo-class. That is the divergence above, so the new result is the native one, but existing code that leaned on the old order will render differently.
Against non-StyleX CSS — rules containing an at-rule drop from (0,2,0) to (0,1,0). Hand-written CSS that previously lost to them at (0,1,0) may now win. This only affects rules with at-rules; everything else already emitted a single class.
Happy to gate this behind a flag if you'd prefer the staged rollout
enableMediaQueryOrdergot.