Conversation
`font` was not in the property dispatch at all, so `font: 10px/1 Ahem` — the idiom most of WPT uses to get predictable text metrics — left the element at the default 16px in a default family. Every geometry assertion built on it was therefore measured against the wrong font, which quietly distorts far more of the suite than a missing feature normally would: 13.4% of `css/` tests use it. Parses the full grammar, including the optional style/variant/weight/stretch prefixes, `/ <line-height>` in each of its four spacings, and the `<system-family-name>` keywords. Size and family are both required, so a value yielding neither is dropped whole rather than half-applied, and a successful parse resets the longhands it covers as a shorthand must. `<absolute-size>` keywords (`medium`, `x-large`, …) come along with it: the shorthand's `<font-size>` accepts them, and `parse_font_size` previously rejected them and left the inherited size in place. Co-authored-by: Cursor <cursoragent@cursor.com>
5 tasks
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.
What & why
fontwas missing from the property dispatch entirely — the only"font"arm indeclaration.rsis the one that maps the legacy HTML<font>element'sattributes. So
font: 10px/1 Ahemset nothing at all, and the element stayed atthe default 16px in the default family.
That matters more than a normal missing property, because
font: <size>/<lh> Ahemis the idiom WPT reaches for whenever a test needs predictable glyph metrics.
13.4% of files under
css/use the shorthand (6,574 of 49,014). Those testsweren't failing because the feature under test was broken — they were being
measured with the wrong ruler, and a test whose reference uses the shorthand fails
even when the test itself never mentions it. On a 5,295-test sample across
css-text,css-flexbox,css-grid,css-backgrounds,css-sizingandcss-overflow:font:1,406 of the 4,326 failures in that sample (32.5%) sat behind this.
What it does
Parses the full grammar:
font-variantandfont-stretcharen't modelled byComputedStyle, but they'restill recognised — an unrecognised token has to invalidate the whole declaration,
so silently not knowing them would reject valid values.
/ <line-height>in all four spellings the tokenizer can hand over:10px/1,10px/ 1,10px /1,10px / 1.<system-family-name>keywords (caption,menu, …). We can't ask theplatform what those are, so they land on the UA default — but they still reset the
longhands, which is the part that's observable.
inherit/unset(the font longhands all inherit, so those coincide) andinitial.Two behaviours worth calling out, both of which have tests:
leave the cascade alone, so nothing is written to the style until the whole value
has parsed —
font: 12pxcan't be allowed to land the size and drop the family.font-weight: bold; font: 20px serifendsup non-bold, and a
line-heightfrom an earlier declaration in the same ruledoesn't survive. The line-height is resolved against this declaration's size,
not the size the element had on the way in, so
font: 10px/1is 10px and not 16.<absolute-size>keywords come along for the ride: the shorthand's<font-size>accepts them and
parse_font_sizepreviously returnedNoneformedium/x-large/ …, leaving the inherited size in place. They're now on the usualmedium= 16px scale.Verified end-to-end as well as in unit tests — rendering
font: 10px/1 monospace,font: 10px monospaceandfont: italic bold 10px/2 monospacenow produces lineboxes of 10px, 13px and 20px respectively, matching the equivalent longhands, where
before all three produced 21px (16px at the default line-height).
🤖 How this was built
Checklist
cargo test --workspacepassescargo fmt --all+cargo clippycleanOne note on the WPT delta
Expect this to show up as a mixed delta rather than a clean win, and the
regressions are worth reading carefully — several of them are tests that were only
passing because both sides were wrong in the same way. The clearest example is
css/css-grid/grid-items/grid-item-block-axis-content-contribution-00{1,2,3}:test and reference both say
font: 10px/1 Ahem, so with the shorthand ignored bothrendered at 16px and matched. With it honoured, the reference (explicit
height: 10px) is right and the test's auto-sized grid row comes out 13px, becausegrid items ignore
line-height— a separate, pre-existing bug that this changemerely stops masking. I'll send that one separately.
Made with Cursor