Journal tags: mediaqueries

It’s said that the best way to learn about something is to teach it. I certainly found that to be true when I was writing the web.dev course on responsive design.

I felt fairly confident about some of the topics, but I felt somewhat out of my depth when it came to some of the newer modern additions to browsers. The last few modules in particular were unexplored areas for me, with topics like screen configurations and media features. I learned a lot about those topics by writing about them.

Best of all, I got to put my new-found knowledge to use! Here’s how…

The Session is a progressive web app. If you add it to the home screen of your mobile device, then when you launch the site by tapping on its icon, it behaves just like a native app.

In the web app manifest file for The Session, the display-mode property is set to “standalone.” That means it will launch without any browser chrome: no address bar and no back button. It’s up to me to provide the functionality that the browser usually takes care of.

So I added a back button in the navigation interface. It only appears on small screens.

Do you see the assumption I made?

I figured that the back button was most necessary in the situation where the site had been added to the home screen. That only happens on mobile devices, right?

Nope. If you’re using Chrome or Edge on a desktop device, you will be actively encourged to “install” The Session. If you do that, then just as on mobile, the site will behave like a standalone native app and launch without any browser chrome.

So desktop users who install the progressive web app don’t get any back button (because in my CSS I declare that the back button in the interface should only appear on small screens).

I was alerted to this issue on The Session:

It downloaded for me but there’s a bug, Jeremy - there doesn’t seem to be a way to go back.

Luckily, this happened as I was writing the module on media features. I knew exactly how to solve this problem because now I knew about the existence of the display-mode media feature. It allows you to write media queries that match the possible values of display-mode in a web app manifest:

.goback {
  display: none;
}
@media (display-mode: standalone) {
  .goback {
    display: inline;
  }
}

Now the back button shows up if you “install” The Session, regardless of whether that’s on mobile or desktop.

Previously I made the mistake of inferring whether or not to show the back button based on screen size. But the display-mode media feature allowed me to test the actual condition I cared about: is this user navigating in standalone mode?

If I hadn’t been writing about media features, I don’t think I would’ve been able to solve the problem. It’s a really good feeling when you’ve just learned something new, and then you immediately find exactly the right use case for it!

The final five are here! The course on responsive design I wrote for web.dev is now complete, just in time for Christmas. The five new modules are:

1. Accessibility
2. Interaction
3. User interface patterns
4. Media features
5. Screen configurations

These five felt quite “big picture”, and often quite future-facing. I certainly learned a lot researching proposals for potential media features and foldable screens. That felt like a fitting way to close out the course, bookending it nicely with the history of responsive design in the introduction.

And with that, the full course is now online. Go forth and learn responsive design!

I made a little tweak to The Session today. The navigation bar across the top is “sticky” now—it doesn’t scroll with the rest of the content.

I made sure that the stickiness only kicks in if the screen is both wide and tall enough to warrant it. Vertical media queries are your friend!

But it’s not enough to just put some position: fixed CSS inside a media query. There are some knock-on effects that I needed to mitigate.

I use the space bar to paginate through long pages. It drives me nuts when sites with sticky headers don’t accommodate this. I made use of Tim Murtaugh’s sticky pagination fixer. It makes sure that page-jumping with the keyboard (using the space bar or page down) still works. I remember when I linked to this script two years ago, thinking “I bet this will come in handy one day.” Past me was right!

The other “gotcha!” with having a sticky header is making sure that in-page anchors still work. Nicolas Gallagher covers the options for this in a post called Jump links and viewport positioning. Here’s the CSS I ended up using:

:target:before {
    content: '';
    display: block;
    height: 3em;
    margin: -3em 0 0;
}

I also needed to check any of my existing JavaScript to see if I was using scrollTo anywhere, and adjust the calculations to account for the newly-sticky header.

Anyway, just a few things to consider if you’re going to make a navigational element “sticky”:

1. Use min-height in your media query,
2. Take care of keyboard-initiated page scrolling,
3. Adjust the positioning of in-page links.

Mark has written down some thoughts on breakpoints in responsive designs. I share his concern that by settling on just a few breakpoints, there’s a danger of returning to the process of simply designing for some set canvases: here’s my “mobile” layout, here’s my “tablet” layout, here’s my “desktop” layout.

In my experience, not all breakpoints are created equal. Sure, there are the points at which the layout needs to change drastically in order for the content not to look like crap—those media queries can legitimately be called breakpoints. But then there are the media queries that are used to finesse page elements without making any major changes to the layout.

When I was working on Matter, for example, there was really only one major breakpoint, where the layout shifts from one column to two. That’s the kind of breakpoint that you can figure out pretty easily from the flow of your content; just resizing your browser window is usually enough to settle on the point that feels right. But there are lots of other media queries in the Matter stylesheet. Those are there to make smaller adjustments to margins, font sizes …the kind of changes that came about from testing on phones and tablets in the device lab.

It feels a bit odd to call them breakpoints, as though the layout would “break” without them. Those media queries are there to tweak the layout. They’re not breakpoints; they’re tweakpoints.

Laura asked a question on Twitter the other day about dealing with older versions of Internet Explorer when you’ve got your layout styles nested within media queries (that older versions of IE don’t understand):

Sass, media queries and support for (older) Internet Explorers. How do you do it? This StackOverflow question asks: stackoverflow.com/questions/1062…

— Laura Kalbag (@laurakalbag) January 3, 2013

It’s a fair question. It also raises another question: how do you define “dealing with” Internet Explorer 8 or 7?

You could justifiably argue that IE7 users should upgrade their damn browser. But that same argument doesn’t really hold for IE8 if the user is on Windows XP: IE8 is as high as they can go. Asking users to upgrade their browser is one thing. Asking them to upgrade their operating system feels different.

But this is the web and websites do not need to look the same in every browser. Is it acceptable to simply give Internet Explorer 8 the same baseline experience that any other old out-of-date browser would get? In other words, is it even a problem that older versions of Internet Explorer won’t parse media queries? If you’re building in a mobile-first way, they’ll get linearised content with baseline styles applied.

That’s the approach that Alex advocates in the Q&A after his excellent closing keynote at Fronteers. That’s what I’m doing here on adactio.com. Users of IE8 get the linearised layout and that’s just fine. One of the advantages of this approach is that you are then freed up to use all sorts of fancy CSS within your media query blocks without having to worry about older versions of IE crapping themselves.

