Taking RWD To The Extreme
Email Newsletter
Weekly tips on front-end & UX.
Trusted by 200,000+ folks.
Register for free today!
JavaScript Form Builder — Create JSON-driven forms without coding.
Try if for free!
Get a Free TrialWhen Ethan Marcotte conceived RWD, web technologies were far less mature than today. As web developers, we started to grasp how to do things with floats after years of stuffing everything inside table cells. There weren’t many possible ways to achieve a responsive site. There were two of them: fluid grids (based on percentages) and media queries, which were a hot new thing back then.
What was lacking was a real layout system that would allow us to lay things out on a page instead of improvising with floating content. We had to wait several years for Flexbox to appear. And CSS Grid followed that.
Undoubtedly, new layout systems native to the browser were groundbreaking 10 years ago. They were revolutionary enough to usher in a new era. In her talk “Everything You Know About Web Design Just Changed” at the An Event Apart conference in 2019, Jen Simmons proposed a name for it: Intrinsic Web Design (IWD). Let’s disarm that fancy word first. According to the Merriam-Webster dictionary, intrinsic means “belonging to the essential nature or constitution of a thing.” In other words, IWD is a natural way of doing design for the web. And that boils down to using CSS layout systems for… laying out things. That’s it.
It does not sound that groundbreaking on its own. But it opens a lot of possibilities that weren’t earlier available with float-based layouts or table ones. We got the best things from both worlds: two-dimensional layouts (like tables with their rows and columns) with wrapping abilities (like floating content when there is not enough space for it). And there are even more goodies, like mixing fixed-sized content with fluid-sized content or intentionally overlapping elements:
See the Pen [Overlapping elements [forked]](https://codepen.io/smashingmag/pen/zxOgdoM) by Comandeer.
As Jen points out in her presentation, this allows us to finally make even fancy designs in the “web” way, eliminating the tension between web designers and developers. No more “This print design can’t be translated for the web!” Well, at least far fewer arguments…
But here’s the strange part: that new era didn’t come. IWD never became a household term, the same way that RWD has. We’re still stuck to the good and old RWD era. Yet, Flexbox and Grid became indispensable tools in (nearly) every web developer’s tool belt. They are so natural and intrinsic that we intuitively started to use them, missing their whole revolutionary aspect. Instead of a groundbreaking revolution of IWD, we chose a longer but steadier evolution of RWD.
Enter The Browser
I believe that IWD paved the way for more radical ideas, even if it hasn’t developed into a bonafide era. And the central point of all of those radical ideas is a browser — that part of the web that sits between our code and the user. Web developers have always had a love-hate relationship with browsers. (Don’t get me started on Internet Explorer!) They often amuse us both with new features (WebGPU for the win!) and cryptic bugs (points suddenly take up more space, what the heck?). But at the end of the day, we tell the browser what to do to display our page the way we want it to be displayed to the user.
In some ways, IWD challenged that approach. CSS layout systems aren’t taking direct orders from a web developer. We can barely hint at what we want them to do. But the final decision lies with the browser. And what if we take it even further?
Heydon Pickering proposed the term algorithmic layouts to describe such an approach. The web is inherently algorithmic. Even the simplest page uses internal algorithms to lay things out: a block of text forms a flow layout that will wrap when there is not enough space in the line. And that’s so obvious that we don’t even think about it. That’s just how text works, and that’s how it has always worked. And yet, there is an algorithm behind that. That and all CSS layout systems. We can use Flexbox to make a simple layout that displays on a single line by default and falls back to wrapping up multiple lines if there is not enough space, just like text.
See the Pen [Resizable flexbox container [forked]](https://codepen.io/smashingmag/pen/wBwVqJJ) by Comandeer.
And we get all of these algorithms for free! The only thing we need to do is to allow Flexbox to wrap with the flex-wrap property. And it wraps by itself. Imagine that you need to calculate when and how the layout should wrap — that would be a nightmare. Fortunately, browsers are good at laying out things. After all, they have been doing it for over 35 years. They’re experienced in that, so just let them handle this stuff. That’s the power of algorithmic layouts: they work the best when left alone.
Andy Bell summed it pretty well during All Day Hey! in 2022 when he recommended that we “be the browser’s mentor, not its micromanager.” Don’t try to be smarter than a browser because it knows things you can’t possibly know. You don’t know what device the user uses — its processing power, current battery level, viewport, and connection stability. You don’t know what assistive technologies the user uses or how they configured their operating system. You don’t know if they disable cookies and JavaScript.
You know only one thing: there is that peculiar thing between your website and the user called browser — and it knows much more about the page and the user than you do. It’s like an excellent translator that you hire for those extremely important business negotiations with someone from a totally foreign culture that you don’t know anything about. But the translator knows it well and translates your words with ease, gently closing the cultural chasm between you and the potential customer. You don’t want to force them to translate your words literally — that could be catastrophic. What you want is to provide them with your message and allow them to do the magic of shaping it into a message understandable to the customer. And the same applies to browsers; they know better how to display your website.
Enter The Declarative Design
I think that Jen, Heydon, and Andy speak of the same thing — an approach that shifts much of the work from the web developer to the browser. Instead of telling it how to do things, we rather tell it what to do and leave it to figure out the “how” part by itself.
As Jeremy Keith notices, there has been a shift from an imperative design (telling the browser “how”) to a declarative one (telling the browser “what”). Specifically, Jeremy says that we ought to “focus on creating the right inputs rather than trying to control every possible output.”
That’s quite similar to what we do with AI today: we meticulously craft our prompts (inputs) and hope to get the right answer (output). However, there is a very important difference between AI and browsers: the latter is not a black box.
Everything (well, most of what) the browser does is described in detail in open web standards, so we’re able to make educated guesses about the output. Granted, we can’t be sure if the user sees the two-column layout on their 8K screen or a one-column layout on their microwave’s small screen (if it can run DOOM, it can run a web browser!). But we know for sure that we defined these two edge cases, and the browser works out everything in between.
In theory, it all sounds nice and easy. Let’s try to make the declarative design more actionable. If we gather the techniques mentioned by Jen, Heydon, Andy, and Jeremy, we will end up with roughly the following list:
Use Native Layout Systems
They’re available in basically every browser on the market and have been for years, and I believe that they are, indeed, widely used. But from time to time, a question pops up: Which layout system should I use? And the answer is: Yes. Mix and match! After all, different elements on the page would work better with different layout systems. Take, for example, this navigation on top with several links in one row that should wrap if there is not enough space. Sounds like Flexbox. Is the main part divided into three columns, with the third column positioned at the bottom of the content? Definitely CSS Grid. As for the text content? Well, that’s flow.
“
Start With Semantic HTML
HTML is the backbone of the web. It’s the language that structures and formats the content for the user. And it comes with a huge bonus: it loads and displays to the user, even if CSS and JavsScript fail to load for whatever reason. In other words, the website should still make sense to the user even if the CSS that provides the layout and the JavsScript that provides the interactivity are no-shows. A website is a text document, not so different from the one you can create in a text processor, like Word or LibreWriter.
Semantic HTML also provides important accessibility features, like headings that are often used by screen-reader users for navigating pages. This is why starting not just with any markup but semantic markup for meaningful structure is a crucial step to embracing native web features.
Use Fluid Type With Fluid Space
We often need to adjust the font size of our content when the screen size changes. Smaller screens mean being able to display less content, and larger screens provide more affordance for additional content. This is why we ought to make content as fluid as possible, by which I mean the content should automatically adjust based on the screen’s size. A fluid typographic system optimizes the content’s legibility when it’s being viewed in different contexts.
Nowadays, we can achieve truly fluid type with one line of CSS, thanks to the clamp() function:
font-size: clamp(1rem, calc(1rem + 2.5vw), 6rem);
The maths involved in it goes quite above my head. Thankfully, there is a detailed article on fluid type by Adrian Bece here on Smashing Magazine and Utopia, a handy tool for doing the maths for us. But beware — there be dragons! Or at least possible accessibility issues. By limiting the maximum font size, we could break the ability to zoom the text content, violating one of the WCAG’s requirements (though there are ways to address that).
Fortunately, fluid space is much easier to grasp: if gaps (margins) between elements are defined in font-dependent units (like rem or em), they will scale alongside the font size. Yet rest assured, there are also caveats.
Always Bet On Progressive Enhancement
Yes, that’s this over-20-year-old technique for creating web pages. And it’s still relevant today in 2025. Many interesting features have limited availability — like cross-page view transitions. They won’t work for every user, but enabling them is as simple as adding one line of CSS:
@view-transition { navigation: auto; }
It won’t work in some browsers, but it also won’t break anything. And if some browser catches up with the standard, the code is already there, and view transitions start to work in that browser on your website. It’s sort of like opting into the feature when it’s ready.
“
It applies to many more things in CSS (unsupported grid is just a flow layout, unsupported masonry layout is just a grid, and so on) and other web technologies.
Trust The Browser
Trust it because it knows much more about how safe it is for users to surf the web. Besides, it’s a computer program, and computer programs are pretty good at calculating things. So instead of calculating all these breakpoints ourselves, take their helping hand and allow them to do it for you. Just give them some constraints. Make that <main> element no wider than 60 characters and no narrower than 20 characters — and then relax, watching the browser make it 37 characters on some super rare viewport you’ve never encountered before. It Just Works™.
But trusting the browser also means trusting the open web. After all, these algorithms responsible for laying things out are all parts of the standards.
Ditch The “Physical” CSS
That’s a bonus point from me. Layout systems introduced the concept of logical CSS. Flexbox does not have a notion of a left or right side — it has a start and an end. And that way of thinking lurked into other areas of CSS, creating the whole CSS Logical Properties and Values module. After working more with layout systems, logical CSS seems much more intuitive than the old “physical” one. It also has at least one advantage over the old way of doing things: it works far better with internationalized content.
See the Pen [Physical vs logical CSS [forked]](https://codepen.io/smashingmag/pen/mybNMzR) by Comandeer.
The demo above shows the difference between physical and logical CSS. The physical tiles have the text-align: left property applied, while the logical ones have text-align: start. When the “left to right” inline text direction is set, both of them look the same. But when the “right to left” one is set, the logical tiles “move” their start to the right, moving the text alongside it.
Additionally, containers with tiles have their width set — the physical container with the width: 400px property and the logical one with the inline-size: 400px property. They both look the same as long as the block text direction is set to “horizontal.” But when it is set to “vertical,” the logical one switches its width with the height (as now the line of text is going from top to bottom, not from left to right), and the physical one keeps its initial width and height.
Taking It To The Extreme
“What do you mean by taking RWD to the extreme — it’s already pretty extreme!”
I hear you. But I believe that there’s still room for more. The changes described above are a big shift in the RWD world. But this shift is mainly technological. Fluid type without the clamp() method or algorithmic layouts without flexbox and grid couldn’t possibly exist — at least not without some horrible hacks (does anyone still remember CSS locks?). Our web development routine just caught up to what the modern browser can do. Yet, there is still another shift that could happen: a mental one.
I’ll be honest: I’m a die-hard fanatic of using rem and em length units. I’ve been using them for years, but they clicked for me only when I stopped trying to translate them into pixels. And what helped me in it was a… chemistry class I attended many years ago. When working with all these chemical concoctions, you often need to calculate their ratios. There’s that fancy method for doing that:
60 — 100%
20 — x
x=100%*20/60=33.(3)%
After I applied this way of thinking to rem and em units, I entered a new world of thinking about layouts: a ratio-based one. Because there is still a myth that 1 rem roughly equals 16 pixels — except it doesn’t. It could equal any number of pixels because it all depends on what value the user sets in their browser. So, thinking in concrete numbers is, in fact, incompatible with rem and em units. The only fully compatible way is to… keep it as-is.
And I know that sounds crazy, but it forces a change in thinking about websites. If you don’t know the most basic information about your content (the font size), you can’t really apply any concrete numbers to your layout. You can only think in ratios. If the font size equals ✕, your heading could equal 2✕, the main column 60✕, some text input — 10✕, and so on. This way, everything should work out with any font size and, by extension, scale up with any font size.
We’ve already been doing that with layout systems — we allow them to work on ratios and figure out how big each part of the layout should be. And we’ve also been doing that with rem and em units for scaling things up depending on font size. The only thing left is to completely forget the “1rem = 16px” equation and fully embrace the exciting shores of unknown dimensions.
But that sort of mental shift comes with one not-so-straightforward consequence. Not setting the font size and working with the user-provided one instead fully moves the power from the web developer to the browser and, effectively, the user. And the browser can provide us with far more information about user preferences.
Thanks to the modern CSS, we can respond to these things. For example, we can switch to dark mode if the user prefers one, we can limit motion if the user requests it, we can make clickable areas bigger if the device has a touch screen, and so on. By having this kind of dialogue with the browser, exchanging information (it gives us data on the user, and we give it hints on how to display our content), we empower the user in the result. The content would be displayed in the way they want. That makes our website far more inclusive and accessible.
After all, the users know what they need best. If they set the default font size to 64 pixels, they would be grateful if we respected that value. We don’t know why they did it (maybe they have some kind of vision impairment, or maybe they simply have a screen far away from them); we only know they did it — and we respect that.
And that’s responsive design for me.
(gg, yk)
