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:
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:
- Investigate and experiment with fluid design techniques before attempting RWD.
- 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).
- 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.
Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.
Jump Start Git, 2nd Edition
Visual Studio Code: End-to-End Editing and Debugging Tools for Web Developers