On other sites, like Huffduffer, I make an assumption (always a dangerous thing to do) that IE7 and IE8 users are using a desktop or laptop computer and so they could get some layout styles. I outlined that technique in a post about Windows mobile media queries. Using that technique, I end up splitting my CSS into two files:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!--[if (lt IE 9) & (!IEMobile)]>
<link rel="stylesheet" href="/css/layout.css" media="all">
<![endif]-->

The downside to this technique is that now there are two HTTP requests for the CSS …even for users of modern browsers. The alternative is to maintain one stylesheet for modern browsers and a separate stylesheet for older versions of Internet Explorer. That sounds like a maintenance nightmare.

Pre-processors to the rescue. Using Sass or LESS you can write your CSS in separate files (e.g. one file for basic styles and another for layout styles) and then use the preprocessor to combine those files in two different ways: one with media queries (for modern browsers) and another without media queries (for older versions of Internet Explorer). Or, if you don’t want to have your media query styles all grouped together, you can use Jake’s excellent method.

When I relaunched The Session last month, I initially just gave Internet Explorer 8 and lower the linearised content—the same layout that small-screen browsers would get. For example, the navigation is situated at the bottom of each page and you get to it by clicking an internal link at the top of each page. It all worked fine and nobody complained.

But I thought that it was a bit of a shame that users of IE8 and IE7 weren’t getting the same navigation that users of other desktop browsers were getting. So I decided to use a preprocesser (Sass in this case) to spit out an extra stylesheet for IE8 and IE7.

So let’s say I’ve got .scss files like this:

• base.scss
• medium.scss
• wide.scss

Then in my standard .scss file that’s going to generate the CSS for all browsers (called global.css), I can write:

@import "base.scss";
@media all and (min-width: 30em) {
 @import "medium";
}
@media all and (min-width: 50em) {
 @import "wide";
}

But I can also generate a stylesheet for IE8 and IE7 (called legacy.css) that calls in those layout styles without the media query blocks:

@import "medium";
@import "wide";

IE8 and IE7 will be downloading some styles twice (all the styles within media queries) but in this particular case, that doesn’t amount to too much. Oh, and you’ll notice that I’m not even going to try to let IE6 parse those styles: it would do more harm than good.

<link rel="stylesheet" href="/css/global.css">
<!--[if (lt IE 9) & (!IEMobile) & (gt IE 6)]>
<link rel="stylesheet" href="/css/legacy.css">
<![endif]-->

So I did that (although I don’t really have .scss files named “medium” or “wide”—they’re actually given names like “navigation” or “columns” that more accurately describe what they do). I thought I was doing a good deed for any users of The Session who were still using Internet Explorer 8.

But then I read this. It turned out that someone was not only using IE8 on Windows XP, but they had their desktop’s resolution set to 800x600. That’s an entirely reasonable thing to do if your eyesight isn’t great. And, like I said, I can’t really ask him to upgrade his browser because that would mean upgrading the whole operating system.

Now there’s a temptation here to dismiss this particular combination of old browser + old OS + narrow resolution as an edge case. It’s probably just one person. But that one person is a prolific contributor to the site. This situation nicely highlights the problem of playing the numbers game: as a percentage, this demographic is tiny. But this isn’t a number. It’s a person. That person matters.

The root of the problem lay in my assumption that IE8 or IE7 users would be using desktop or laptop computers with a screen size of at least 1024 pixels. Serves me right for making assumptions.

So what could I do? I could remove the conditional comments and the IE-specific stylesheet and go back to just serving the linearised content. Or I could serve up just the medium-width styles to IE8 and IE7.

That’s what I ended up doing but I also introduced a little bit of JavaScript in the conditional comments to serve up the widescreen styles if the browser width is above a certain size:

<link rel="stylesheet" href="/css/global.css">
<!--[if (lt IE 9) & (!IEMobile) & (gt IE 6)]>
<link rel="stylesheet" href="/css/medium.css">
<script>
if (document.documentElement.clientWidth > 800) {
 document.write('<link rel="stylesheet" href="/css/wide.css">');
}
</script>
<![endif]-->

It works …I guess. It’s not optimal but at least users of IE8 and IE7 are no longer just getting the small-screen styles. It’s a hack, and not a particularly clever one.

Was it worth it? Is it an improvement?

I think this is something to remember when we’re coming up solutions to “dealing with” older versions of Internet Explorer: whether it’s a dumb solution like mine or a clever solution like Jake’s, we shouldn’t have to do this. We shouldn’t have to worry about IE7 just like we don’t have to worry about Netscape 4 or Mosaic or Lynx; we should be free to build according to the principles of progressive enhancement safe in the knowledge that older, less capable browsers won’t get all the bells and whistles, but they will be able to access our content. Instead we’re spending time coming up with hacks and polyfills to deal with one particular family of older, less capable browsers simply because of their disproportionate market share.

When we come up with clever hacks and polyfills for dealing with older versions of Internet Explorer, we shouldn’t feel pleased about it. We should feel angry.

Update: I’ve written a follow-up post to clarify what I’m talking about here.

.net Magazine is running a series of articles on their site right now as part of their responsive week. There’s some great stuff in there: Paul is writing a series of articles—one a day—going step-by-step through the design and development of a responsive site, and Wilto has written a great summation of the state of responsive images.

There’s also an interview with Ethan in which he answers some reader-submitted questions. The final question is somewhat leading:

What devices (smartphones/tablets) and breakpoints do you typically develop and test with?

Ethan rightly responds:

Well, I’m a big, big believer of matching breakpoints to the design, not to individual devices. If we’re after more future-proof responsive designs, we should stop thinking in terms of ‘320px’, ‘480px’, ‘768px’, or whatever – the web’s so much more flexible than that, and those pixels are a snapshot of the web as we know it today. Instead, we should focus on breakpoints tailored to the design we’re working on.

He’s right. If we’re truly taking a Content First approach then we need to “Start designing from the content out, rather than the canvas in.”

If we begin with some specific canvases (devices), they’re always going to be arbitrary. There are so many different screen sizes and ratios out there that it doesn’t make sense to favour a handful of them out of tradition. 320, 480, 640 …those numbers aren’t any more special than any other screen widths.

But I now realise that I have been also been guilty of strengthening the hallowed status of those particular pixel widths. When I post screenshots to Flickr or include screenshots in presentations I automatically do what the Media Queries site does: I take snapshots at “traditional” widths like 320, 480, 640, 800, and 1024 pixels.

