Open the stylesheet of any site delivered this year. You will almost always find the same thing: three or four breakpoint widths, and under each of them, the same values redeclared. That is the responsive of 2012, and it still holds the majority of the web.
The other school has existed ever since clamp() landed everywhere. It redeclares nothing, it interpolates. The difference is not a matter of taste, it is a difference of method, and it gets paid for in specific places.
The mockup stops arriving in slices
Responsive assumes you have drawn the screens it serves. In practice you draw two or three, and the whole rest of the range has never been seen by anyone. A visitor at 1100 pixels wide is looking at a composition the designer never approved: it is the 1440 mockup squeezed by force, or the 768 one stretched until the proportions give way.
Fluid reverses the burden of proof. You draw the two bounds, and what lives between them is derived from the same rule. The relationship between a title and its text, between a margin and a column, no longer depends on the width. What you approved is the proportion, not the value.
Development time, which is counted at the tenth change
Twenty sizes, four breakpoints: eighty declarations to write, to test, and to retouch every time the mockup shifts a notch. In fluid, twenty sizes make twenty declarations, and the number of breakpoints does not enter the equation.
The gain does not show on day one. It shows at the tenth change. A centralised scale is corrected at the source. A scale duplicated per breakpoint is corrected four times, or three and a half times, and it is the forgotten half that ships to production.
The foldable, the ultra-wide, and everything nobody planned for
A recent foldable phone shows around 450 pixels wide folded, and close to 880 unfolded. Neither of those widths falls in a box of the mobile, tablet, desktop triptych, and the switch from the first to the second happens while the page is on screen.
At the other end, Tailwind’s last breakpoint stops at 1536 pixels. Beyond that, nothing moves any more: a 3440 screen gets exactly the layout of a 1536 screen, with emptiness around it. Fluid does not have that problem because it knows no catalogue of devices. EVA CSS interpolates from 320 to 1920 pixels around a reference at 1440, and what goes beyond is bounded by decision, not by oversight.
Zoom, which breakpoints in pixels ignore
A breakpoint declared in pixels knows nothing of the browser’s font size. A visitor who raises their default font has not changed screen width: the site serves them the same layout with larger text inside, and it overflows. That is the known flaw of Webflow, whose breakpoints are in pixels, and it is the technical argument Lumos puts forward for moving all its sizing to clamp(). Tailwind corrected course by declaring its breakpoints in rem, but a breakpoint in rem is still a breakpoint.
A fluid size behaves differently, and the mechanism is worth a close look:
font-size: clamp(2rem, 1.694rem + 1.306vw, 3rem);
The floor, the ceiling and the intercept are in rem, so they follow the browser’s font. Only the slope is in vw. The text grows when the screen grows, and it also grows when the user needs it to. No breakpoint knows how to do both.
What the sites we look at already do
This is not an avant-garde. I opened the CSS of anthropic.com: it is a Webflow site, and its size scale is entirely fluid. Thirty-four variables in clamp(), twenty-two spacing steps, eleven text sizes, plus the site margin, all interpolated between 375 and 1600 pixels.
You find there, named identically, the variables of Lumos, Timothy Ricks’ fluid framework for Webflow: --site--margin, --site--column-count, --grid-breakout. And the main stylesheet, 280 kilobytes, now contains only thirteen media query blocks, 8% of its weight, twelve of which are the three breakpoints inherited from Webflow.
That is the balance of power I look for on a project: sizing continuous, media queries reserved for real structural changes. This site holds exactly one.
Why AI keeps coding in breakpoints
Ask a model for a responsive page. You will get md:text-2xl lg:text-4xl. That is not a technical opinion, it is a corpus effect: fifteen years of tutorials, frameworks and accepted answers have installed the breakpoint as the normal way to write responsive, and Tailwind’s documented idiom is still the breakpoint prefix.
A model returns the average of what it has read. It will not propose fluid by itself. It executes it very well when asked, with the formula, the bounds and the curve you give it. That is still a decision, and I am the one taking it.
What I take from it
Responsive is not wrong. It is expensive. It costs duplicated declarations, widths nobody drew, devices outside the catalogue and an overflow at the first zoom. You pay for it in maintenance, long after delivery.
Fluid does not ask for more work, it asks for less, provided you set the scale once and for all. That is exactly what EVA CSS does: bounds, a curve, a source of truth, and nothing left to redeclare.
