Is Your Responsive Web Design too Fragile?

Contributing Editor

Take a look at this media query demonstration page in Chrome. Now adjust the width of your browser and reduce the body below 800px. As soon as it reaches 799px the background color and media query detection text will change.

Now load the same page in Firefox, Opera or Internet Explorer 10 and resize the browser again. It will depend on your OS and configuration, but you’ll discover you must reduce the size around 20 pixels further to fire the same media query event. On my PC it reacts at 782px:

media query result

Why? Let’s look at the W3C media query specification for width:

The ‘width’ media feature describes the width of the targeted display area of the output device. For continuous media, this is the width of the viewport (as described by CSS2, section 9.1.1 [CSS21]) including the size of a rendered scroll bar (if any).

It couldn’t be any clearer: Chrome or, more specifically, the Webkit rendering engine (soon to be Blink) is incorrectly ignoring the scrollbar and reacting too early. That appears sensible since scrollbar widths vary between systems, but it’s going against the W3C standard (perhaps another reason to reject the WebKit monoculture?)

There are technical solutions to the problem. For example, mqGenie detects non-Webkit browsers and calculates the scrollbar width so you can subtract it from the browser’s reported viewport dimensions. But you shouldn’t use it…

If your responsive design is so fragile that 20 pixels either way causes layout problems, you aren’t doing it right!

Responsive Web Design permits fluid layouts to be interspersed by breakpoints. Those breakpoints may be simple (such as modifying a font size) or implement more complex changes which rearrange columns and grids.

Unfortunately, fluid layout design skills became a lost art during the past decade. As I commented in 2009, fixed width has become the norm. Fluid layout may be one of the medium’s biggest strengths but designers often struggle with the concept.

RWD addresses many of the criticisms of fluid design but adds further complications. It’s therefore tempting to use media queries to implement a series of fixed width layouts — and that’s when browser issues such as scrollbar assumptions bite.

Here are my three golden Responsive Web Design recommendations:

  1. Investigate and experiment with fluid design techniques before attempting RWD.
  2. When creating a responsive template, start with the simplest mobile-first layout and work toward more complex desktop designs (see also How to Use Responsive Web Design to Support Old Browsers).
  3. Forget pixels — use proportional units such as %, em and rem for font and element dimensions. Even if your final design must have fixed dimensions, create a fluid layout and set the outer element’s width accordingly.