Physician, heal thyself.

So I’ve started taking screenshots at different widths. For the screenshots I posted of the new dConstruct site, I took a series of screenshots from 200 to 1200 pixels in increments of 100.

But really I should be illustrating the responsive nature of the design by taking screenshots at truly arbitrary widths: 173, 184, 398, 467, 543, 678, 832 …the sheer randomness of those kinds of numbers would better reflect the diversity of screen sizes out there.

Of course what I should really be doing is posting pictures of the website on actual devices.

I think our collective obsession with trying to nail down “common” breakpoints has led to a fundamental misunderstanding about the nature of responsive design: it’s not about what happens at the breakpoints—it’s about what happens between the breakpoints.

I think Jeffrey demonstrated this misunderstanding when he wrote about devices and breakpoints:

Of course, if breakpoints are dead, responsive design is dead, because responsive design relies on breakpoints both in creative workflow and as a key to establishing user-need-and-context-based master layouts, i.e. a minimal layout for the user with a tiny screen and not much bandwidth, a more fleshed-out one for the netbook user, and so on.

I was surprised that he suggested the long-term solution would be a shake-out of screen widths resulting in a de-facto standardisation:

But designers who persist in responsive or even adaptive design based on iPhone, iPad, and leading Android breakpoints will help accelerate the settling out of the market and its resolution toward a semi-standard set of viewports. This I believe.

I don’t think that will happen. If anything, I think we will see even more diversity in screen sizes and ratios.

But more importantly, I don’t think it’s desirable to have a “standard” handful of screen widths, any more than it’s desirable to have a single rendering engine in every browser (yes, I know some developers actually wish for that: they know not what they do).

I agree with Stephanie: diversity is not a bug …it’s an opportunity.

By far the most common use of media queries is to execute CSS based on viewport width (using min-width or max-width). Lately there’s been more talk about using media queries based on height as well.

Paul talked about using min-height media queries to adjust content appearing above the fold. Owen Gregory wrote his superb 24 Ways article on using viewport proportions and device-aspect-ratio for media queries. Trent has documented his use of horizontal and vertical media queries to bump up the font size for wide and tall viewports.

One of the areas where I’ve found height-based media queries to be quite handy is in combination with another CSS3 module: multiple columns.

Splitting text over multiple columns is not something to be done lightly on a screen-based display. If the columns drop below the viewport then the user has to scroll down, scroll back up, scroll down again …you get the picture. It works fine in print but it’s not something that should be attempted on the web unless the entire text is visible at one time.

Well, with media queries we can get a pretty good idea of whether the text will fit on the viewport …assuming we know the length of the text.

Here’s an example (thanks to Space Ipsum for supplying the text). It splits the text into two columns if the viewport has enough width and height:

@media all and (min-width: 40em) and (min-height: 36em) {
    [role="main"] {
        column-count: 2;
        column-gap: 2em;
    }
}

If the viewport is wider still, the text can be split over three columns. In this case, the test for height can actually smaller because the text is spreading over a wider area, meaning the overall height of the text is shorter:

@media all and (min-width: 65em) and (min-height: 25em) {
    [role="main"] {
        column-count: 3;
        column-gap: 2em;
    }
}

The actual CSS is more verbose than that: vendor prefixes are still required. You can grab the example from Github if you want to have a play around with it.

The next talk here at An Event Apart in Boston is one I’ve really, really, really been looking forward to: it’s a presentation by my hero Ethan Marcotte. I’ll try to liveblog it here…

The talk is called The Responsive Web Designer’s Workflow but Ethan begins by talking about his grandmother. She was born in 1910 and she’s still in great shape. This past Christmas she gave Ethan a gift of three battered and worn books that were her father’s diaries from the 1880s. They’re beautiful. The front is filled with almanac data but the most fascinating part is the short updates, mostly about the weather. They’re imperfect with crossing out and misspelling but they’re very visceral.

Stories are important. Passing on stories is an important part of what makes us human. Ethan illustrates this by showing some of my tweets about eating toast.

Newspapers are an odd paradox. For one day they are filled with the most important stories but just a day later they lose that immediate value. Take the Boston Globe, for example. It has a long history. Looking at old copies, the artefact itself is quite lovely.

But it’s a changing industry. This year nearly half of American adults will receive their news through mobile devices. The industry is trying to catch up with various strategies: separate mobile sites, iPad apps, and so on.

Ethan’s response last year was to talk about Responsive Web Design, which breaks down into three parts:

• flexible grids,
• flexible images and media and
• media queries.

The idea has taken hold and lots of very talented designers have adopted a responsive approach.

Well, today you can add one more site to the list: The Boston Globe, relaunching with a responsive design this Summer.

Up ‘till now, responsiveness has been about layout—that’s different to design. As Paul Rand wrote:

Design is the method of putting form and content together.

There were three firms involved in the Globe redesign: The Boston Globe itself, Upstatement, and Filament Group. Ethan was in that third group. Everyone’s got a wide range of skills. It’s tempting to divide skills into visual design and interaction design. But that distinction is often a reflection of the job roles at design agencies.

Is the traditional design agency process part of the problem? We have this linear approach: discover, design, develop, deliver—like a relay race. But for a responsive site, you can never really say what the final deliverable is. You could try to come up with Photoshop comps for all possible layouts but that just doesn’t scale.

Then there’s the tools. The first thing you do when you open up Photoshop is to create a fixed canvas size in pixels. This is what Jason was railing against in his quest for a real web design application.

For the responsive workflow, what’s needed is …design-o-velopment (no, not really).

The group convenes. The designers introduce the comp, explaining their decisions. The developers ask lots of questions. Where does content come from? How does the user interact with it? And the important one: how is going to look on a smaller screen? How should it adapt? They discuss the various input modes: mouse, touch, keyboard, voice. The questions are more important than any particular answers at this point.

“What value does this content have for our mobile users?” That question can be best answered by adopting Luke’s Mobile First approach. Narrow screens force us to focus.

Look at an article on AOL. The mobile version is great. The desktop version is cluttered. We drown the content. “Mobile” has become a synonym for “Less” and “Desktop” has become a synonym for “More.”

If you were asked to describe a mobie user, you might think of someone on the go, easily distracted. Whereas you may imagine a desktop user as sitting comfortably with plenty of screen size and attention. But it’s not that simple. People use their mobile devices in all sorts of environments at all sorts of times.

