chore!: raise the Firefox floor to 129, the version our CSS actually needs - #697
Merged
Conversation
…needs The floor said Firefox 121, set by :has(). Two features have arrived since that line was written and both sit above it: @starting-style with transition-behavior: allow-discrete, which the Menu's entry animation uses (Firefox 129), and @Property (128). @Property is the one that matters. Its nine registrations exist to declare inherits: false, which is what stops a colour or opacity utility on a container tinting everything nested inside it. Below 128 the registrations are ignored and that bug is live — so the old floor was not merely optimistic, it promised support for browsers where a documented behaviour does not hold. Safari, iOS and Chrome do not move: @starting-style landed in Safari 17.5, which is exactly where light-dark() already put that floor, and Chrome needed 117 against light-dark()'s 123. Coverage 87.06% -> 86.47%. Upstream Bootstrap v6 sits at Chrome 130 / Firefox 132 / Safari 18, so this stays more permissive than theirs. Versions are from MDN's browser-compat-data. caniuse does not track any of these three features, so `browserslist "supports …"` cannot answer for them — worth knowing before the next time someone checks.
Coverage Report for CI Build 30946267740Coverage increased (+0.007%) to 92.972%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
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
2 participants
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.
.browserslistrcsaid Firefox 121, set by:has(). Two features have arrived since that line was written and both sit above it.Measured, not remembered
MDN browser-compat-data for everything modern our compiled CSS emits:
@property@starting-styletransition-behavior: allow-discrete:has()light-dark()color-mix()oklch()Only Firefox moves: 121 → 129.
@starting-stylelanded in Safari 17.5, which is exactly wherelight-dark()already put that floor, and Chrome needed 117 againstlight-dark()'s 123. Safari, iOS and Chrome stay where they are.Why it is a correctness issue, not tidying
@starting-styledegrades gracefully — the Menu appears without its entry animation.@propertydoes not. Those nine registrations exist for one reason:inherits: false. Without them custom properties inherit again and.bg-opacity-25on a container tints every nested.text-bg-*,.link-opacity-50fades every nested link. That is the exact bug the comment inmixins/_utilities.scssdescribes.So Firefox 121–127 was not a slightly-degraded experience we were knowingly supporting. It was a documented behaviour that does not hold, in browsers we promised.
Coverage
87.06% → 86.47%, measured with
npx browserslist --coveragebefore and after. Upstream Bootstrap v6 sits at Chrome 130 / Firefox 132 / Safari 18, so this line stays more permissive than theirs.A trap worth recording
caniuse does not track
@property,@starting-styleortransition-behaviorat all —npx browserslist "supports css-at-property"returns nothing, and there is nomdn--prefixed entry either. Anyone checking these with browserslist gets silence, not an answer. The.browserslistrccomment now says to query MDN's browser-compat-data instead, and carries a feature-to-floor table in the shape upstream uses, so the next feature that raises a floor is noticed when it lands rather than months later.Docs: the browsers & devices page gains the two new rows and a note about what an ignored
@propertyactually does; migration guide updated.