fix(next/font/local): omit font-weight descriptor when no weight is specified - #2843
Open
vjymisal0 wants to merge 1 commit into
Open
fix(next/font/local): omit font-weight descriptor when no weight is specified#2843vjymisal0 wants to merge 1 commit into
vjymisal0 wants to merge 1 commit into
Conversation
…pecified The generated @font-face rule always defaulted to `font-weight: 400` when neither the source nor the top-level options specified a weight. For variable fonts with a `wght` axis this clamps the font face to the regular instance, so elements using e.g. font-weight: 600 no longer render with the correct variable-font instance even though the computed CSS font-weight value still matches. Next.js only emits the font-weight descriptor when weight/defaultWeight is provided (see packages/font/src/local/loader.ts and the Turbopack next_font/local/stylesheet.rs implementation), so vinext should match that and omit the descriptor entirely rather than inventing one. Fixes cloudflare#2793
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 #2793
Problem
The
next/font/localshim's generated@font-facerule always defaulted tofont-weight: 400whenever neither the source nor the top-level options specified a weight:For variable fonts with a
wghtaxis, this clamps the font face to the regular (400) instance. Elements styled with e.g.font-weight: 600still compute to 600 in the CSSOM, but the browser renders the 400 instance of the variable font instead of interpolating to 600, because the@font-facerule pins the descriptor.Fix
packages/vinext/src/shims/font-local.ts: only emit thefont-weightdescriptor when a weight was actually specified on the source or top-level options.font-stylekeeps its existing"normal"default, matching the expected output in the issue.This matches Next.js, which only emits
font-weightin the generated CSS whenweight/defaultWeightis provided (seepackages/font/src/local/loader.tsand the Turbopacknext_font/local/stylesheet.rsimplementation, both linked from the issue).Test plan
tests/font-local-transform.test.ts:omits the font-weight descriptor when no weight is specified (issue #2793)— asserts nofont-weightin the generated CSS and thatresult.style.fontWeightisundefinedwhen no weight is given.still emits font-weight when a weight is specified on a single non-object source options— regression guard for the existing explicit-weight path.font-weight: 400present.pnpm test tests/font-local-transform.test.ts— all 43 tests pass.pnpm test tests/shims.test.ts -t "font"— all font-related tests in the broader shims suite pass (19 passed, rest unrelated/skipped).vp check(format + lint + typecheck) passes on the changed files.Scope note: this only touches
font-local.ts— I checkedfont-google-base.tsfor the same pattern and it doesn't hardcode afont-weightdefault, so it isn't affected.