☑ Responsive Design

This website is more or less wholly my own work. I use a content generator to create the HTML from Markdown source files, but the credit (or blame) for the layout and design lies with me alone¹.

Actually, I should hastily add that the one exception to this is that the current colour scheme comes straight from Ethan Schoover’s excellent Solarized palette. But that’s not really germane to the topic of this post, which I note with dismay I haven’t yet broached despite this already being the end of the second paragraph.

Now I’m not going to try and claim that this site is brilliantly designed — I’m a software engineer not a graphic designer. But I do strongly believe that developers should strive to be generalists where practical and this site is my opportunity to tinker. Most recently my tinkering has been to try to improve the experience on mobile devices, and I thought I’d share my meagre discoveries for anyone else who’s looking for a some basic discussion on the topic to get them started.

The first thing I’d like to make clear is that this stuff is surprisingly simple. I’ve known for awhile that the experience of reading this site on my iPhone was not a hugely pleasant one compared to the desktop, but I’d put off dealing with it on the assumption that fixing it would require all sorts of hacky Javascript or browser-specific hacks — it turns out that it doesn’t, really.

However, there are some gotchas and quirks due to the way that font rendering works and other odd issues. Without further ado let’s jump head-first into them.

Any viewport in a storm¶

No matter how simple your site layout or styling, you might find that it doesn’t render optimally on mobile devices. One reason for this is that mobile browsers render to a much larger resolution than the actual screen, and then they zoom font sizes up to remain legible on the screen.

The reason they do this is because they’ve grown up having to deal with all sorts of awful web designers to whom it never occurred that someone might want to view their page at anything less than a maximised web browser on a 1600x1200 display. As a result they use all sorts of absolute positioning and pixel widths, and these cope horribly when rendered on a low resolution screen. Thus the browsers pretend that their screen is high resolution and render accordingly — but to keep the text readable they have to boost the font sizes. The net result is typically something that’s not necessarily all that pretty, but is often surprisingly usable.

This is quite annoying if you’ve gone to the trouble of making sure your site renders correctly at lower resolutions, however, and that’s pretty much the topic of this post. So how do you go about disabling this behaviour?

The short answer is to include a tag like this:

<meta name="viewport" content="initial-scale=1.0" />

The slightly longer answer is that the viewport meta tag specifies the viewport area to which you expect the browser to render. If your layout assumes a certain minimal resolution for desirable results then you can specify that width in pixels like this:

<meta name="viewport" content="width=500" />

This instructs the browser to render to a viewport of width 500 pixels and then perform any scaling required to fill the screen with this. It’s also possible to specify a height attribute but most web layouts don’t make too many assumptions about viewport height.

The first line I showed above didn’t set width, however, but instead the initial-scale. As you might expect, this instructs the browser to render the the full width of the page on the pixel width of the window without applying any scaling. Note that this is probably the only value you’ll need if you’re confident you’ve designed your styles to adapt well to all device screens.

You can also use this tag to constrain user scaling to prevent the user zooming in or out, but personally I find this a rather gross affront to accessibility so I’m not going to discuss it further — you should never presume to know how your users want to access your site better than your users, in my opinion.

When is a pixel not a pixel?¶

This is all fine and dandy, but pixels aren’t everything. If I render to a viewport of 1000 pixels the resultant physical size is significantly different on a desktop monitor than on a retina display iPhone.

The correct solution to this would probably be some sort of way to query the physical size or dot pitch of the display, but that would require all web designers to do The Right Thing™ and that’s always been a bit too much to ask.

Instead, therefore, browser vendors have invented a layer of “virtual pixels” which is designed to be approximately the same physical size on all devices. When you specify a size in pixels anywhere within your CSS then these “virtual pixels” are used — the browser will have some mapping to real physical pixels according to the screen size and resolution, and also no doubt to some extent the whims of the browser writers and consistency with other browsers.

The CSS specifications even have a definition of a reference pixel which links pixel measurements to physical distances — broadly speaking it says that a pixel means a pixel on a 96 DPI standard monitor. I wouldn’t want to make any assumptions about this, however — I’m guessing these things still vary from browser to browser and it’ll be some time, if ever, before everyone converges on the same standard.

As a result of all this you might find your page being stretched around despite your best efforts — there doesn’t seem to be a good way around this except have a fluid layout and use high resolution images in case they’re ever stretched (few things look more shoddy than a pixelated image).

If you want more details, Mozilla have a great article about the whole thing. You can also read all about the reference-pixel and this slightly old article about CSS units is also very useful.

Responsive design¶

Now our site renders at the correct size and scale on the device. Great. If your layout is anything like mine, however, now you’re feeling the loss of all those grotty scaling hacks and things don’t look all that good at all. What you need to do is restyle your site so it degrades gracefully at smaller screen sizes.

As much as possible I really recommend doing this through fluid layouts — the browsers are very good at laying out text and inline elements in an appropriate manner for a given width so where possible just use that. However, there are things that aren’t possible with this approach — for example, if you’re using a mobile device to view this site, or you shrink your browser window enough, you’ll see that the side bar disappears and jumps to the top to free up some additional width to stop the text getting too squashed. There’s no way that a browser will be able to make this sort of decision automatically, it needs a little help from the designer.

This sort of thing can be achieved with media queries.

These offer a way to conditionally include bits of CSS based on your current media type² and resolution. They don’t make it any easier to design a good mobile layout — making pretty websites is left as an exercise for the reader — but they do at least give you a simple way to swap between the styles you’ve created for different viewports.