Making decisions about what people want based simply on the device they are using is a little bit like telepathy. Context doesn’t necessarily determine the user’s intent.

Even a good mobile experience, like Flickr’s, gets things wrong. Content is withheld from visitors with mobile devices. Lots of people click on that “desktop version” link because they feel they are missing out.

When you practice Mobile First, you’re making a commitment to the content. Everything that’s displayed on the page deserves to be there. Mobile First really means Content First.

Now you prototype like wild. A pixel-based tool like Photoshop is limited in what it can convey so you need to start making prototypes from the outset.

Figuring out the proportions for a flexible grid is fairly straightforward: target divided by context equals result. Slot in your pixel values to that equation and you get a percentage that you can declare in your stylesheet. Now you’ve got a liquid layout.

Resizing images is simple:

img { max-width: 100%; }

For important large images you can use Scott Jehl’s script to swap out the image src attribute based on the viewport size. It defaults to the smaller-sized image.

Finally, there’s the media queries. There’s a lot of devices to test on. Fortunately the Filament Group are involved with jQuery Mobile so they’ve already got a lot of devices. But rather than designing for specific devices, they searched instead for commonalities, like screen sizes. These are common breakpoints so they are what’s used in the media queries.

There’s very good browser support for media queries but there are still some laggards. Scott Jehl’s other script, Respond, bootstraps media query support using JavaScript.

It’s worth pointing out that they don’t have comps for all these breakpoints: they’re designing in the browser at this point. But they take these prototypes back to the designers so that they can vet them. They ask more questions. How well does the layout adapt? Do individual elements still feel usable? Most importantly, do any page elements need additional design work?

The masthead of the Boston Globe was a tricky problem. The result from prototyping wasn’t satisfactory so the designers came up with a different solution. As the layout shrinks, the masthead functionality changes. This solution wouldn’t have been possible without reconvening to review the prototype. So they’re designing in the browser but what they’re designing are design recommendations.

A responsive site isn’t flipping between a set of fixed layouts. It’s liquid. Breakpoints that you haven’t thought of will still work.

You have to figure out what is the most appropriate experience for what device. Stephen Hay wrote a great post called There Is No Mobile Web. His point is that the rise of mobile should encourage to revisit our principles of accessibility and progressive enhancement for everyone.

When responsive design meets Mobile First—starting with the narrowest width and building up from there—what you’re doing is progressive enhancement. You’ll even see this layering in the way that the stylesheets are structured.

The basic experience is still very attractive. The next step is enhancing for browsers that support media queries …and Internet Explorer. They get an enhanced stylesheet.

There are other things you can test for: are touch events supported, for example. So an iPad has the screen size of a laptop but it also supports touch events. They get some enhanced JavaScript functionality.

A really tricky question is “is this key content, or is it simply an enhancement for some users?” Web fonts are good example of this grey area. For the Boston Globe, they decided to make a hard cut-off point and only serve up web fonts to viewports above a certain size.

Conditional loading in JavaScript is very useful for serving up the right functionality to the right devices.

Let’s pull back a bit before we wrap up.

Just as there has been discussion “Mobile” and “Desktop”, there has also been discussion of “Mobile” and “Responsiveness.” A lot of the discussion is around butting heads between idealism and realism. Ultimately the decision about whether to make “Mobile” site or a “Responsive” site is more about the designer’s philosophy than about devices.

This has been quite a day for announcements. As well as the forthcoming Boston Globe redesign, Ethan also has a publishing date for his book: Responsive Web Design will be published by A Book Apart on June 7th.

Yesterday I documented the way I invoke media queries on Huffduffer while making sure that desktop versions of Internet Explorer get the layout styles. There’s an alternative way of serving up layout styles to IE that doesn’t involve splitting up your stylesheets.

Supersmart Scott Jehl has written a handy script called Respond that’s a textbook example of a browser polyfill:

A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will

In the case of Respond, you just need to make sure that you close every min/max-width media query declaration block with a comment:

/*/mediaquery*/

The script then executes those blocks if the specified conditions are met. You can see it action on the demo page.

The advantage of using this solution is that you don’t have to split up your styles into two documents (one for content styles, one for layout). The disadvantage is that it introduces a JavaScript dependency.

Use whichever solution works best for you, but note that two things remain constant:

You should still begin with linearised styles and only apply float and width declarations within media query blocks—think Mobile First (though I think of this as device-independence first).

You might still want to use a conditional comment to pull in Respond to avoid the extra HTTP hit for non-IE browsers. In that case, you may as well use the same clause to stop IE Mobile from parsing the script:

 <!--[if (lt IE 9) & (!IEMobile)]>
 <script src="/js/respond.min.js"></script>
 <![endif]-->

When I met up with Malarkey right before An Event Apart in Seattle he told me about a quick bit of guerrilla testing he had been doing. He popped into a store selling Windows Phone 7 devices and started surfing the web. Specifically, he started looking at sites using responsive design like Jon’s and Colly’s.

Most of the sites he looked at displayed the desktop layout instead of adapting to the smaller dimensions of the screen. That’s because the rendering engine for Windows Phone 7—some bastard hybrid of IE7 and IE6—doesn’t support media queries. So if you’re using media queries to undo width and float declarations, the media queries won’t be executed.

A better option is to begin with the layout-less version and use media queries to add in width and float declarations for the browsers that are wide enough to get that layout—this is kinda like Luke’s Mobile First approach. But if you do that, versions of Internet Explorer less than 9 won’t get those layout declarations even though the browser window is wide enough (IE9 is the first version to support media queries).

On Huffduffer I get around this problem by using conditional comments. First of all, I split off the layout styles into a separate stylesheet that is called with a media query in the link element:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">

(This isn’t ideal because now there is an extra HTTP request, but hear me out.)

Older browsers—including plenty of mobile browsers—won’t download the layout stylesheet so they’ll just get the linearised content. That’s all well and good but it leaves Internet Explorer out in the cold. Using a conditional comment, I can point older versions of IE to the same layout stylesheet:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!--[if lt IE 9]>
<link rel="stylesheet" href="/css/layout.css" media="all">
<![endif]-->

Now older versions of Internet Explorer also get the layout styles. This would all be fine and dandy except for the fact that Windows Phone 7 will also get the layout styles because it will understand the conditional comment. Curses!

