I’ve found that a significant number of media queries can be replaced by fluid rules instead. E.g. instead of setting padding and full width on a container for mobile and a fixed width on desktop, do this for all breakpoints
width: min(calc(100wv - 2rem), 80rem)
Instead of resizing text for different breakpoints, use
font-size: clamp(2rem, 4vw + 1rem, 3rem);
etc. No media queries needed. I also find it easier to reason about since you don’t have different rules applying in different circumstances.
Note that the vw unit is broken by design because it includes the viewport scrollbar, so that 100vw may be more than 100% of the effective viewport width—100vw is always wrong. There are some situations where the imprecision is acceptable, but there are almost always better solutions these days.
Those new viewport units only fix the issues with retractable chrome as commonly employed on mobile platforms. They completely ignored the scrollbars issue which has been a design bug from the very start (though there used to be a workaround—`overflow: scroll` on the body—but it was removed from the spec after only Firefox ever implemented it), which I cynically say is because it’s not an issue on mobile platforms which uniformly use overlay scrollbars.
I wouldn't say it's wrong in the examples above - I want to have the same padding on both sides, and not the padding + scrollbar gutters on one side.
There's also `scrollbar-gutter: stable` to always reserve space for the scrollbar. It's not supported in Safari, but macOS uses overlay scrollbars by default anyway so it doesn't really matter.
It’s wrong, because 100vw is the document width plus any scrollbar width (including via scrollbar-gutter). If you have a body with zero padding and a vertical scrollbar, then 100vw > 100% except on platforms with overlay scrollbars. On Windows, this is likely to mean that or a 1000px-wide body, 100vw will be 1017px.
min and max can be difficult to figure out, especially if they have a bunch of calculations and stuff going on, but clamp is generally more explicit a description of what is wanted than media queries, for example the clamp above says:
never let the font size be smaller than 2rem
never let the font size be bigger than 3rem
the middle is then your fluid calculation of what the size should be between those two sizes.
since min, max, and clamp can be used in every property that can use calc it follows that lots of media query code can be replaced.
Finally when using media queries alone you will always run into some situation where something does not look that good if you are resizing your window and you are still in breakpoint 1 but you have not hit breakpoint 2 yet, you can of course fix that by adding a breakpoint in between these two, but the same problem presents itself multiple times.
Media queries alone will never give a 100% fluid experience.
I'd say you're on the right track. It's been years since I had to use media queries. Frankly, I associate them with bad job being done. Either due to inexperience or simply laziness
I can attest to not thinking about either mobile or desktop much in isolation since utility div classes in frameworks have become muscle memory. The other beneficial change has been to just look for visually weak browser width ranges, within content sections or components, and adjust them, regardless of whether “mobile” or “tablet” would be looking at them. It sounds like more work, but it’s better than trying to work to an arbitrary spec and usually results in more thoroughly refined work than conceived by designers.
Same! I can also attest to most people not thinking about the problem this way and it being a huge pain to get most engineers and designers to think in terms of “responsive first”, as opposed to “mobile first”.
Trying to impart this way of thinking was one of my biggest failures managing a product engineering team. I’m curious if others have successfully gotten teams of designers and engineers to stop worrying about mobile/tablet/desktop first and instead think in terms of an infinite number of viewport configurations?
To be more specific about my problems: in my experience with designers is that they want fixed viewport sizes so they can come up with “pixel perfect” designs. The tools they used tended to have fixed canvas sizes and dimensions. For “responsive first” designs, you need something that’s constantly changing the viewport size.
Engineers struggled because they wanted specs to implement against that were also pixel perfect. From a tooling perspective, I noticed most use Chrome and NOT the responsive view. I don’t know how anybody can build a responsive web application without being exclusively in responsive view and constantly resizing the viewport.
If I had to generalize the struggle between design & engineering, they felt they couldn’t meet the requirements given to them in a reasonable amount of time unless “mobile” and “desktop” were scoped separately.
> in my experience with designers is that they want fixed viewport sizes so they can come up with “pixel perfect” designs.
This is pretty much the "original sin" of the web. Every anti-accessible inflexible technology we've had to struggle with for 20+ years has been driven by this. Flash sites. Text "baked" into images. User-agent bans.
> If I had to generalize the struggle between design & engineering, they felt they couldn’t meet the requirements given to them in a reasonable amount of time unless “mobile” and “desktop” were scoped separately.
If I had to guess, they think the amount of people who would actually use something that falls outside of the standard desktop/mobile/tablet presets is very low and not worth the amount of extra effort it would take to implement.
In other words, this is one of those things the boss says they want but realistically it's way down the list of real world priorities and if nobody does it, nobody gets in trouble for not doing it, so it wasn't actually important in the first place. Whereas if something's wrong on the desktop or mobile designs, they'll hear about it and hear about it quickly, so they know that IS important.
There's a lot of truth behind this, but it's a bit of a chicken and egg problem.
The reason it was "way down the list of real world priorities" is because it was perceived as an impossible requirement to meet in terms of effort. My hopes is that it would be met as an innocuous side effect of making the thing work in a mobile and desktop viewport, but for the reasons I speculated above, it wasn't, and hence got dropped down on the list to the point where it wasn't worth the battle needed to ship a truly responsive design.
I can't just blame individuals though -- its easy to say, "oh, well they just weren't smart or motivated enough", but that's not the case. In the end I'm left thinking that the tooling, documentation, and ecosystem surrounding it simply didn't support making this "an easy requirement".
Good thoughts. It can be hard to “scale” this kind of conscientiousness. You might try to get them to use an app that shows multiple widths at once. A regression test suite to catch obvious problems in certain ranges can also help and some engineers would enjoy writing them.
> I’m curious if others have successfully gotten teams of designers and engineers to stop worrying about mobile/tablet/desktop first and instead think in terms of an infinite number of viewport configurations
Sadly, no, despite my best efforts across multiple teams I've led in the last few years.
If someone manages to crack this, I'll hail them as a hero.
Not to mention lower height when in landscape mode. Websites that don't disable sticky headers (or other elements) are useless because those fixed elements now take up most of the screen.
But that seems to be most sites these days. I have this bookmarklet invokable with a keyboard shortcut:
javascript:let i, elements = document.querySelectorAll('body *'); for (i = 0; i < elements.length; i++) { if(getComputedStyle(elements[i]).position === 'fixed' || getComputedStyle(elements[i]).position === 'sticky'){ elements[i].parentNode.removeChild(elements[i]); } }
That zaps fixed and sticky elements, so I can actually see the content. (I like the Vivaldi browser because I can assign keys to many things.)
It’s lower width (and height) because the screen is smaller. Remember that in CSS, px is not a physical screen pixel. It’s actually defined in the spec as an angular size[1]. In practice users might adjust their display preferences to suit their eyes. I would not recommend trying to compensate for physical display size, and instead let the user and the browser handle that.
Resolution can be targeted with other media queries, which should be useful for other high-resolution devices. And separate from this you should target touchscreens with a `pointer: coarse` query.
This is exactly why you should not think in terms of mobile, tablet, desktop, but instead in terms of features of the output media.
Just do your user research to see if it’s worth detecting non-touch input and resize elements. If you do this, you’ll be doing it for all larger widths, not just your guess at tablet. You don’t want to do it based on device detection because so many tablet users prefer keyboard and trackpad input (but again, try to find that out for your app/site’s user base.)
Lots of “gotcha” questions being asked that are symptoms of less-than-thorough responsive and multi-device development, I have to say…
True. We usually do raster content 2x at all widths, and size everything in pixel-independent units. But you are right that thinking in that abstraction doesn't cover all the work.
Bootstrap or tailwind, plus a handful copied from project to project. Just the usual fractions of width, width and aspect ratio constraints, padding, and so on.
Having done a lot of both ways, I am still a fan of mobile first. Otherwise inevitably the mobile site ends up being an afterthought, with retrofitted elements that almost but don’t quite work on mobile (often everything on the desktop page is just stacked, and it doesn’t quite work but it’s hard to put your finger on why). This rarely happens in reverse, because the default lazy desktop implementation is just that it’s “too simple” which is generally much less of a problem. It’s more obvious when something needs to be added than when it needs to be simplified or removed.
You can still write mobile-first; I think the idea here is mostly to no longer assume that all rules you write mobile-first will also apply to desktop. In other words, if you find yourself overwriting styles in a min-width media query for desktop, consider instead moving the rule you're overwriting into a max-width query, and then add a separate rule in the min-width query that just applies to desktop, if needed.
"Mobile first" was a term popular among those who don't write code, but loved saying it in meetings.
As a dev, I've never embraced the idea. It's over-compensating for the days when mobile was an afterthought. If all you've done is make desktop the afterthought, you haven't solved anything.
The sites I've worked on - big, small, popular, unpopular, all have significant numbers of important desktop and laptop visitors (important as in low bounce rate, high engagement). I spend time building interesting things for their screens because I want their return visits.
I prefer "accessible first" or "mobile-friendly". Not that I use catch phrases. Nothing needs to be "first". You don't need an ideology, you need results.
> "no one wants to spend their time retrofitting a desktop-centric site to work on mobile devices!"
That sounds like a problem from 15 years ago. Today it's reasonable to develop the desktop layout and mobile response at the same time. We have better tools such as flexbox to get mobile layouts working out of the gate.
When 75% plus of visitors to consumer facing sites – shopping, media etc – are on mobile devices then it's pretty clear to me that mobile first should be the focus.
All too often I come across sites that were designed on desktop and mobile was an afterthought, and it quite clearly shows
Before making big generalized claims, you need to define "mobile device". If you're including tablets and iPads, a lot of those devices have large screens which are closer to desktop or laptop anyway.
Your "mobile first" decision to banish the top navigation to a burger menu, for example, might actually leave enough empty space which would have fitted the navigation you just sent to burger land.
"[Device]-first" isn't a thing that comes to the rescue of anyone. If anything, starting with the big-screen design, allows all possible features to be clearly realized, sorted, and refined. After which, optimization and reduction can happen for whatever small-screen channels are needed. Chipping away at the block of marble is a reasonable and sensible approach.
Starting with a full set of features and presentation is more beneficial for understanding your product goals. Mobile-first inhibits the potential and limits exploration, by enforcing a restraint at the outset.
Imagine if the classic painters used the equivalent of "mobile first", let's call it "window first", in anticipation of satisfying the 50% of people who view the artwork from outside the gallery, peering through a window. Or take it further and try "postage stamp first" because more people will buy postage stamps than visit the gallery. Each to their own as always!
For most of the sites I work with (large retailers and publishers) tablets are a tiny percentage of traffic often 1-2% at most and I don’t consider them as being mobile
Starting with a big screen design might allow “all possible features to be clearly realized, sorted, and refined” but all too often it leads to unoptimized mobile experiences because compromises are made to make the desktop experience adapt to mobile
And when 75% of the audience aren’t going to get that full experience I argue that designing a great experience for the 25% to the compromise of the 75% is a flawed approach
The claim that only 25% of visitors are on a laptop or desktop, would not be accurate for many shopping sites. I'm not sure why you're generalizing about website traffic.
Laptops are not unpopular devices. People use them at work, at home, to shop, browse, everything. People love their laptops. At work, people love dual monitors etc. That won't change because humans need sufficient screen real estate to get stuff done and display documents etc.
As I said before, quality of users is also important. You should analyze your traffic to see bounce rate and spending for mobile phone vs everything else.
You seem to think that a mobile layout will be "compromised" if the design starts with the full website layout. This is old thinking. If the brief says "we want a strong website on all devices" then your designer and devs will make sure the site is great on all layouts. Otherwise they're not doing their job.
There's no universal law that says unless you design for mobile first, it will suffer. Your idea is left over from years ago when mobile phone usage was low, and mobile browsers were poor. Remember when there was a delay between pressing a button and the action, because iOS was "waiting" to see if was a double-tap or not. The compromise was built-in.
Add to that the crippled cache and memory abilities of phones, and the preference of mobile manufacturers to push people to native app stores, nobody should be surprised that mobile browsing was/is compromised by its very nature.
I work with large ecommerce sites (mainly US, UK & EU), for most of them around 75% of visitors are on phones and it’s pretty much the same picture for every consumer facing site I work with.
There’s some variation depending on the demographics e.g. sites with a large audience amongst the older population tend to have more tablet, and laptop visitors.
You can check the mobile vs desktop split for most sites using the Chrome UX Report
You say my logic is flawed but too many sites are designed with large screens in mind and then retrofitted to mobile with poor outcomes for the user experience
If you start with what we already know, natural responsiveness is fairly straight-forward. There are still phones out there running 320px. There are desktops running 6-8K. There are people using side-by-side windows at 4K, making each window slightly less than 1080p. And we know the same page needs to work on all of those and everything in between. With just those four pieces of information and a little logic, you can make confident decisions about your layout's behavior at different breakpoints.
With that in mind, the same is true now as it has been for almost 20 years. The layout should be made of 320px columns growable to 400px, while components occupy one or more columns. If everything else is based on that foundation, it will be rare to run into special cases. Whereas the current breakpoints based around 768 and 1024 are actively working against you by creating common dead zones that you need to adjust for.
You can see the 1025-1079 dead zone in action by visiting most websites in 4K side-by-side, causing a horizontal scroll as the content overflows. That includes major sites from Google, Meta and others who really ought to know better. Since almost all of my browsing is done side-by-side, I've resolved to reducing the default browser zoom to 90%, which eliminates the horizontal overflow on most of these sites.
I was a little surprised this treated dimensional media queries as an ~afterthought, but I guess my assumptions may be stale.
It's just as frustrating to use a site on a desktop that insists on a mobile layout until I make the window uncomfortably wide. (I assume this is tablet-focused design run amok.)
So, for a while now I've found it fruitful to regularly resize the browser between min and max width as I work (and sometimes vertically).
Rather than worrying about someone's device-size chart, I tend to build in more breakpoints focused on transitioning as the dimensions approach points where the content feels too crowded or too sparse, or where the UI/X affordances are creaking.
(Though this entails more of the regression testing that the source cites as a con.)
It’s kinda what happens when designers use 1024 or 1200 as desktop but don’t consider tablet at all. No one wants to spend the money on it so mobile ends up getting used up to wider desktop breakpoints. We’re guilting too if only showing desktop in tailwinds lg:*
yah, i’ve found that there are a couple “natural” breakpoints that depend on min- / max-content, where things are single column under about 400-500px (~40-50ch), 2 or 3 column above that, and either width constrained above ~1200px or more content columns collapse up. we’re needing fewer and fewer media queries to accomplish this however, which is nice.
I can't wait for container queries to finally get browser support. I just want to write self-contained css which is reusable and not dependent on a framework, a preprocessor, or a methodology like bem. One file for my components, one file for the responsive layout, and one for fonts and variables.
For what it's worth (and not related to CSS), I added functionality to my canvas library to make canvas elements aware of their container's shape and size, so the graphical elements can dynamically rearrange/resize as required[1]. This extends to DOM elements in the library's stack environment[2]. Of course the library is Javascript, so not useful for JS-disabled browsers.
i've played with container queries recently (via safari tech preview and ungoogled chromium), and they're not quite the panacea they could be. you still often need extraneous container divs to achieve some of the layouts/responsiveness you may want (this was true of grid and flexbox too, unfortunately). it's not the end of the world, but it doesn't lessen the mental burden as much as you might think.
Having worked on what I would classify as a very large and complicated mobile/desktop web app for a few years now, I would probably choose a different direction if I had access to enough developers.
I'm fairly convinced at this point that with enough developers, the best approach is adaptive if you plan on building a web app with considerable complexity. Completely isolated development, fully custom design and code for mobile.
With an adaptive site you have the choice to include or exclude elements which may have a major performance impact on the app, including for instance: entire view/component trees, media queries, heavy JS like graphs or ads. You also get to make web-unfriendly decisions like using a custom renderer if you think it will produce a higher quality experience, like Flipboard's React Canvas from several years ago: https://engineering.flipboard.com/2015/02/mobile-web
Overall it's still very context dependent, but I would recommend for larger teams to not completely discount adaptive mobile sites if they're looking to build the highest quality mobile experiences.
Component level layout should not be adaptive, but I've seen situations where a component migrates a long distance from the initial placement when switching to an alternate media-width.
>> I would recommend for larger teams to not completely discount adaptive mobile sites
Quality developers know when to use what. It's the legacy code that bites us.
mobile first css was really useful when stuff like grid wasn't well supported everywhere yet. you could stick stuff in a @supports block, and older browsers just get the mobile view instead, which usually doesn't need grid. But yeah, having done a good bit of both ways, I do think the desktop first way is just easier to write. You would think that "hey things are just stacked on top of one another by default anyway, so mobile default just makes sense", but mobile CSS tends to have a bunch of spacing rules you end up having to undo again, whereas most of the desktop stuff you overwrite is, in my experience, stuff you'd usually have two different rules for no matter what.
Plus, the desktop design tends to be the more complex one, so the HTML will be laid out to accomodate grids/flexbox elements, etc. where necessary. for the mobile view, you usually don't have to change the HTML as much.
In my experience, reactive media queries require less long-term maintenance. Anytime there's a strange re-sizing side-effect, it's someone using an isMobile flag.
I find the many angles and spins commenters here gave this thesis a remarkable consolidation of the reasons behind the idea of mobile first.
I might add, that there were tables and WAP before and finally the iPhone on the demand side gave rise to the mobile revolution. Or put another way: before iPhone there wasn't really a reason to design for mobile, only desktop.
Also in the beginning dev and designers focussed on landing pages and websites, not complex SaaS applications, to be mobile first.
I always rejected responsive web design, because it was in my point of view - lacking browser support of flex/grid! - an overly theoretical approach without any practical merits. Data on projects I worked showed, that a hybrid approach with some responsive sugar for edge cases did the deal way better (hybrid approach).
I remember, when Smashing Magazine went on the hype train and redesigned their website to be responsive, the goal was that it would react to every pixel change in the browser with a consistent layout - a task so tough and so irrelevant, even the designer afterwards conceded. (diminishing returns)
Even today, I prefer to think in views instead of "mobile first". It is not about adding or substracting features depending on the screen size, it is more about fulfilling tasks given a certain screen resolution. Some SaaS apps do not make sense on a phone. That's why I rejected the term "mobile first" in the first place.
Nevertheless, I recognize all the hard work by all devs and designers they pure in developing apps for different screen (re)solutions. No matter what you call the paradigm, it is tough and challenging. Keeping an eye on the user and the data, helped me stay sane.
Dumb Q: if you split them as in the example at the end of the article... then you have a lot of duplicated rules obviously as 90% of your CSS _should_ be the same?
Maybe the example at the end wasn't clear enough that you should still have a base CSS that encompasses the common parts?
It looks like Patrick is proposing the `default.css` holds most of the CSS (the 90% you're talking of), with mobile/tablet/desktop/print holding only variances over those base settings (so they'd only be the further 10% and only one downloaded matching the media definition.. maybe two if you print preview)
In reality, your css file size is most likely not going to be any type of bottle neck in website performance anyways.
In my experience, browser side javascript is always the biggest render blocking issue with all the on-the-fly dom manipulation it might entail. Viewport specific css usually adds some kilobytes, a few hundred at most but the browser tends to be relatively swift about those as long as you don't use a lot of stuff like transitions or wildcard selectors on a broad spectrum.
build webapps that you WANT to use from you phone. then actually use them from your phone. take notes on what is annoying, and fix it next time your at your desk.
webapps suck on mobile when the builders don’t use them on mobile.
It's really frustrating that media types are deprecated and I'd like to see it revived as a media feature. I understand the impossibility of picking the perfect layout for a website based on a broad category like "desktop|phone|TV". But in practice I think it works fine. Certainly better than assuming the device type/user preference based off some other feature. I'd love to hear that this is a solved problem and I'm just behind the curve.
One one hand, I think this makes total sense from a technical perspective. Don't load code you don't need, right? That's what we're doing with JS in SPA frameworks like Next.js, NuxtJS, SvelteKit, etc.
The problem with splitting code like this is it isn't aligned with the developer's thought process. It's a step back from where we've been headed over the past decade of web development. Current major JS frameworks like React and Vue are basically JS in HTML and newer CSS frameworks like Tailwind are basically CSS in HTML. The reason these frameworks have gained so much traction is because they don't break the developer's concentration.
The whole "separation of concerns" mantra from a decade ago was misguided. Web developers don't naturally think about code in terms of "let's do the HTML, then the CSS, then the JS". They think, "let's make a button that does something when I click it". And with the current frameworks, that button is often a single (albeit long) line of code. Semantics, layout, animation, interaction—everything. A decade ago, that button was spread across three files in three separate locations.
The problem with the approach outlined in the article is developers don't think, "let's do mobile, then tablet, then desktop". They think, "this box is always blue and it lives in a column that's a third the width of the container on larger screens".
The reason the code splitting works in the JS frameworks I mentioned earlier is because it's completely automatic. Unless this code splitting requires zero effort on behalf of the developer, it's never going to catch on. The DX just isn't there, even if it is certainly more performant.
All of this is built upon the misguided premise that the same markup could work both for mobile and for desktop. It can't unless it's text and images only. Different interaction paradigms call for different positioning of elements, different nesting, different density, etc. You do really have to have two sets of templates if you want to support mobile devices.
> Different interaction paradigms call for different positioning of elements, different nesting, different density, etc.
I’ve challenged this on HN before, but I’ll take a different approach. Can you describe a scenario where these fundamentally can’t be achieved with the same markup? I’ve never encountered one, in over a decade of developing responsive apps and sites.
They maybe can be done with the same markup, but it'd be much more work and some duplication, too. And of course it's absolutely unacceptable to redesign your UIs to make it easier to reuse markup — remember, developer experience doesn't matter if the end result is shit.
Interestingly, it's not a simple drop-in replacement when issuing Google fonts in a NEXT.js app's `_document.js` head. I have a CORS error, though Google fonts worked previously without any additional config. Does NEXT.js whitelist Google fonts in their routing? Or would there be a difference in how the "bunny" drop-in behaves with CORS headers?