There are two ways to use them — you can put conditional blocks in your CSS:

@media screen and (max-width: 450px) {
    body {
        font-size:0.9em
    }
}

Or alternatively you can switch to an entirely different stylesheet in your HTML:

<link rel="stylesheet" media="screen and (max-width: 750px)"
      href="/styles/mobile.css" type="text/css" />

I use both of these approaches on my site — I find it easier to write a wholly different stylesheet for the mobile layout since it has so many small changes³, and then I make a few small tweaks within the CSS itself for more fine-grained viewport widths within that range.

For example, switching to the mobile stylesheet on my site converts the sidebar sections to inline-block and renders them above the content. Within that same stylesheet, however, there are some small tweaks to make these render centered and spaced out where there’s room to do so, but left-aligned for narrow displays where they’re likely to flow on to multiple lines.

However, it’s important to note that you could use either approach equally well on its own — I don’t believe there’s anything that can be achieved with one but not the other.

As an aside if you’re tempted to go for the <link> approach to save network traffic on the assumption that the browser will only fetch the sheets it needs, think again. The browser can’t really have any special foresight about how you’re going to resize the viewport so it fetches all CSS resources. The media queries then just control which rules get applied.

You can find a few more details in this Stack Overflow question. It does turn out that some browsers will avoid downloading image files they don’t need, but that would presumably apply regardless of whether the media query was located in a <link> tag or in a CSS file.

Font scaling¶

One additional issue to be aware of when designing mobile layouts is that if you render to the device width you can get odd results when you turn a mobile device into landscape orientation. Intuitively I’d expect a wider, shorter viewport with text rendered to the same font size, but in actual fact what you can end up with is a zoomed page instead. I think what’s going on here is that the scale factor is determined for portrait orientation and then applied in both cases, but I must admit I’m not confident I fully appreciate the details.

Whatever the cause, one fix appears to be to disable the mobile browser font size adjustments — this should no longer be required, after all, because the layout is now designed to work equally well in any viewport.

Because this is a somewhat new property and not necessarily supported in its standard form by all browsers it’s wise to specify all the browser-specific versions as well:

-webkit-text-size-adjust: 100%;
-moz-text-size-adjust: 100%;
-ms-text-size-adjust: 100%;
text-size-adjust: 100%;

You might have better luck playing around with different values of this setting than I did — I must confess I didn’t experiment much once I realised that disabling the adjustment seemed to fix my issues.

Hard copy¶

The discussion so far has been all about screens, primarily — the same media selectors can also be used to specify an alternative stylesheet for printing.

<link rel="stylesheet" media="print"
      href="/styles/print.css" type="text/css" />

This all works in exactly the same way except the sorts of things you do in these stylesheets is likely quite different. For example, I force all my colours to greyscale⁴ and remove the sidebar and other navigation elements entirely. I also remove decorations around links since these of course have no significance in a printed document.

If you want to remove something from the flow of the document you can do this in CSS by setting display to none:

@media print {
    div.sidebar {
        display: none;
    }
}

You might wonder how this differs from setting visibility: hidden — the difference is that display: none removes the element from the document completely, changing the layout; whereas visibility: hidden still reserves space for the element in the layout, it just doesn’t actually render it.

If you want to test out the print stylesheet of this or any site without wasting paper, you can do so with Google Chrome Developer Tools⁵. Open up the developer tools with the More Tools » Developer Tools menu option and then click the vertical ellipsis (⋮) and select More Tools » Rendering Settings to show a new window. Now you can tick the Emulate Media option and choose Print from the dropdown.

Layout in CSS¶

One important thing to note about all the techniques discussed on this page is that they only allow you to swap in or out CSS in response to viewport width — the HTML document structure itself is unchanged. This isn’t generally much of a limitation in today’s browsers since modern CSS offers a huge degree of flexibility, but it’s certainly something to bear in mind when you’re writing your HTML. In general the closer you are to a clean structural HTML document where CSS supplies all of the layout controls, the easier you’re likely to find adapting your site for multiple devices.

If you really need to redirect users to a different page based on width then of course it’s possible with Javascript, but this is a pretty ugly solution — it’s the sort of thing that leads to a world of pain where you have a version of your site for every device under the sun. If you’re the sort of masochist to whom that appeals, go right ahead.

Responsive vs. adaptive design¶

One final point that I should mention is that there are two schools of thought about laying things out for multiple devices — these are responsive and adaptive design, although it’s important to note that they’re not actually mutually exclusive.

Responsive design

This describes layouts that change continuously with the width of the viewport as it changes.

Adaptive design

This describes layouts that have several distinct options and “snap” between them as the viewport changes.

Responsive layouts are generally regarded as more graceful, I think, but adaptive layouts may be easier for more complex sites where it’s easier to implement a test a small number of distinct options. Personally I’ve used aspects of both, but I think I’d be comfortable describing my design as responsive overall since I try to use the full viewport width where I can, except in very wide cases where overlong text harms readability.

This is probably better illustrated than explained so I suggest checking out this set of GIFs that demonstrate the differences.

Conclusions¶

Overall I found the whole process of making my site more mobile-friendly very painless. I have quite a simple layout (quite intentionally) which made it a lot less hassle than I can imagine a lot of image-heavy sites might find. Frankly, though, that’s the modern web for you — bitmap images are so passé, and for good reason.