Implement fluid typography from 16px to 24px across 400px–1200px in one declaration?

This tests clamp() fluency for viewport-relative type scaling without media queries. A strong answer states clamp(16px, calc(16px + 8 * (100vw - 400px) / 800), 24px) and explains the slope math. A red flag is multiple media queries or calc() without clamp().
What's really being asked
This question probes your ability to build modern responsive design systems using intrinsic CSS rather than breakpoint-heavy media queries. The interviewer wants to see that you understand linear interpolation, viewport-relative units, and how clamp() can enforce bounds in a single declaration. It also reveals whether you know the math behind fluid grids and typographic scales or if you simply copy-paste snippets. Senior candidates are expected to connect this technique to design tokens and systematic spacing.
The full answer
First, the candidate should state the single declaration using clamp() with three arguments: a minimum of 16px, a preferred fluid value, and a maximum of 24px. Second, they should derive the preferred value using calc() with the formula 16px plus the product of the font range and the viewport progress, specifically calc(16px + (24 - 16) * ((100vw - 400px) / (1200 - 400))). Third, they should explain that the denominator 800 represents the viewport width range and that the numerator (100vw - 400px) normalizes the current viewport to a zero-to-one progress ratio. Fourth, they should mention accessibility considerations such as respecting user font preferences by using rem units for the bounds or ensuring the fluid value does not break zoom behavior. Finally, they should note that clamp() has been baseline available since July 2020, so browser support is no longer a practical concern.
The mistakes people make
A frequent mistake is writing multiple media queries with stepped font sizes, which violates the single-declaration constraint and creates jarring jumps rather than smooth scaling. Another error is providing calc() without clamp(), which produces unbounded growth that can shrink below 16px on narrow screens or explode above 24px on ultra-wide monitors. Some candidates also forget to subtract the minimum viewport width in the numerator, yielding an incorrect y-intercept that makes the font size 16px at 0px viewport rather than at 400px. Others suggest JavaScript resize listeners, which signals a lack of familiarity with modern CSS capabilities.
What usually comes next
The interviewer might ask how you would convert the pixel values to rem for accessibility, or how you would handle a non-linear typographic scale. They may also probe performance implications of viewport units in composite layers, or ask how to generate a full set of fluid type tokens for a design system using CSS custom properties. A sharp candidate might preemptively mention using a preprocessor mixin or a design-token generator to automate the slope calculation across many type scales.
A concrete example
The exact declaration is font-size: clamp(16px, calc(16px + 8 * (100vw - 400px) / 800), 24px). At a viewport of 400px, the calc() resolves to 16px because the viewport offset is zero. At 1200px, the offset is 800px, the fraction evaluates to 1, and 16px plus 8px yields 24px. Between those widths the value scales linearly, and clamp() ensures it never escapes the bounds even if the user snaps the window to 200px or 3000px.
Interview question
Which single declaration produces fluid typography that is exactly 16px at 400px viewport, exactly 24px at 1200px viewport, and never exceeds those bounds?
- a.font-size: calc(16px + 8 * (100vw - 400px) / 800)
- b.font-size: clamp(16px, calc(16px + 8 * 100vw / 800), 24px)
- c.font-size: clamp(16px, calc(16px + 8 * (100vw - 400px) / 800), 24px)Correct
- d.font-size: clamp(16px, calc(16px + 8 * (100vw - 400px) / 1200), 24px)
Why? this is the answer
Option C correctly normalizes the viewport by subtracting 400px, divides by the 800px range, and enforces bounds with clamp(). Option A lacks clamp() and allows unbounded growth, while B miscalculates the y-intercept by omitting the viewport offset and D uses the wrong denominator.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #css
- #clamp
- #fluid-typography
- #responsive-design
- #design-systems
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on css — each one lists the topics its interview covers.
See open roles