Skip to content

fix(css): restore sans-serif UI font - #88

Merged
rdmiller merged 1 commit into
varese-devfrom
fix/sans-serif-ui-font
Aug 10, 2026
Merged

fix(css): restore sans-serif UI font#88
rdmiller merged 1 commit into
varese-devfrom
fix/sans-serif-ui-font

Conversation

@rdmiller

Copy link
Copy Markdown

Several parts of the UI render in a serif face: flexlayout tab labels, "No Results Yet!" in the results panel, and the Heap/FPS readout over the canvas.

Cause

src/css/styles.css carried a universal rule with no fallback, depending on a webfont pulled from Google Fonts:

@import url(https://fonts.googleapis.com/css?family=Lato:...);
* { font-family: "Lato"; }

Host apps block that request under their CSP, so Lato never loaded — and with no fallback in the declaration, every element the rule matched dropped to the browser's default serif. MUI components were unaffected because their emotion classes outrank * and carry the theme's own sans stack, which is why the app looked half-right rather than obviously broken.

Evidence

Measured in the running app rather than inferred:

  • document.styleSheets contained zero Google Fonts entries — the @import never landed.
  • Text set in Lato measured 327.02px; the same text in a deliberately nonexistent family __NoSuchFont__ measured 327.02px. Identical, so Lato was resolving to nothing. Arial measured 366.38px for comparison.

Fix

Introduces --cram-font-family holding the same stack the MUI theme uses, applies it to * and .App, and drops the now-unused external font request.

Using the MUI stack rather than a bare Arial means unstyled elements resolve to the same font Typography already uses, instead of introducing a second sans face. Arial remains in the stack as the conventional fallback.

workbenchTheme.css feeds the same variable into flexlayout's --font-family, keeping a literal fallback in case those styles are ever consumed without styles.css.

Verification

Confirmed in the browser against project-varese — flexlayout root, tab buttons, "No Results Yet!" and the Heap/FPS label all now compute to the sans stack, and render accordingly.

Also swept for other fallback-less font-family declarations in CSS and inline fontFamily in components: there are none, so these were the only affected paths.

2226 tests / 104 files pass, lint and typecheck clean. CSS-only change; no behavioural surface.

Split out of #87, which is unrelated feature work. No file overlap between the two.

🤖 Generated with Claude Code

`* { font-family: "Lato" }` had no fallback, and the Lato it depended on
came from a Google Fonts @import that host apps block under their CSP. So
Lato never loaded and every element the rule matched fell back to the
browser default — a serif face — while MUI components kept their own sans
stack and looked correct.

Visible as serif flexlayout tab labels, "No Results Yet!" in the results
panel, and the Heap/FPS readout over the canvas. Confirmed in the browser:
no Google Fonts stylesheet was present, and text set in Lato measured
identically to text set in a deliberately nonexistent family.

Replaces it with a --cram-font-family variable holding the same stack the
MUI theme uses, so unstyled elements agree with Typography, and drops the
now-unused external font request. workbenchTheme.css feeds the same
variable into flexlayout's --font-family, keeping a literal fallback in
case those styles are ever consumed without styles.css.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@rdmiller
rdmiller merged commit c3425e9 into varese-dev Aug 10, 2026
@rdmiller
rdmiller deleted the fix/sans-serif-ui-font branch August 10, 2026 21:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant