body font-size falls back to 16px outside VS Code (--mt-font-size declared only on :root)

[nedtwigg]

lib/src/index.css:9 sets body { font-size: var(--mt-font-size) }, but
--mt-font-size is declared only on :root:

/* lib/src/theme.css:20 */
:root {
  --mt-font-size: var(--vscode-font-size);
  --mt-font-family: var(--vscode-editor-font-family);
}

applyTheme() writes --vscode-font-size (default 13px) to
document.body.style (lib/src/lib/themes/apply.ts:79), not to :root.
CSS resolves var() inside a custom-property declaration at the element where
that property is declared, so the :root declaration cannot see a --vscode-*
value that only exists on body. --mt-font-size resolves to nothing,
font-size: var(--mt-font-size) is invalid-at-computed-value-time, and body
falls back to the UA default 16px instead of the intended 13px.

This is why theme.css has a second, body-scoped block — and its own comment
spells out the exact rule being violated:

/* lib/src/theme.css:95 */
 * These mirror the @theme block above but are declared on `body`. CSS resolves
 * var() inside a custom-property declaration at the element where the property
 * is declared, so body-level declarations can see --vscode-* variables that
 * applyTheme() writes to body.style. */
body {
  --mt-font-family: var(--vscode-editor-font-family);
  ...
}

That block re-declares --mt-font-family but not --mt-font-size, which
looks like an oversight rather than intent.

Affects every host where applyTheme() is the only writer of
--vscode-font-size — standalone, website, and Pocket. VS Code is unaffected;
the webview host supplies --vscode-font-size at the document level itself.

Fix is one line — add --mt-font-size: var(--vscode-font-size); to the
body block next to --mt-font-family.

Why this wasn't fixed in the audit: it changes the inherited font size for
every unsized text node in three hosts (13px vs the 16px they render at today),
so it wants a visual review and a Chromatic pass rather than a drive-by edit.
Worth confirming the 13px intent still holds before landing it.

Found during the spec audit in #; documented rather than changed.

[dormouse-bot]

Reproduced and fixed in #478 — your analysis held exactly.

I turned the mechanism into a test before touching the CSS: consumed-keys.test.ts now parses theme.css, collects every custom property declared in @theme or :root whose value reads a --vscode-* variable, and asserts each is re-declared on body. Across 34 document-level declarations, --mt-font-size was the only violation — so this was a one-off oversight, not a pattern, and the check now stops the next one.

On the visual review you flagged: Chromatic caught 1 story needing a new baseline (build 588). Every automated check on the PR is green; UI Tests is waiting on your accept/reject, which is where the 13px-intent call gets made.