[AksharP5]

What

Valid custom-font CSS no longer fails lint when an unquoted font-family is the final @font-face descriptor and omits its optional semicolon.

Why

The declaration matcher includes the closing brace in the family name. A declared ProjectFont becomes projectfont}, producing a blocking font_family_without_font_face error.

Same input through the real HTML linter:

CSS declaration	Before	After
@font-face{src:local('DejaVu Sans');font-family:ProjectFont}	1 error; strict-render gate blocks	0 errors; gate permits
Same declaration with a final semicolon	0 errors	0 errors
Quoted family, no final semicolon	0 errors	0 errors
No declaration	1 error	1 error

Chrome 152 CSSOM accepts the semicolon-free declaration as ProjectFont. The issue contains a complete, asset-free reproduction; this comparison exercises lint and the strict-render decision, not a full video render.

Related work

Fixes #6083.

#1538 strips braces from CSS comments; #2538 handles !important. Closed #2778 does not change this declaration extractor.

How

Stop the existing family-value matcher at }. Add regressions for single-word and multiword names and document the accepted syntax.

Test plan

• Two new regressions fail on the base implementation.
• Font rules and project-lint suites: 100 passed.
• Lint package build and TypeScript check passed.
• Real linter/strict-gate before/after and browser CSSOM inspected.
• Changed TypeScript passes oxlint and oxfmt; diff whitespace check passes.
• Documentation updated; comment checks run before push.

Validated on main 10c724bf5, Linux x86_64, Node 26.11.1 and preinstalled Bun 1.4.1 (repository pins 1.4.4). Full workspace checks are limited by missing installed inspector/AWS dependencies; Mintlify validation is unavailable because mint is absent. No new links or MDX components were added.

[mintlify]

Preview approval required

This pull request comes from a fork, so Mintlify won't build a preview until someone with write access approves commit 2cad3c9.

Approve preview

[miguel-heygen]

Nice first contribution. I ran both the old and the new pattern over the real block matcher and the defect reproduces exactly as described: font-family:ProjectFont} yielded projectfont} before and yields projectfont now, with quoted names, multiword names and the trailing semicolon case all unchanged. The three other font family extractors in the repo already exclude the closing brace, so this brings the one outlier in line, and the new tests fail on base.

One housekeeping item: the docs validation job is cancelled at this head while the PR edits the lint rules page, so please get that one green before merge.

[AksharP5]

@miguel-heygen Refreshed this branch onto current main at 2cad3c9 to trigger fresh docs validation after the old run was cancelled. git range-diff confirms the font fix, tests and docs patch are unchanged. Parsers/lint builds, all 100 font/project-lint tests, lint typecheck, formatting and comment checks pass. The new commit is signed and verified. Ready for another look once CI finishes.

[miguel-heygen]

Thanks for the fix, and welcome. This is a nicely contained one.

The housekeeping item from the earlier look is now closed: docs validation is green at this head along with the rest of the suite, so the approval stands here.

I re-ran the old and the new pattern side by side over the real block matcher to try to break it. The reported case goes from projectfont} to projectfont, the trailing semicolon case, the quoted case and the multiword case are all unchanged, and a declaration with trailing space before the brace actually comes out cleaner now. I could not build an input where the old pattern extracts a correct family and the new one does not. A quoted name containing a brace fails under both, but the outer @font-face block matcher already truncates there, so that is not something you introduced.

One thing I liked: the other family extractor in this file already excludes the closing brace, so this brings the one outlier in line rather than adding a new rule. The two new cases fail on base, which is what makes them worth keeping.

[jrusso1020]

Approving, agreeing with Miguel's approval at this head.

The bug is real on main. extractFontFaceFamilies in packages/lint/src/rules/fonts.ts matches [^;'"]+, and since the @font-face block match ends at }, a final unquoted descriptor with no semicolon captures ProjectFont }. After trim that is projectfont }, which never equals the used family, so font_family_without_font_face fires as a blocking error on valid CSS. Both new test cases hit exactly that path, so they fail on main and pass here.

The fix also brings this regex in line with its siblings. The used-font matcher a few lines down in the same file, htmlParityContract.ts in core, and the capture downloader in cli all already stop at }. This was the one extractor that didn't.

Need: yes, valid CSS hard-fails lint (#6083) · Size: ok · Reuse: matches the existing [^;}] pattern used by the other font-family extractors · Simpler: already minimal, one character class

— Rames