Browser compatibility matrix

Left: axis unpinned — Right: 'slnt' 0 stated

These must look identical. If the left one leans back, this device has the bug. The fix is component-level, not a global reset: any rule that states 'wght' via font-variation-settings must also state 'slnt' (src/lib/fonts/axis-pinning.test.ts enforces this for this repo's own code). An earlier version of this fix instead pinned 'slnt' 0 on html in app.css — that broke font-style: italic everywhere, on every engine, because an ancestor's explicit slnt blocks the browser's automatic mapping from font-style onto the axis. The "Hazard demo" section further down re-checks that on this device.

font-style: oblique + font-variation-settings: 'slnt' -11 — RECOMMENDED

Leans correctly everywhere, by construction: font-style: oblique is the semantically correct, spec-preferred way to ask for this (CSS Fonts 4 font-style-matching) and is future-proof as engines converge — confirmed already fixed between Safari 18.7 and 27.0 (see the two rows below). The explicit slnt value is what makes it deterministic today, on every version, without waiting for old Safari to disappear from the field: an element's own explicit font-variation-settings always wins over any automatic mapping, so whichever half an engine honours, the other covers it.

font-variation-settings: 'slnt' -11 alone — the deterministic ingredient

Leans forward. This sets the axis directly — no automatic font-style mapping involved, so nothing to disagree about across engines or versions, and immune to the ancestor-pin hazard below (unlike the two rows underneath). It is one half of the recommended pattern above, not a replacement for font-style: pairing it with font-style: oblique keeps the semantic layer without giving up determinism.

font-style: oblique alone (bare, no italic) — version-dependent

Per the CSS Fonts 4 font-style-matching algorithm, this is an exact match against the face's own font-style: oblique descriptor — no italic-to-oblique fallback step, one less layer of indirection than the row below. Leans ~11deg in Chromium, current WebKit and Firefox. On real devices this is confirmed version-dependent, not a permanent Safari limitation: broken on Safari 18.7 (iPhone XR), fixed by Safari 27.0 (macOS desktop) — the exact version this changed in is unknown, only these two endpoints are confirmed. Pair with explicit slnt (the row above) for determinism on anything between those two.

font-style: italic against a bare `oblique` face — version-dependent

Leans ~11deg in Chromium, current WebKit and Firefox — but confirmed UPRIGHT on real Safari 18.7 (iPhone XR): it does not perform this automatic font-style -> slnt mapping at all, even with no ancestor pin in the way. Not separately re-tested on Safari 27.0 — probably fixed alongside the bare-oblique row above, since both reach the same underlying axis-mapping capability just via a different matching path, but that is a guess, not a measurement, so it is left unconfirmed here rather than assumed. Playwright’s WebKit is a different, newer build and reproduces neither gap — this is a real engine divergence you can only catch by hand. font-style: italic is fine as a semantic hint; pair it with explicit slnt (or prefer bare oblique, one layer less indirect) for determinism.

font-style: oblique (BARE) against the font's TRUE -11deg..11deg range — still the trap

-11deg..11deg is not an arbitrary or mismatched range — it's Cairo's actual fvar slnt bounds (min -11, default 0, max 11). The trap is specifically the BARE keyword: CSS Fonts 4 says lack of an angle implies 14deg, which is OUTSIDE this face's declared bounds, so Chromium and WebKit fall back to synthesis to reach 14deg on top of the (correctly matched) axis — Chromium leans roughly twice as far, WebKit prefers synthesis over the axis outright and lands near the same overshoot. Only Firefox is correct. Correction to an earlier version of this row: this is NOT "declaring ANY oblique range breaks it, correct bounds or not" — state the EXACT angle the range covers instead of the bare keyword, and it resolves correctly everywhere (the row below). fonts.css still ships the bare keyword against a range-FREE face regardless: that stays correct with no extra use-site discipline required, where a ranged face would require every consumer to know and state the exact angle. font-synthesis is forced back to weight+style here — this site's own font-synthesis: weight would otherwise neutralise the trap by accident. Not re-tested on a real device.

font-style: oblique 11deg against the font's TRUE range — the real end state, and it works

This is the combination the trap row above is actually missing, and the genuine spec-ideal end state: a face that declares its true slnt bounds, and a use site that asks for a specific point inside them. Unlike the bare keyword, 11deg IS within this face's declared range, so there is nothing for the engine to fall back to synthesis for — resolves via the axis alone, correctly, in Chromium, Firefox and Playwright WebKit, whether or not font-synthesis allows style synthesis. fonts.css does not ship this yet: it requires every consumer to discover and state the exact angle rather than just writing font-style: oblique, and it has not been checked on real Safari. Kept as a documented possibility for when Cairo (or a successor) is ready to declare its axis range properly, not a recommendation to adopt today.

font-style: oblique 11deg against the shipped family — do not use

CSS Fonts 4: OpenType's slnt axis is positive counter-clockwise, CSS's oblique angle is positive clockwise — so stating the angle here SHOULD target 'slnt' -11, the same destination as the recommended row, via font-style-matching alone, no font-variation-settings needed. It does, in Firefox. It does NOT in Chromium or WebKit: caught first as a false pass in an isolated test that only declared the oblique face with no normal sibling; re-measured against a family carrying both, the way fonts.css actually ships Cairo, and both engines pick the wrong face and render upright — not a partial lean, no lean at all. Confirmed live on this page: the matrix cell below reproduces it. Stick with the recommended row above.

font-variation-settings as an @font-face DESCRIPTOR

The old hand-written font.css relied on this. Measured DEAD in WebKit — upright, no lean at all — so Cairo italic was silently broken in Safari all along. Not separately device-confirmed in isolation from the original backslant bug report; not re-tested here.

Faux-oblique synthesis on top of a real axis

Should look the SAME as the recommended row above. If it leans noticeably further, the engine is synthesising a skew on top of the real axis — fix with font-synthesis: none.

Left: italic, no ancestor pin. Middle: same, under a pinned ancestor — stays upright. Right: explicit slnt, under the SAME pinned ancestor — leans correctly regardless