But with one little tweak to the conditional comment, we can tell Windows Phone 7 not to follow the link:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!--[if (lt IE 9)&(!IEMobile)]>
<link rel="stylesheet" href="/css/layout.css" media="all">
<![endif]-->

That’s why Huffduffer serves up the layout styles to desktop versions of Internet Explorer but just gives the linearised layout to Windows Phone 7 …as observed by Andy in an AT&T shop on a rainy afternoon in Seattle.

All of this should become moot by September when word has it that Microsoft will upgrade the engine of Internet Explorer Mobile to be closer to IE9. Until then, this combination of stylesheet separation and conditional comments is the most robust way I’ve found to target as many layout-capable browsers as possible.

I swear there’s some kind of quantum entanglement going on between Ethan’s brain and mine. Demonstrating spooky action at a distance, just as I was jotting down my half-assed caveat related to responsive design, he publishes a sharp and erudite explanation of what responsive design is and isn’t attempting to do. He uses fancy learnin’ words and everything:

When I’m speaking or writing about responsive design, I try to underline something with great, big, Sharpie-esque strokes: responsive design is not about “designing for mobile.” But it’s not about “designing for the desktop,” either. Rather, it’s about adopting a more flexible, device-agnostic approach to designing for the web. Fluid grids, flexible images, and media queries are the tools we use to get a bit closer to that somewhat abstract-sounding philosophy. And honestly, a more unified, less fragmented approach resonates with my understanding of the web on a fairly profound level.

Meanwhile Mark has written a beautiful encapsulation of the sea change that responsive design is a part of:

Embrace the fluidity of the web. Design layouts and systems that can cope to whatever environment they may find themselves in. But the only way we can do any of this is to shed ways of thinking that have been shackles around our necks. They’re holding us back.

Start designing from the content out, rather than the canvas in.

Both Ethan and Mark are writing books. I can’t wait to get my hands on them.

In the meantime, I wanted to take an opportunity to clear up some misunderstandings I keep seeing coming up again and again in relation to responsive web design. So put the kettle on and make a nice cup of tea while I try to gather my thoughts into some kind of coherence.

Breaking it down

To paraphrase Donald Rumsfeld, web design is filled with quite a few known unknowns. Here are three of them:

1. Viewport: the dimensions of the browser that a person uses to access your content.
2. Bandwidth: the speed of the network connection that a person uses to access your content.
3. Context: the environment from which a person accesses your content.

Viewport

With the proliferation of mobile devices, tablets and every other kind of browsing device imaginable, there’s a high number of possible viewport sizes. But here’s the thing: that’s always been the case.

For over a decade, we have pretended that there’s a mythical perfect size that every person will be using. To start, that size was 640x480, then it was 800x600, then 1024x768 …but this magical ideal dimension was always a phantom. People have always been visiting our websites with browsers open to varying dimensions of width and height—the rise of “mobile” has simply thrown that fact into sharp relief.

The increasing proliferation of different-sized devices and browsers means that we can no longer cling to the consensual hallucination of the “ideal” viewport size.

Fortunately this is a solved problem. Liquid layouts were a good first step. Once you add media queries into the mix it’s possible to successfully deal with a wide range of viewport sizes.

Simply put, responsive web design solves the viewport question.

But that’s just one of three issues.

Bandwidth

Using either media queries or JavaScript, we can test for a person’s viewport size and adapt our layouts accordingly; there is no equivalent test for the speed of a person’s network connection.

This sucks.

The Filament Group are experimenting with responsive images and I hope to see a lot more experimentation in this area. But when it comes to serving up different-sized media to different people, we are forced to make an assumption. The assumption is that a small viewport equates to narrow bandwidth.

‘Tain’t necessarily so. If I’m using my iPod Touch I’m surfing with a fairly small screen but I’m not doing it over 3G or Edge—same goes for anyone idly browsing on the iPhone or iPad on their work or home connection.

Likewise, just because I’m using my laptop doesn’t mean I’m connected with a fat pipe. When I took the train from Seattle to Portland there was WiFi available …of a sort. And many’s the hotel connection that pushes the boundaries of advertising itself as “high speed.”

Once again, the “solution” to this problem for the past decade has been to ignore it. Just as with viewport size, we engage in a consensual hallucination of ideal bandwidth. Just as with viewport size, the proliferation of new devices is highlighting a problem that was always there. Unlike viewport size, the bandwidth issue is a much tougher nut to crack.

Responsive web design doesn’t directly solve the bandwidth question. I suspect that the solutions will involve a mixture of server-side and client-side trickery, most likely involving clever lazy loading for nice-to-have content. I’ll be keeping an eye on the work of Steve Souders.

In the meantime, the best we can do is stop assuming a best-case scenario for bandwidth.

Context

You don’t know what a person is doing when they visit your website. It’s possible to figure out what viewport size they are accessing your content with and it might even be possible to figure out how fast their network connection is but short of clairvoyance, there’s no way of knowing whether someone is in a hurry or looking to spend some time hanging out on your site.

Once again, this has always been the case. Once again, we have up ‘till now ignored the problem by pretending the person visiting our website—the same person with the perfect viewport size and the fast internet connection—doesn’t mind being served up dollops and dollops of so-called “content”, very little of which is directly relevant to them.

The rise of services like Readability and Safari’s Reader mode demonstrate that the overabundance of page cruft is being interpreted as damage and routed around.

The context problem—figuring out what a person is doing at the moment they visit a site—is really, really hard.

Responsive web design does not solve the context problem. It doesn’t even attempt to. The context problem is a very different issue to the viewport problem—which responsive web design does solve. As Mark put it:

It’s making sure your layout doesn’t look crap on diff. sized screens. Nothing more.

He was responding to Brian and Kevin who I think may have misunderstood the problems that responsive web design is trying to solve. Brian wrote:

anyone that claims “responsive design” as a best practice clearly has never actually tried to support multiple contexts or devices.

Those are two different issues: contexts and devices. The device issue breaks down into viewport size and bandwidth. Responsive design is certainly a best practice when tackling the viewport issue. But Brian’s right: responsive design does not solve the problem of different contexts. Nor did it ever claim to.

As I’ve said before:

The choice is not between using media queries and creating a dedicated mobile site; the choice is between using media queries and doing nothing at all.

If responsive design were being sold as a solution to the context problem, I too would be annoyed. But that’s not the case.

The mythical mobile context

