Prompt and context
A design system uses a brand font, but network conditions, licensing, or script coverage can make the browser use a fallback. Explain how font-size-adjust can reduce perceived lowercase-size jumps and how it differs from mobile text autosizing.
What the interviewer is testing
- Understanding that x-height and font size are different metrics.
- Ability to define fallback calibration, loading, and progressive-enhancement boundaries.
- Ability to combine visual consistency, script coverage, and accessibility checks.
Questions to clarify first
- Which scripts do the primary and fallback fonts cover?
- Is the goal to reduce loading-time jumps, or to keep a permanent fallback readable?
- Is mobile text autosizing allowed, and which size and line-height tokens already exist?
A 30-second answer
font-size-adjust calibrates the relative lowercase height using a font metric. I would measure the primary and fallback fonts, then use an explicit ratio or from-font progressively. It cannot make glyph widths, line height, or CJK metrics identical, so I would test scripts, zoom, loading failure, and low-vision settings. text-size-adjust is a separate control for mobile text autosizing, not a fallback-font calibration tool.
Step-by-step deep dive
1. Separate size from x-height
font-size-adjust keeps lowercase letters at a comparable readable height to the primary font. Two fonts set to 16px can have different x-heights, making the fallback look smaller or larger. The property adjusts a relative metric; it does not reproduce the primary typeface.
2. Choose an explicit ratio or from-font
An explicit value works when the team has measured the primary metric. With from-font, a supporting browser can read the metric from the available font and reduce a hand-tuned constant. The browser matrix and font files still need verification.
3. Keep calibration near typography tokens
:root {
--body-size: 1rem;
}
body {
font-family: "Brand Sans", "Fallback Sans", sans-serif;
font-size: var(--body-size);
font-size-adjust: from-font;
line-height: 1.5;
}The property affects the element and its descendants. Keeping it near the body typography token avoids unrelated components inventing compensation values. A readable stack remains the fallback when the property is unsupported.
4. Handle loading order
Calibration does not remove every change caused by swapping fonts. Combine it with a deliberate font-display policy, preload decisions, and an acceptable fallback. Measure initial readability, text reflow, and the final-font state separately; do not hide content to chase zero movement.
5. Test scripts and locales
A Latin lowercase ratio is not a universal proxy for Chinese, Japanese, Arabic, or mixed text. Build localized samples and inspect punctuation, numerals, weight, wrapping, and line height. Use locale-specific tokens when needed instead of treating one ratio as a global truth.
6. Separate it from text-size-adjust
text-size-adjust controls browser text inflation in mobile viewports. It does not calibrate fallback x-height. Identify whether the defect is a font metric or a mobile layout behavior before choosing a property, and avoid disabling an accessibility behavior to fix the wrong problem.
7. Define observable acceptance criteria
Record font-load success, layout change, zoom truncation, and readability under user font settings on real target browsers and devices. Include visual regression, screen-reader, keyboard, and high-contrast checks in the release gate.
Model answer
I would treat this as typography-metric governance. I would sample the primary and fallback x-heights, apply an explicit ratio or from-font near the body token, and keep a reliable stack. This can improve relative lowercase readability but cannot guarantee equal widths, line heights, or mixed CJK layout, so I would test successful and failed font loads, scripts, browser zoom, and mobile devices. Mobile autosizing belongs to text-size-adjust. Acceptance would use layout, truncation, readability, and accessibility evidence rather than one screenshot.
Common mistakes
- Claiming that
font-size-adjustmakes every font the same size. - Treating
from-fontas guaranteed across every browser and font file. - Disabling mobile enlargement with
text-size-adjust: noneas a generic fix. - Testing only an English first screen and never testing local scripts or load failure.
- Looking only at a layout metric while ignoring zoom, user font settings, and screen readers.
Follow-up questions and responses
What if the design also requires equal widths?
State that the property handles a relative height metric only. Choose a closer fallback, tune spacing, or redesign wrapping; do not promise one ratio solves every metric.
How do you degrade when from-font is unavailable?
Keep the stack and default size readable, then use feature detection or progressive enhancement for an explicit value. Treat unsupported behavior as a normal browser condition, not a reason to block text.
How do you stop a font swap from moving a button?
Reserve enough space, calibrate the fallback, and measure width before and after the primary font arrives. Critical actions should not depend on hidden text or unpredictable autosizing.
Should a CJK page use the same value?
Do not reuse it blindly. CJK does not map to the same lowercase x-height concept, so validate the local font and line-height samples independently.
How do you show that accessibility was not harmed?
Test browser zoom, system font preferences, focus order after reflow, screen-reader output, and high contrast. A fixed-pixel screenshot is not sufficient evidence.
How do you discuss browser support in an interview?
Give the target browser matrix and a feature-detection plan, with a readable stack when unsupported. Avoid claiming universal support without a matrix or test evidence.