By Craig Buckler

Responsive Web Design and Scrollbars: Is Chrome’s Implementation Better?

By Craig Buckler

In my recent post, Is Your Responsive Web Design too Fragile?, I described an inconsistency between browsers when firing media query events:

  • Chrome and Safari exclude the scrollbar dimensions.
  • Firefox, Opera and IE include the scrollbar dimensions.

Assume we have a media query which detects a minimum width of 800px, e.g.

@media (min-width: 800px) { ... }

Chrome and Safari will include those styles when the body width is 800px or greater. However, if your OS shows vertical scrollbars with a width of 20px, other browsers would include the styles at 780px.

Let’s read 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).

The Webkit engine is wrong. But is it better?

At first glance, Chrome’s implementation seems logical but it’s important to understand that ‘width’ refers to the viewport dimensions, i.e. the total area inside the browser window — not the page width. Using the assumptions above, Chrome’s viewport width is actually 820px (800px body + 20px scrollbar). In other browsers, the viewport width is 800px (780px body + 20px scrollbar).

Unfortunately, knowing the viewport width does not aid CSS development since you don’t know whether the scrollbar is visible or what its dimensions are. However, Chrome’s alternative is far worse since the introduction or removal of a scrollbar can trigger a media query. This is a little complex, so I’ll explain with an example:

  1. Assume you have a simple responsive site which shows a desktop layout at 800px or greater and a mobile site at 799px or less. Scrollbar widths are 20px.
  2. Currently, the user has their browser window sized to an 810px viewport width. The height is large enough to show the current page (in desktop layout) without scrollbars.
  3. You click through to another page. Here, the content is longer than the viewport height and a vertical scrollbar appears. This reduces the body width to 790px and Chrome instantly switches from the desktop to mobile layout. The user becomes confused and vows never to return to your site again.

The situation is exacerbated if you have dynamically generated content. If a page currently fits in the viewport and you display a status message which increases the height, the resulting vertical scrollbar will switch the user from desktop to mobile layout (which could show the message in a different location). Once the status message is removed, the page will return to the desktop layout.

Firefox, Opera and IE do not exhibit this behavior because the viewport dimensions never change unless the user resizes their browser window. However, Chrome and Safari users could experience different layouts just because your site has slightly more content on one page than another. Nasty.

Admittedly, this is an edge case:

  • Mobile browsers do not normally display permanent scrollbars so the problem is never apparent on those devices.
  • A desktop browser user would be unlucky to have window dimensions set at a point where layouts noticeably changed.
  • You could prevent Chrome switching layouts by ensuring the vertical scrollbar is always visible, i.e. body { overflow-y: scroll; }.

That said, I consider it a valid reason for the Webkit and Blink teams to address the issue. I suspect media queries were implemented in Webkit before the syntax became a standard. However, we now have a W3C Recommendation; it makes sense to follow the finalized rules and provide a consistent experience for users and developers.

  • In January I wrote a blog post titled “Your Media Queries Are Wrong” detailing this issue buy also wrote a JavaScript plugin called mqGenie which normalises and adjusts breakpoints cross-browser so that they always fire at their intended witdh.

    You should check it out:

    • Thanks Matt.

      I featured a link to mqGenie in my article ” Is Your Responsive Web Design too Fragile?”…

      mqGenie is useful when all else fails, but RWD is better when it’s a series of fluid designs interspersed by breakpoints than pixel-critical layouts.

      • Oh, I didn’t see that.

        I don’t agree that “you shouldn’t use it” and “you’re doing it wrong”. There are perfectly valid times where you can’t produce the desired result “natively” because of the scrollbar differences: matching heights of two completely separate elements is one example.

        Thanks for the mention though, and I’m glad others at raising awareness of this issue.

      • I agree there will be edge cases and mqGenie is an ideal quick solution. However, if you reach that point, there’s possibly a better way to define your RWD layout so it’s less fragile.

  • Mats

    For now It seems wIser to add an extra medIa query tHat Includes tHe 780px too.
    Sorry about How tHe text looks., My pHone Is fubar

  • Bryan Anderson

    Internet Explorer 10 does not include scrollbar widths either since the scrollbar is not always displayed. I discovered this yesterday. It would be great if all browsers would be more consistent in how the viewport width was calculated.

  • Yah! you are right Craig Buckler. I am also agree both of you

  • I am still learning Responsive Design (RD)- just like the old HTML4 / xHTML days it can take time to learn the nuances of different browsers and inevitable hacks. I have found Bootstrap useful but it is far from perfect. Which begs the question is there a perfect way to build a CC3/HTML 5 responsive site with at least some decent functionality – (and I don’t mean resorting to a linear up/down page). As it is a RD moving target, just when you think you got iy sussed – along comes a bug or two or a new screen/device.

    As a matter of interest one of my sites shows (via Google Analytics) that in the past year over 530 screen resolutions/devices were detected !!! – from 240×240 up to mega 2400 – THAT’s SCARY and impossible to test !!

    I had a comment from a client along the lines of “My website looked great on mobile X but it’s all out of line on mobile Y”.

  • Brendan Davis

    Isn’t RWD a bit crippled at present by the pixel race that the manufacturers of phones and tablets have got themselves into? Deciding on a layout based on the number of pixels alone is not enough now that phones with a 5″ display have more pixels than most of the world’s installed base of PC monitors. Already there are many phones with over 300 pixels per inch – i.e. above the normal printing resolution for high quality fine-art photo printing – and one of the presenters at the recent Samsung conference was talking about 450 per inch! There seems to be a need for a central database of viewing devices that a browser can get this physical size.information from. The alternative might be a way to ‘interrogate’ the display to obtain this information. Has anyone come up with a simple fix for this issue? Incidentally, your example of the 800px break point would mean that the majority of current top selling phones would get the desktop layout.

    • Hi Brendan. Remember that retina (and retina-like) displays increase the pixel density but not the resolution to ensure applications and web pages remain visible. Therefore, a screen may report itself as 1200×800 but actually has 4x as many pixels (2400×1600).

      This can result in bitmap images looking blocky but the problem largely disappears if you use SVGs or icon fonts.

      Anyway, I don’t think RWD is crippled, but you may encounter a few interesting challenges!

Get the latest in Front-end, once a week, for free.