As with the viewport issue and the bandwidth issue, the context issue—which has always been there—is now at the fore with the rise of mobile devices. As well as trying to figure out what a person wants when they visit a website, we now have to think about where they are, where they are going and where they have just been.

This is by far the toughest problem.

Bizarrely, this is the very known unknown that I see addressed as though it were solved. “Someone visits your site with a mobile device therefore they are in a rush, walking down the street, hurriedly trying to find your phone number!”

Really?

The data does not support this. All those people with mobile devices sitting on a train or sitting in a cafe or lounging on the sofa at home; they are all in a very different context to the imaginary persona of the mobile user rushing hither and thither.

We have once again created a consensual hallucination. Just as we generated a mythical desktop user with the perfect viewport size, a fast connection and an infinite supply of attention, we have now generated a mythical mobile user who has a single goal and no attention span.

More and more people are using mobile devices as a primary means of accessing the web. The number is already huge and it’s increasing every day. I don’t think they’re all using their devices just to look up the opening times of restaurants. They are looking for the same breadth and richness of experience that they’ve come to expect from the web on other devices.

Hence the frustration with mobile-optimised sites that remove content that’s available on the desktop-optimised version.

Rather than creating one site for an imaginary desktop user and another for an imaginary mobile user, we need to think about publishing content that people want while adapting the display of that content according to the abilities of the person’s device. That’s why I’m in favour of universal design and the One Web approach.

That’s also why responsive web design can be such a powerful tool. But make no mistake: responsive web design is there to help solve the viewport problem, not the context problem.

Update: Of course the usual caveat applies. Also, here’s some clarification about what I’m sugguesting.

Because I was so busy, the two-year anniversary of Huffduffer passed unnoticed back in October. Two years! It’s hard to believe. It seems like just yesterday that I launched it. It’s been ticking along nicely for all that time and I’ve been tweaking it whenever I get the chance.

I recently added oEmbed support. I’m very impressed with the humble little format. It’s basically a unified API onto the multiple embed codes provided by so many websites. You request a URL from an endpoint such as https://huffduffer.com/oembed?url= and you get back a JSON (or XML) file with the details of the HTML you need to embed the content—video, photo, whatever. Something like https://huffduffer.com/oembed?url=https://huffduffer.com/adactio/32454

YouTube, Flickr, Vimeo and a whole host of other sites support oEmbed and the Embedly service provides easy access to all of them. Now Huffduffer is listed amongst the 160 oEmbed providers supported by Embedly. Maybe if I make the right ritual sacrifices, perhaps Huffduffer players might start showing up in New Twitter: it uses a combination of oEmbed and a whitelist to display third-party content in the side panel.

I made some tweaks to the front-end of Huffduffer recently too. For starters, you might notice that the body copy font size has been bumped up from fourteen pixels to sixteen. While fourteen pixels is perfectly fine for Helvetica or Georgia, it’s just that little bit too small for Baskerville.

While I was in there messing around with the CSS, I took the opportunity to tweak the small screen rendering.

For a start, I changed the way that the media queries are executed. Instead of beginning with the wide-screen “desktop” layout as the default and then undoing the widths and floats for smaller screens, I’m now using the same technique I’ve tried out here on adactio.com: begin with a linear layout-less flow and only add widths and floats within media query blocks. That way, mobile devices that don’t support media queries will still get the linearised view.

The elephant in the room is, once again, Internet Explorer (below version nine, anyway). While I can quite merrily say “screw ‘em” here on adactio.com, I need to make more of an effort for Huffduffer. So I split up my CSS into two files: a global.css file that contains all the typography and colour rules, and layout.css that contains a default wide-screen “desktop” view followed by media queries for narrower widths. This is how I’m calling both stylesheets:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!--[if lt IE 9]>
<link rel="stylesheet" href="/css/layout.css" media="all">
<![endif]-->

See how the layout.css file is being called twice? Once for browsers that support media queries (with a browser width wider than thirty ems) and again for Internet Explorer less than version nine.

Mobile devices that don’t support media queries or conditional comments will never load the layout.css file. Browsers that do support media queries, be they mobile or desktop, will only execute layout.css if the viewport is at least thirty ems wide. Legacy versions of Internet Explorer will always load layout.css because of the conditional comment. It’s entirely possible that Windows Mobile 7 will also load layout.css because the browser is currently using an IE7 codebase (Trident 3.1, to be precise). Screw ‘em …at least until Microsoft bring out an update.

The disadvantage of this technique is that my CSS is now split up into two separate files. I’d much rather keep HTTP requests to a minimum by having just one style sheet, but I think that, in this case, the reward in cross-browser compatibility is worth the expense of that extra hit.

While I was testing the changes, I noticed something interesting on my iPod Touch when I was at the Clearleft office, where we have the stereo connected to the WiFi network. The most recent iOS update allows you to stream directly from your device to your stereo or television. What I didn’t realise was that this is true of any media, including HTML5 video and audio content in a web page. Nice!

It’s the start of the Christmas season. I know it’s the start of the Christmas season, not just because Brighton is currently blanketed in snow, but also because 24 Ways—the advent calendar for geeks—has kicked off with its first article. Hurray! And this year, all of the articles will be available as a book from Five Simple Steps for a mere £8, with all the proceeds going to charity. Grab a copy before the end of December because this is a time-limited offer.

This year, 24 Ways isn’t the only advent calendar for geeks. While I was off galavanting up and down the west coast of the US last month, my cohorts at Clearleft were scheming up a little something special: an advent calendar for fonts. Every day, for 24 days, release a Fontdeck font for one year’s free use.

When they told me, I thought “great idea!” …then they told me they were going to call it an “adfont” calendar and there was much groaning and gnashing of teeth.

The Adfont Calendar 2010 (groan) is now live.

The lovely visual design comes courtesy of Michelle, the latest addition to the Clearleft team, and it mimics a type case; just like the one we happen to have in the office. Every office needs a type case.

Originally, the interface was going to be one looooong type case with some JavaScript layered on top to allow smooth horizontal navigation. But when Rich asked me for some advice on implementing it, I steered him down a different path. Instead of displaying everything horizontally, why not use media queries to show just enough drawers to fit the user’s browser window and allow the rest to stack vertically?

I didn’t think he’d take my challenge seriously but he’s only gone and bloody done it!

Have a poke around and see what’s behind drawer number one.