It’s a different way of thinking but persevere. Inflicting paper-like restrictions on web design reduces the possibilities and makes Responsive Web Design more difficult than necessary.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.audero.it/ Aurelio De Rosa

    Very good and informative article Craig. I really appreciated it.

  • Damien Van Der Windt

    Still, when you need to trigger some script exactly when your layout change, you need to be able to rely on exact breakpoint.

    A 20px gap on some browsers is really annoying.

    • http://www.optimalworks.net/ Craig Buckler

      Do you need to rely on an exact breakpoint? While it’s normally specify it in pixels, you could also use em or other relative options. Even if you do use pixels, you should be fine if you use a series of fluid layouts.

      • http://www.brothercake.com/ James Edwards

        em-based breakpoints are totally the way to go. The browser calculates them using fixed base size (ie. they don’t change when the canvas font-size changes), but they DO change when the *browser* font-size changes.

        So consider — instead of breaking to the single-column layout at (say) 760px, you break at 47.5em (calculated with the 16px default most browsers use). When the screen gets smaller the layout breaks in the expected way, but it ALSO does that when the font-size gets larger!

        The effect is brilliant — you can even watch it happen in Opera and Firefox — stepping up the zoom or font-size and watch the layout break :-)

  • Roger

    Interesting that you post this. I’m having an issue with Twitter Bootstrap + Chrome, where if I re-size the browser it screws up the navigation. The last listed item doesn’t “pop” back up to the top when re-sizing from a small view port to a large view port. When I readjust the width of the browser to simulate an iPhone for example it works fine. Then I adjust it to its maximum width and the nav breaks, the last link in the navigation menu stays down. It only happens in Chrome. It even works fine in IE 8 !! Now.. how do I address this issue if Chrome is going forward with this?

    Is Chrome going to be the new IE when it comes to RWD? Too many variables.

  • http://www.cam.ac.uk Helen Sargan

    Bingo – we have just hit exactly this problem, and I was scratching my head over how to fix the too-fragile bit of our responsive design. This has saved me a lot of work – thanks!

    • http://www.optimalworks.net/ Craig Buckler

      Glad to be of service, Helen!

  • Harald Mahrer

    This is good to know, but…

    The behavior of Webkit is more intuitive for my opinion. Because the scrollbars make the “viewport”, that the user really sees “smaller”, so Webkit behaves like I would have expected.

    I would consider a “viewport” as something I really see, not something partially hidden.

    By the way, there are lot’s of reasons for responsive breakpoints, but there is definitely no reason, not make the design fluid “inbetween” (beside that it is not the easiest way).

  • http://www.barrettsdesign.com Rich Barrett

    I am trying to think of a situation where you would not want to take the scrollbar in to consideration as part of the viewport width!

    • http://www.optimalworks.net/ Craig Buckler

      I initially considered Chrome’s implementation to be more logical but there are a few edge cases which make it problematic — which may be the reason why the W3C decided on the scrollbar inclusive option. It’s a little convoluted to explain in a comment … I think I need a follow up post!

    • http://www.optimalworks.net/ Craig Buckler

      Here you go:
      http://www.sitepoint.com/rwd-scrollbars-is-chrome-better/

      It took me a while to appreciate why Chrome is wrong, but it is!

  • http://www.lockedowndesign.com/portfolio John J. Locke

    You would think that this point would be obvious to many people who build websites, but I still see it all the time. We’ve moving closer to the point where the finer points of RWD are integrated everywhere, but we’re still not 100% there yet.

  • Christian

    People, stop thinking Chrome is the end-all and be-all of browsers…

    • http://www.websitemba.com/ Kris K.

      Yeah, no browser is a perfect one and that includes Chrome. One thing I notice with this browser is that it eats-up lots of memory especially if you view flash content website especially videos and flash games on Facebook. But its one of the browsers that always trying to cope with the current web standards, so to say.

    • http://www.optimalworks.net/ Craig Buckler

      Agreed. There’s little to choose between Chrome, Safari, Firefox, Opera and IE10. Chrome is not always ahead.

  • http://jokeyrhy.me/ Ron

    OS X Mountain Lion hides inactive scroll bars. So unless you are scrolling, technically WebKit on OS X is complying with the W3C specification. As Apple is the primary source of all things WebKit, and OS X and iOS are Apple’s primary targets, it makes sense that this would bleed over into other WebKits on other platforms.

    I wonder if Google Chrome will be able to address this standards issue now that they are free of Apple…

  • http://www.zell-weekeat.com Zell Liew

    Whoa Craig. I totally didn’t know about this issue.

    I’m actually quite new to HTML and CSS and I just finished creating a responsive design blog template as my own side project. Luckily, the issue didn’t really cause any major problems in my simple design.

    Really helped a whole lot and I’ll take note of this problem with any future designs.

    Thanks for highlighting this.

  • http://brightbyte.co.uk/ Joe

    Thanks for the article Craig, quite insightful!

    We published a blog recently that will hopefully be of interest for people learning the basics of responsive development: http://brightbyte.co.uk/responsive-development-the-basics/. Please feel free to use it as a reference point.

    Thanks again, great content.

  • http://ensightful.com Dan Owen

    Breakpoints should be used for design changes based on width (and maybe height). Within a particular pair of breakpoints the design should be fluid. To me that is the best of both worlds -old-style fluidity wedded to new-style media queries.

  • http://x-tale.diandian.com/ s

    Well, in fact I HATE WebKit, and I think it soon for it (and Blink) to become the next IE 6.

  • http://madlemmings.com Ashley Faulkes

    As we all know 2013 is the year of Responsive Design – or so they say. Of course not everyone can spend money on apps for every mobile platform, so I think it is the basis for a great solution. In fact I just wrote a post on it focused more on non-tech people and users of frameworks such as WordPress.

    As a developer, I am however very interested in this discussion as deciding on exact media query boundaries is a tough decision and loads of trial and error

    appreciate your post Craig