There has been some talk recently about turning off responsive design: Bruce Lawson, Webmonkey, and I also I wrote about it a while back. To be clear, I’m a big fan of responsive design, but I hope we can all agree there is no sense being dogmatic about a tool.
As fate would have it, I got an email from a reader:
I work with a 13″ MacBook Air and I use zoom a lot while surfing around because I haven’t the best eyesight.
Your site is difficult to do this because, the global % width is squeezing the content in. I found this “bug” in a lot of RWD websites. It makes it hard for me to access to the content.
They are right. A few zooms isn’t a big deal, but when you get to four or five the content gets pretty garbled up.

Just out of curiosity, I asked: “Would it be better for you if the page expanded wider than the width of the browser window? So you’d have to horizontally scroll as well?”
Yes, I prefer scrolling horizontally. I think if I’m the cause of breaking the page by zooming in, It’s also my responsibility also to scroll horizontally.
That’s interesting to hear, since horizontal scrolling is one of those universally reviled things by web designers that we try and avoid at all costs. Even in the fixed width days. Should we bump up to *gasp* 1024px wide sites? No! It might cause horizontal scrolling!
To be clear, I still think it’s a bad thing, it’s just interesting that someone feels “responsibility” to do it if they “break” the page. It’s a bummer they need to feel like they need to “break” the site to be able to read it at all.
This is my fault. But EM-Based media queries can fix! Kinda!
My media queries were in pixels. If changed them into EMs, then as you zoom in, the EM size changes, and the media queries should take effect where the pixel ones would not. So that’s what I did and it works great! But please note: you have to refresh the screen to see the media query take effect, it doesn’t happen as you zoom. I wish it would, but I also suspect people who do this a lot know to refresh. Also in my experience, at least Chrome is particularly persistant with your preferred zoom level on a site-by-site basis.
My base font size is 16px, so I just did a “Find in Project” for every single one of them and converted them.
@media (max-width: 1200px) { }
became
@media (max-width: 75em) { }
Fortunately I use fancy Sass @content mixins, so the vast majority of them were changed by changing one mixin.
Note that I even notch down my font-size for smaller widths, but the browser zoom is more than enough to actually make the text larger.
Also credit where credit is due, Lyza Gardner showed us the advantages of em-based media queries nearly a year ago.
Too big of an assumption?
So now I’ve “fixed” this and the layout no longer “breaks” when zoomed in. But is this absolutely better for the reader who wrote to me? They specifically told me they preferred horizontal scrolling and that’s not the solution I delivered. I’m assuming that a non-broken layout without horizontal scrolling is even better. But who knows, maybe they don’t like the mobile layout, even thought I don’t limit what you can do. Always a dance.
The media queries do take effect without refresh, at least in firefox!
Oh that’s good know, awesome. Chrome still doesn’t. I hope they do someday.
Not for me in Firefox 18. Em based media queries seem to have no effect versus what I see in Chrome.
Well, now I just feel silly. Not one, but TWO people beat me to the punch!
Oops! Nevermind. Everything works as expected it’s just my monitor is too big. Firefox maximized at 2560 x 1440 and zoomed in all the way looks like this http://cl.ly/image/0o0s2t3v3M3v if you’re wondering.
They can take effect on Chrome too! You just have to resize the page so that a media query will fire.
I reckon some javascript trickery could get the browser to think the page has been resized every time someone zooms the browser.
Chris, Thanks for the post. Very interesting.
It’s worth noting that Firefox doesn’t require refresh to apply new em-based media query rules.
Oops, John beat me to it!
Well, now I just feel silly. Not one, but TWO people beat me to the punch!
“Duplicate” posts help us better understand what the audience is collectively thinking. I still found this helpful.
Firefox will trigger media queries as you zoom the page (without page reload), scaling content nicely and keeping things pretty. The webkit browsers, on the other hand, will not and need that page refresh. I’m curious as to if this will change in the future, if enough light is shed on it.
Thanks for the heads up, Chris! I’ll be sure to stick to EMs for my containers in the future.
The page refresh is only necessary in some browsers – Firefox does the “right” thing and the media query kicks in as you zoom.
I’d expected that you used em based media-queries as I first heard about them through you.
It is a good point that this reader came up with. We should all be more careful in the future.
This is all Chrome’s fault as it doesn’t happen in Firefox, in Firefox you can even fake Retina by zooming 6 times.
The pixel is dead! Anytime you’ve used pixels in a responsive design you’re doing it wrong.
We had great results with em based media queries on our new http://etchapps.com build although making the JS and CSS play nicely was interesting…
Many thanks to your reader for bringing this up. I’ve had the same problem and even blogged about it a long time ago. Apple.com isn’t responsive at all yet is easy to read on a phone because you can zoom in on the text easily. Many (though not all) responsive sites take that away, and I just have to give up reading anything on the site. The Web design community will get this all worked out eventually.
You can’t please everybody, but you can design around a preferable experience. I’d be curious if the original visitor would prefer a pre-cropped/zoomed viewport if they were on a mobile device as well.
I think there are edge cases where people do want a dense desktop view on a small device (if your site is too responsive), or actually want the font smaller, but that could be repaired in the design itself. It’s good to consider minority opinions. Part of the issue is also that media queries in the wrong hands can faux-zoom and change designs elements in a way that is undesired by users or completely jostles ones viewing context. So be mindful of zoomers and finger pinchers.
OFFTOPIC — But, I don’t know about you but that animated GIF is effin annoying >_< . If one could just stop it on the frame you want to see the site on the ‘breaking’ stage without having to see the frigging thing cycle over and over and over… and over, that would be awesome :p
ONTOPIC — It was nice that that user emailed you and let you know about the issue, but mostly that he/she is willing to take ‘responsibility’ for breaking the site hence willing to deal with horizontal scrolling.
However, that type of user may very well be only one in the entire planet (Ok, not one… two then). The ‘bulk’ of the users are no where near as understanding as the user that emailed you, so what they’ll keep on doing is leaving a site.
Nonetheless, that user’s input accounted for a solution that benefits the entirety of that ‘bulk’ I mentioned above.
Damn, were we lucky that user sent you that message.
Big Thank Yous to him/her and you.
I heard this some times before, mainly from elderly people.
Is it possible with a button (aka some little Javascript) to lock the browser-width that CSS will read?
So that the browser (or at least: it’s CSS parser) thinks the page is still (say: 1920px) wide.
On that way, zooming is easy as suddenly all responsive-code is ‘locked’.
Perhaps a lot easier and making more sense then using EM (with refresh needed).
Who will fill in?
Another Compass extension that can manage breakpoints for you is aptly named “Breakpoint” and it allows you to specify media query breakpoints in pixels, but the compiled CSS will contain ems.
Breakpoint is very convenient because we inspect, debug, and (for the most part) think about screens in px-based units, but as many have pointed out it is better to use em-based media queries. Breakpoint lets you have it both ways!
This extension looks very nice.
However, the documentation is not clear about when to use
$breakpoint-to-ems: true;
.When and where exactly do you set this command on?
Tnx.
I typically put the
$breakpoint-to-ems
flag into my configuration partial, which comes before any of the actual styles. Either way it needs to be set before you use any of the mixins that generate media queries.If Breakpoint isn’t DRY enough for you, there’s also a wrapper extension called Respond-to which outputs the same code as Breakpoint, but captures some of the repetitive config into a single variable. I actually prefer using Respond-to over plain Breakpoint.
Sorry to ask, but what do you mean by “configuration partial”? It still unclear to me where is it that one needs to put this directive, if it’s a flag when you have Sass start watching (sass –watch…) or if you place that flag somewhere in your .scss/_mixins.scss file.
Thanks in advance.
Wish one could edit their comments…
Chris, never mind, I think I found the answer after looking into the
_breakpoint.scss
file of the project. I see that$breakpoint-to-ems: false !default;
is just a variable.However, it says
!default
, what does that mean though?Thanks again.
Ricardo,
false
is the default value for$breakpoint-to-ems
but if you set that variable totrue
somewhere very early in your Sass files then that should be all you need to do.The configuration partial I’m referring to is a partial that I create for each project. It’s not defined by any of the tools we’re discussing. I @import it before any styles are declared, so it’s a handy way to set global variables that I’m going to use in my Sass projects.
Mild trivia. When using Safari, zoom-in squishes the content within the responsive container. However, when using gesture zoom (i.e. double tapping with the track pad on an element), it zooms in just fine. Similar to how it would zoom on a touch device.
I think this is great. Desktop browsers really should let you zoom-in both ways. One way takes advantage of a sites media queries and the other should be more mobile pinch-to-zoom style where you get the original layout, just bigger.
Great stuff. I had never ever thought about zooming but it did indeed make this site here http://i-cart.org look terrible. Switched up to em’s now its pretty good.
One thing that is neat as well with using em’s is if the user wants your site to take up half their screen which triggers one of your media queries likely, they can zoom out if they want to get the ‘full desktop’ version back or zoom in to view more mobile like version. It gives the user even more flexibility to make your site do as they wish
Delicious.
Im finding that creating a site that is accessible to everyone is a nightmare with the rate that device and multi browser usage is going at, whilst still trying to bear in mind users with poor hardware, old browsers and with supportive tech… on projects where the site usage data suggests that there is such a broad base of users. My most recent project had this issue, but with ‘progressive enhancement’ in mind for users with newer tech and focussing on some core accessibility bits (effective contrast ratios and role’s in the markup) using a mix of fluid and responsive media queries, it is possible to acchieve a 90%+ effective site.
It’s working.
Firefox 18.0
Ubuntu 12.10
I’m gonna try this one.
Thanks.
Well in 90’s we got one screen size – 15″, some HTML tags and there is not to much to mix. Today we got screens staring with 3″ till 30″ and lot of tags to combine, the challenge is bigger. I think the best for design is to have responsive designer, always ready to fulfill demands of his clients, using every approach he can. Chris show us on this article one way.
Who would have thought there was a downside to responsive web design?
It’s interesting though, because the trend now is for font sizes to get bigger, since screen resolutions are increasing. I’ve seen sites with 17/18 pixel font sizes.
I really hate that the fonts are getting bigger. I loved the crisp little 11px (9pt in Photoshop) pixel fonts. I am not sure why I like them so much, but they definitely added some charm to the page. (Look at facebook and decrease the smallest font by 1px). I am not saying that big and defined fonts look bad, but I miss pixel fonts.
Also so much more planning involved in making a design responsive, I still haven’t figured out the right workflow for making a responsive layout.
This is just bad behavior by Chrome. It evaluates its media queries against physical device pixels and not against virtual CSS pixels. I think that’s wrong. Firefox does it right.
Example: Browser window is 1000 device pixels wide, you zoom in 200%, the html-element is now 500 CSS pixels wide but any media queries for 500px doesn’t trigger because Chrome still thinks the viewport is 1000px wide.
Firefox even updates window.devicePixelRatio correctly to reflect the proportions between CSS pixels and device pixels when zooming.
Example: Zoom in to 200%, window.devicePixelRatio is now set to 2 since there are twice as many pixels on the screen as on the page. This is good news for responsive images that can take advantage of the full resolution even when zoomed in.
Chrome doesn’t do this and window.devicePixelRatio is still 1.
Thanks :-)
Hi,
I’m the user that asked Chris about the issue.
Going more deep, i think that the Macbook Air ( not retina but high pixel density ) users have this problem cause the same that happens to Ipad Mini and the “vexing viewport” problem.
Apple needs to think more about the viewport of his high density pixel devices.
Lyza Gardner from Cloud Four wrote a very detailed blow post about this very topic some months ago. She goes into detail about how and why it works. Might be a good companion read to this article.
What really hooked me is when she explained that by using em based media queries, your site responds to the content and not the viewport size. So if someone visits your site completely zoomed in, the media queries would kick in since the ems are in relation to your zoom factor. However using px they don’t take affect since px is related to the viewport.
Been using ems ever since.
Here’s the article:
http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/
I Like Big font wish it would sparkle or have special effects to it
This is the weirdest coincidence. Yesterday, I was meeting with the university’s Online Media Committee to discuss the progress on an upcoming redesign. There were several comments that how when they are guiding someone around the site by phone, it seems that everybody is freaking zoomed in – even staff and faculty. The comments were along the lines of, “Dang, this looks really squishy and weird.” I didn’t realize em based media queries “fixed” that, I’m going to give it a shot.
This is accessibility wisdom for anyone who works with users that have just an average web savvy.
Hi Chris,
It is worth noting that there is a webkit bug that means zooming does not trigger media queries: http://alastairc.ac/2012/01/zooming-bug-in-webkit/
FF, IE and Op get it right, but Safari and Chrome are still catching up.
I do usability testing with people who have accessibility issues (including using zoom), and in non-webkit browsers RWD generally works very well on laptops and desktops.
Of course, this is different to the issue of whether people prefer the desktop layout (as Bruce wrote about recently), and that there are very limited options on mobile devices.
Holy crap, is that an animated GIF? Awesome! Great article!
That’s a great idea mate, i’ve been using EMs a lot more lately, I create websites that allow people to create wysiwyg style previews of printed products and EMs allowed me to resize the preview via media queries without having to write heaps of css for each breakpoint. I hadn’t thought of EMs used in the actual media queries but it all makes sense now. I also use the trick of bumping up the input and textarea text to 16px to avoid the zoom affect on iOS when the user adds content.
It’s a shame when looking at this site that the user still feels the need to zoom. The text is already pretty big.
Thanks for sharing Chris.
I found if you use REM units for media queries, it updates as you zoom.
Check out the following demo:
http://fvsch.com/code/bugs/rem-mediaquery/
Cheers!
I tested pixel based @media queries in all desktop browsers and it seems only Chrome has this problem…
Of course if you are going to use ems, you should go all out and use them everywhere .
@Matthew – Good demo, so it seems “em” is the way.
Support for rem units in a media query doesn’t seem consistent. It works in Chrome and updates as you zoom. In Safari, the media query (and all styles within) are ignored. In Firefox, the media query is ignored but the styles inside the media query are applied. Personally, I like what Chrome does, but that’s just me. It’s what I expected ems to do.
@chris coyier: You divide the original media query’s dimensions with 16px since your “base font size is 16px”. But it appears it does not matter what your base font size is (I assume the font size set to the HTML or BODY element). I set up a jsFiddle with 50px base font size, see jsfiddle.net/lmeurs/jML58/.
Great post, but what about pinch zoom on mobile devices? I see that when using boot strap, The two paragraphs I have like to squish into each other on the homepage instead of stacking in a standard PC/Mac browser.
How do I solve this issue? I posted my website in my comment, and I used Android Google Chrome to view this, but I tested it in other mobile devices like iPad’s Safari and it does the same thing.
http://www.surakusa.com
Well, now even if you declare breakpoints in pixels, a website goes responsive when we zoom it (cmd+)