Fifteen Years Later: What Actually Changed in Web Layouts
It has been 15 years since Ethan Marcotte’s original article introduced responsive web design (RWD) to the world. In web years, that is practically ancient history. Yet we still describe what we build as “responsive websites,” as if the technique that solved 2010-era problems remains the final word on layout. Something newer emerged in that time — quietly enough that it hardly registered as a shift at all.
Back when Marcotte proposed RWD, the available tools were primitive. Layouts depended on floats, tables, or both. A responsive site had two fundamental building blocks: fluid grids built on percentages, and media queries, which were forward-looking at the time. What was missing was a genuine layout system — a way to arrange content that did not require constant improvisation.
The Unnamed Breakthrough
Flexbox arrived, followed by CSS Grid, and the change was substantial enough that Jen Simmons proposed a new name for the era in her 2019 talk “Everything You Know About Web Design Just Changed”: Intrinsic Web Design (IWD). The term comes from the idea that something intrinsic “belongs to the essential nature or constitution of a thing.” In practice, IWD is doing what CSS layout systems are meant for — using the native tools to arrange content rather than working around their limits.
The advantages over float-based systems were immediate. IWD gave us the best of both worlds that previously existed separately: two-dimensional layouts in the manner of tables, combined with wrapping behavior that adjusts when space runs short. It also solved long-standing frustrations, mixing fixed and fluid sizes in the same layout or allowing elements to intentionally overlap.
That last part mattered to the working relationship between designers and developers. As Simmons noted, the web could finally handle “fancy” designs in its own way, removing tension that previously ended conversations with the phrase “this print design can’t be translated for the web.” Not entirely — but the conflict narrowed.
Yet the nomenclature never stuck. RWD became a household term; IWD did not. Flexbox and Grid, plus their wrapping and sizing behaviors, slipped into everyday developer tooling without fanfare. Their use is so intuitive that the revolution passed without a ceremony. RWD evolved steadily rather than being replaced by something new.
How Layout Became The Browser’s Job
What IWD did accomplish was opening the door to a more radical line of thinking, one centered on the browser itself. The browser has always played the role of a go-between: the engine that sits between code and user. Developers have a mixed history with that relationship, optimistic about new capabilities like WebGPU and baffled by occasional rendering oddities. But the underlying assumption never changed — we tell the browser what to do, and it displays our layout to the user as designed.
IWD challenged that assumption at a fundamental level. CSS layout systems do not take direct orders. They respond to hints. The designer suggests how a flex container should behave; the browser decides what actually happens in a given context. Heydon Pickering called this algorithmic layouts, acknowledging that the web is inherently algorithmic at its core.
Even the simplest page fits this model. Text forms a flow layout, naturally wrapping when a line runs out of space. That behavior comes free — a single flex-wrap property allows a Flexbox container to behave the same way. The alternative is calculating every possible wrap point by hand, which remains onerous for good reason. Browsers have been refining layout engines for over 35 years; they develop better solutions when left to their own work.
The Mentor, Not The Manager
This is where the philosophy crosses from technique into posture. At the All Day Hey! conference in 2022, Andy Bell articulated the approach succinctly: “Be the browser’s mentor, not its micromanager.” The details of a user’s context are unknowable to a developer — the device, viewport, bandwidth, battery level, assistive technology setup, even whether cookies and JavaScript are enabled. Each of those context-dependent variables is exactly what a browser sees and accounts for.
To force every layout choice from the outset is to discard information the browser is already aware of. Acting as mentor instead means framing the design intent so the browser makes choices aligned with it — trusting the environment to handle the translation from the page’s message to the page’s presentation. The browser fills the divide between content and consumption better than any developer can predict, one encounter at a time.
The Declarative Shift
The common thread in the thinking of Jen Simmons, Heydon Pickering, and Andy Bell is a move away from the imperative and toward the declarative. Instead of giving the browser detailed instructions about how to render a page, you describe what you want, and let the rendering engine handle the rest.
As Jeremy Keith puts it, the job is to create the right inputs rather than trying to control every possible output. The analogy to prompting an AI system is tempting, but there is a crucial difference: the browser is not a black box. Its behavior is governed by open web standards, so we can reason about what it will do with our constraints, even as it adapts between edge cases we define.
Making that approach concrete means collecting the techniques that flow from this philosophy into a practical toolkit.
Compose Native Layout Systems
Flexbox, Grid, and normal flow are all widely supported and have been for years. They are not competitors. A wrapper for navigation links that should wrap on narrow screens is a flex job; a page shell with independent column behavior is a grid job; long-form text is naturally flow content. Start by picking the layout system that matches the component's behavior, and mix them freely.
Native layout systems are here to make the browser work for you — don't hesitate to use that to your advantage.
Build on Semantic HTML
The foundation of resilient pages is markup that conveys meaning on its own. A document should still be readable and navigable if a stylesheet or script fails to load. Semantic elements such as headings are also accessibility features in their own right; screen-reader users often rely on them to move through a page. Choosing the right element for the job is a first-class design decision, not a stylistic preference.
Make Type and Space Fluid
Text that adjusts to the viewport is a core piece of responsive design. One line of CSS using clamp() can now produce fluid type that scales between a minimum and maximum size.
font-size: clamp(1rem, calc(1rem + 2.5vw), 6rem);
The involved mathematics can get complicated, and it is wise to check guides on modern fluid typography and tools such as Utopia to generate the values. There are also known access concerns: a hard cap on maximum font size can interfere with zooming in some browsers, which is something to test against the WCAG text-resize requirement. Approaches to mitigate that issue have been published.
Spacing is simpler. Defining margins and gaps with font-relative units such as rem or em means the white space scales along with the text, and that is usually desirable. However, some argue for the predictability of pixels in certain spacing contexts, so be aware of the caveats on both sides.
Progressive Enhancement Is Still the Bet
The core idea of progressive enhancement is as relevant as ever. Modern features such as the View Transition API will not work everywhere, but enabling them can be a one-line addition. When a feature is unsupported, it simply is ignored; when support appears, the visitor gets the improvement automatically.
@view-transition { navigation: auto; }
The same principle applies to whole layout systems and features such as masonry. Unsupported Grid becomes flow layout; unsupported masonry can fall back to Grid or flow without breaking the content in any browser.
That's progressive enhancement at its best: allowing you to make your stairs into an escalator whenever it's possible.
Delegate the Math to the Browser
The browser knows what users need for security and performance and is excellent at performing calculations. A safe width range for a <main> element — say, between 20 and 60 characters — is all the browser needs to determine an acceptable line length on an unknown viewport. Provide those constraints and allow the layout algorithms to do what they are built for. This also means trusting the ecosystem of open standards that power those algorithms.
Adopt Logical CSS
Flexbox and Grid introduced a way to think about layout that is independent of physical directions; they operate on start and end. The CSS Logical Properties and Values module extends this to the rest of the language, which can make styling feel more natural once you are used to it.
See the Pen [Physical vs logical CSS [forked]](https://codepen.io/smashingmag/pen/mybNMzR) by Comandeer.
The benefit is not just convenience. Logical properties handle internationalized content more gracefully. The demo above, for instance, shows how text-align: start reacts to a right-to-left inline direction whereas a hardcoded text-align: left does not. Similarly, inline-size defines a length along the inline axis, so it automatically adapts to a vertical writing mode where its "width" becomes vertical height, while its physical counterpart does not change.
The Next-Order Responsive Shift
The changes above are largely technological. They are what today's browsers enable. But responsive design can go further with a change in the designer's mental model.
Using rem and em units becomes intuitive only when the effort to convert them to pixels is abandoned. Imagine working with chemical ratios rather than absolute quantities. A useful approach is to think in terms of relative amounts rather than a fixed table of equivalents.
60 — 100%
20 — x
x=100%*20/60=33.(3)%
The persistent myth that 1 rem means roughly 16 pixels is easily disproven. The user sets their browser's default font size to any value, making any fixed pixel equivalent meaningless. Thinking in concrete numbers conflicts with the nature of relative units.
This is a recognizable but strange idea. Without knowing the user's base font size, designing at a fixed pixel level loses meaning, which in turn forces a shift to ratio-based thinking. If the base font size is X, the heading could be 2X, the main column 60X, and an input field 10X. Any user-chosen base value becomes the only consistent variable, and the layout should scale with it.
This way of working is already present when using layout systems that compute sizes internally. It is also present when using rem and em to make components scale with font size. The remaining step is to disconnect these units entirely from the pixel world, giving up the impulse to estimate a pixel value for every measurement.
Shifting to user-provided defaults means ceding a measure of control to the user through the browser in a very real sense. Modern CSS makes it possible to ask what the user prefers — a dark theme, reduced motion, a layout suited to a touch screen, or against other choices users make. Each preference answered is a meaningful move toward a personalized experience where the design acts as an interface rather than an authority.
If a person sets their base font size to 64 pixels, they have a reason, even if you do not know what it is. The appropriate design choice is to accept and work with that setting.
The fundamental users rule should dominate the story of responsive design: the outcome belongs to them.