I went along to the fifth Barcamp Brighton on the weekend. It was a truly excellent event, hosted in The Skiff, a great coworking space. Alas, a creeping cold meant that I couldn’t stick around for too long, but I made sure to give a presentation before I bailed.

I spoke about media queries. As you may have gathered from my recent entries, this is something I’ve been thinking about a lot lately.

I didn’t prepare any slides. If I had, they would have consisted of screenshots and CSS, so I figured why not just show the actual sites and CSS instead? It was a fairly rambling, chaotic presentation but it helped me to clarify some ideas. Prem asked if I would reprise the presentation at Async—Brighton’s JavaScript meetup—on October 28th so that will give me a chance to marshall my thoughts.

In reiterating my point about fluid grids being a necessary prerequisite for responsive web design, I tried to take a long-zoom approach and went all the way back to John’s superb A Dao of Web Design article—now ten years old!

The tool problem

I still feel that most designers haven’t yet fully embraced the web as its own medium, choosing instead to treat it along the same lines as print design. Or, as Mark put it his excellent talk on designing grid systems, designing from the canvas in rather than the content out.

Far too early in the design process, a tool such as Photoshop or Fireworks gets opened up and a new file is created with an arbitrary width (960 pixels being the current width du jour). That process lends itself well to creating paintings of websites but it’s not a great first step in creating a living, breathing website. Experiments like Liz’s Evening Edition not withstanding, what I wrote back in 2006 still holds true:

CSS hasn’t revolutionised web design. The reason lies not with the technology (which is revolutionary), but with the designers using it. Most designers have simply swapped the old technology (tables and font tags) for the new technology, without fully exploring what’s so completely new.

My point is that responsive web design isn’t something that can be tacked on to the end of an existing workflow. It requires a different mindset, one that considers the medium from the outset. If you’re currently thinking in proportions rather than pixels, the transition to responsive web design will be relatively painless. But if you’re stuck in the world of converting PSDs into web pages, you’re going to have a tough time.

I’ve written about the problems with our tools before and Stan has crafted the definitive call to arms for A Real Web Design Application so I’ll spare you another rant.

A new approach

At Barcamp Brighton, I encapsulated my thinking by saying:

Instead of thinking in terms of pixel perfection, we should be thinking of proportion perfection.

Then I showed a bunch of sites I’ve worked on that are using media queries to adapt to different screen sizes: Huffduffer, Salter Cane, St. Paul’s School and UX London.

All of those sites are built in a similar way. First, CSS is used to create the optimal layout e.g. three columns floated alongside one another. Then media queries are used to over-ride those float and width declarations so that the content is linearised.

That’s all well and good but, as someone correctly pointed out during the presentation, what about small-screen devices that don’t support media queries?

That’s an excellent question. The answer requires another shift in perspective. Instead of thinking of the widescreen version as the starting point, why not consider the small screen layout first?

In a way, this is an extension of Luke’s Mobile First exercise — thinking of the mobile experience before building the desktop site.

In his presentation at Over The Air, Bryan Rieger advocated this approach for media queries. As he correctly points out—and this is something echoed by PPK—what we’re talking about here is essentially progressive enhancement.

Instead of just using progressive enhancement to throw in some rounded corners, opacity or gradients, we can apply the same thinking to layout: start with the most basic CSS—colours, fonts, etc.—and then apply floats and widths according to the capabilites of the browser …as determined by media queries.

That’s what I did for the Science Hack Day website and now I’ve decided to take the same approach with adactio.com.

At this point, you might be wondering if I’m going to mention the elephant in the room. You know: the elephant …from Microsoft …elephant versions 8 and lower.

My first thought was to use conditional comments. All browsers get the same stylesheet but elephantine browsers get an extra one which contains the same float and width declarations that are contained in the media queries. But that violates the DRY principle: any time I make a layout change, I would have to remember to make the changes in two different stylesheets. Prem suggested placing an @import rule within the media query to pull in the same stylesheet that IE is getting via conditional comments …but alas, @import rules need to come first in a CSS document.

So, for now, users of Internet Explorer visiting adactio.com will just get the linearised content. I may decide to violate the DRY principle and use conditional comments at a later date.

Revisiting adactio.com

Over the years, I’ve resisted the temptation to do a complete redesign of my site. Instead, I’ve added different designs as options that can be selected from any page on the site. After all, isn’t the whole point of CSS that it’s separated from the structure? Changing the visual appearance shouldn’t necessitate changing the markup; that’s the lesson of the CSS Zen Garden.

So I’ve stubbornly refused to update my markup for almost ten years. But now, what with having written a book on HTML5 and all, I figured I could make a few changes.

The doctype has been updated. Elements that had previously been given IDs are now identified with ARIA landmark roles instead (and referenced in the CSS with attribute selectors). These days, I rarely use IDs for anything other than making document fragments addressable, so it was interesting to see how my past self did things differently.

My past self was also trying to be far too clever with the separation of concerns in the CSS. I was using three different stylesheets for each theme: one for colour, one for typography, and one for layout. In retrospect, this was a bad idea for two reasons:

1. I’m increasing the number of HTTP requests.
2. While it might be obvious that font-family declarations belong in the typography stylesheet and background-color declarations belong in the colour stylesheet, it’s not nearly so simple to figure out where margins and paddings should go. Is that layout? Is it typography?

It turns out that a more holistic approach to CSS is far, far easier to work with. It felt good to finally merge those separate CSS files into one.

Oh, there was one more good point raised at the Barcamp Brighton presentation… I had being going on about how assumptions can be dangerous—assuming that the user is visiting your site from a desktop machine, assuming that a large monitor size equates to a large viewport size, assuming that a large browser window means that large bandwidth is available, and so on. Somebody pointed out that, in applying my media queries using pixels, I was making assumptions about equating pixel width to viewable area. An excellent point! For that reason, all the media queries used in the different themes on adactio.com are triggered with ems rather than pixels.

For the record, here are some useful em widths that can be used as trigger points:

• 40em =~ 640px
• 50em =~ 800px
• 64em =~ 1024px

Default

Tate Modern

Seaside

Zeldman

Adactizilla

Sci-fi

Renaissance

Hirnlego

Another week, another responsive web site.

Two weeks ago, it was St. Paul’s School. Last week, it was Salter Cane. This week, I’ve been working on next year’s UX London site, implementing a nice little design refresh courtesy of Paul.

More pages will be added soon but for now, it’s essentially like a poster for the conference.

Back when I was working on the first UX London site two years ago, I was building it together with Natalie, and I mean literally together: we were pair-programming. Well, I guess programming isn’t quite right for HTML and CSS, but we were pair-writing. It was an excellent experience.

Anyway, Natalie being Natalie, the UX London site was built with rock-solid markup with a flexible layout. All the pieces were in place for a responsive web design so once I was done with the current refresh, I spent a few minutes writing some media queries.

You can see the results for yourself.

Hot on the heels of the work for St. Paul’s School, I’ve been tweaking the media queries for the Salter Cane website. I was switching the site over to using HTML5 structural elements anyway, so I figured I’d meddle with the CSS while I was at it.

Once again, the fact that the site was already using percentages made the process very straightforward. Depending on the viewport width, the layout changes from three columns to two columns to one column.

And once again, I didn’t remove any content for small screen devices. The natural language navigation at the top of the page—now correctly ensconced in a nav element—really comes into its own in the linearised layout, allowing for quick access to different sections of the document.

The timing of all this optimisation is fortuitous. The second Salter Cane album has just been released: it’s called Sorrow.

It already has some fans. Shaun said:

The Truth Is Nothing sounds like Leonard Cohen, Johnny Cash and Arcade Fire had a musical transporter accident. can’t stop listening to it.

Lachlan is equally enthusiastic. If you like what you hear, you can buy the physical album from CD Baby or buy the digital album from iTunes. It will be available on Spotify and Amazon soon.

All the songs are licensed under a Creative Commons attribution license which means that they are podsafe. I’m looking forward to seeing where they end up.

You can listen to the whole album on the Salter Cane site using a Flash MP3 player. The documentation for Audio Player reads:

To insert a player on the page, place an HTML element and give it a unique ID. This element will be replaced with a player. If the browser doesn’t support Audio Player, the element will not be replaced so use it to show alternative content (maybe a message telling the user to download Flash).

The example code looks like this:

<p id="audioplayer_1">Alternative content</p>
<script type="text/javascript">
AudioPlayer.embed("audioplayer_1", {soundFile: "file.mp3"});
</script>

But rather than using a P element, I used the HTML5 audio element:

<audio id="audioplayer_1" src="file.mp3" controls="controls" preload="none">
</audio>  
<script>  
AudioPlayer.embed("audioplayer_1", {soundFile: "file.mp3"});  
</script>

That way, browsers with Flash installed get the plugin while other devices—like, say, the iPhone, iPod and iPad—get the native audio player.

Whatever device you’re using, enjoy listening to Sorrow by Salter Cane.

Ethan is a brilliant person. Responsive web design is a brilliant technique. These two facts are related.

As Ethan recently clarified:

A responsive design is composed of three distinct parts:

1. A flexible grid.
2. Flexible images. Or more specifically, images that work in a flexible context (whether fluid themselves, or perhaps controlled via overflow).
3. Media queries. The final layer of a responsive design, media queries optimize the design for different viewing contexts, and that spot-fix bugs that occur at different resolution ranges.

There has been a lot of discussion on that third part—including a superb presentation by Bryan Rieger—but there has been less emphasis on those first two parts. Anyone hoping to take an existing fixed-width rigid design and adapt it for smaller screen widths using media queries is going to be disappointed and frustrated.

I recently had to adapt an existing layout for varying screen widths. Clearleft did some design and development work for St. Paul’s School, where the thoroughly lovely David Smith is a teacher. I didn’t have much to do with that initial work. Cennydd worked on the information architecture, JayBay created the beautiful visual design and Natalie produced the HTML, CSS and JavaScript. But when they asked for some small-screen optimisation, the task fell to me.

It was a breeze. Because Natalie’s markup and CSS was rock-solid, I was able to whip up some alternate layouts in no time. The fact that the site was already using a fluid grid and fluid images was crucial.

The site now goes from a three-column layout (on browsers wider than 800 pixels) to a two-column layout (on browsers between 800 and 640 pixels) to a single column layout (on browsers less than 640 pixels). I spent some time finessing the details but the lion’s share of the work was done in the first hour.

Notice that I don’t refer to this as mobile optimisation. This is about user-agents with narrow screens. Now, some of those user-agents will be running on handheld devices (whatever that means, these days) and the site certainly looks good on some mobile devices, such as the iPhone, the iPod Touch, the iPad and Android phones. But it works equally well on desktop or laptop-bound user-agents with narrow screen widths.

Some people have misinterpreted the power of responsive web design as being a claim to the title of silver bullet for the mobile context. That’s never been the case. If your content would benefit from a completely different approach when viewed on the go, and you’ve got the time and budget to create a separate mobile site, then go for it (though you may end up going down the rabbit hole of figuring out which devices qualify as mobile and which of those you can support).

But if you’re building your sites the right way anyway, with fluidity and flexibility baked in from the start, then it’s certainly worth spending a few minutes to bash out a couple of quick media queries to optimise for small-screen devices.

The choice is not between using media queries and creating a dedicated mobile site; the choice is between using media queries and doing nothing at all.

That said, in many situations the content you want to serve up will be the same regardless of context. Take Huffduffer, for example. There’s nothing I want to strip out of the pages when they’re served up to mobile devices.

This harks back to what Luke has been saying with his Mobile First talk at An Event Apart. Instead of beginning with a big ol’ desktop site and asking What can I take away for mobile?, ask instead why all that stuff is clogging up your desktop site to begin with. Just because you’ve given yourself 960 pixels to play with—or whatever arbitrary number is the current fave of fixed-width designs—doesn’t mean that every piece of screen real estate needs to be filled up.

Another complaint levelled at media queries is when they are used to over-ride background-image declarations or to apply display: none to images: Those images are still downloaded by the mobile user! It’s a fair point but I would turn it on its head: why the sudden concern about bandwidth when dealing with the mobile context? Performance should be a priority for all your users, regardless of screen size or user-agent. If a large image can be hidden from mobile users, why is it being served up to other users?

That’s the thing about responsive web design: you can’t just think of it as a sprinkle of pixie dust that can be applied to any site. It requires the right mindset. It requires that sites be built on solid foundations of best practice. If those foundations are in place—a flexible layout, flexible images, optimised performance—then responsive web design can work its magic.

In the case of St. Paul’s School and its sister-site Colet Court, the foundations couldn’t have been better.