Skip to main content

More on CSS Media Queries for Mobile

By Jason Grigsby

Published on August 7th, 2010


My previous post on CSS Media Queries kicked off quite a bit of conversation. I wanted to follow up on a few points that have been made and a couple of things I failed to communicate well in the original post.

One of the unfortunate side effects of the strident title I chose was that it gave many people the impression that I didn’t think CSS Media Queries were useful at all for mobile.

That’s not the case. We’re using them in two mobile projects right now and contemplating using them for a third.

I wrote in the post that “CSS media queries are a tool, but they are not a silver bullet.” But that point was overshadowed by the post title and the rest of the article talking about the problems that you need to be aware of when using them.

I got a chance to chat with Ethan Marcotte via Twitter. He wrote:

I think we agree on the fundamental points, honestly—the implementation should always be tailored to the site/audience.

I wholeheartedly agree. In fact, Ethan wrote in his article about Responsive Web Design:

That’s not to say there isn’t a business case for separate sites geared toward specific devices; for example, if the user goals for your mobile site are more limited in scope than its desktop equivalent, then serving different content to each might be the best approach.

In the same way in which my more nuanced opinion about media queries was skewed by my poor choice of title, I think Ethan’s nuanced opinion about when and how media queries can be used for mobile has been skewed by the enthusiasm that people had in response to his A List Apart article and how they might use the technique for mobile.

As I said in my post and reaffirmed to Ethan over Twitter, I’m actually quite excited about Responsive Web Design. I’m going to write more about that separately.

Even though Ethan never intended media queries to be seen as a total solution for mobile, that view has been enthusiastically adopted by others. I’ve read many blog posts and tweets on the topic. There was a session at Web Visions called Mobile Web Dev without Developing a Mobile Site based on building sites using media queries.

PPK got is right when he said that I “challenged the conventional view that media queries are all we need to make a website mobile-friendly.” There was a growing consensus that media queries were all that was needed and that consensus needed to be challenged.

In rereading my post, there is one sentence that I think best summarizes my view:

The way in which CSS media query has been promoted for mobile hides tough problems and gives developers a false promise of a simple solution for designing for multiple screens.

I’ve modified the sentence slightly to make it clearer that it was the way media queries were being promoted as a solution for mobile that was the real problem.

It is also clear that fool’s gold is not the right phrase. Fool’s gold is something that looks like something of worth, but in reality has no intrinsic value. Media queries do have value and are useful tools.

I’m sorry for poor title choice.

There are a few great use cases for media queries for mobile. I highlighted selected web apps and html emails in my previous email. A few others are:

  • As PPK suggests, pairing media queries with javascript could be the core of a mobile web solution. The javascript can be used to swap the correct images in for each context. This is most effective if you start from a mobile design and use media queries and javascript to add functionality for desktop users. You also need to understand which devices your customers are using to make sure this technique works for those browsers.
  • As Pim Derks commented on my post, in situations where “a client has a limited budget, but wants his site to look good on iPhone.” Given the alternative of no mobile web site, it makes sense. I’d suggest looking to see what you can do to stop unnecessary downloads where possible.
  • And the most likely use of media queries, as a small part of a larger mobile optimization effort or a discrete tool being used in one off situations like web apps or html emails.

You’ll notice that the solution that PPK suggests is quite a bit different than starting from the desktop web and simply adding media queries.

It requires images to be uploaded in multiple sizes. For optimal use, it requires html to be retooled to start with mobile web appropriate html only and then javascript to enhance it.

It is entirely possible that a great mobile solution could be built that way. I question the likelihood that web sites are going to be retooled to deliver mobile html first and then progressively enhanced with javascript and css. But I’d be happy to be wrong about that.

I’ve enumerated many of the technical challenges with media queries, but when I talk about media queries hiding tough problems, I’m not talking about any of the issues I raised in my previous post.

What I was referring to was the idea that there was a simple solution to creating a mobile web site obscures a series of infrastructure issues that I believe web developers are going to be confronting over the next few years.

Let’s assume for a moment that there are situations in which you need to deliver different html and associated assets to different mobile devices. To do so requires that your content management or ecommerce system is equipped to do the following:

  • Detect different devices and the capabilities of those devices.
  • Select the correct template based on the device. This implies that your system gracefully handles multiple templates.
  • Separate assets added by authors from the words that they write so that those photos, video, etc. can be resized and reformatted appropriately for the device.
  • Provide tools or establish processes for resizing images and videos. Either manually, or better yet automatically, encode video in multiple formats based on the device.
  • Support non-web consumption of content (e.g., native applications). This will likely require further consideration of how to remove markup and presentation from content.

And many more obstacles created by legacy web publishing tools designed long before we started thinking seriously about mobile.

The big challenges our clients face are rethinking and retooling their infrastructure for mobile. It’s going to be a massive undertaking for a lot of businesses.

The sooner we realize this fact, the sooner we can get to work figuring out the best ways to build that infrastructure.


James Pearce said:

I think you’re more or less preaching to the converted at this point 🙂

Still, I would reiterate that the biggest challenge is not retooling the infrastructure (that’s “just a small matter of software”), but it is thinking more carefully about what mobile users actually want. Clue: it’s not your desktop web site with nifty fluid CSS.

Perhaps the reason that people have flocked to develop client apps for web-like services is not because the tech is inherently superior (it isn’t… see ) but because it has allowed them to break free of the assumption that they have to use the same IA, URL structure, theme elements etc as their desktop site – all of which probably seems like too much of a drag.

“Open a fresh instance of XCode and you have a blank slate!” – perhaps we should be encouraging mobile web designers to be as bold as this when (re-)inventing a company’s mobile web presence: don’t assume you have to start with the desktop version.

(If you aren’t that brave, then of course limply throwing clever CSS at your current site probably does seem like the easiest way to avoid these hard choices.)

Jason Lander said:

another great post jason. i fully agree that there is no one size fits all solution. one of the challenges we face is convincing clients they need a mobile strategy and getting them to invest in it. to date, many of our clients will not. however, they will opt for a less optimal solutions such as making the site at least look presentable in smart phones, based on media queries, just as you’ve suggested. at least it’s a start.

Jason Grigsby (Article Author ) said:

@James A year ago I would have agreed it was just software, but my conversations over the last nine months have convinced me the infrastructure is a big problem.

You wrote:

“Perhaps the reason that people have flocked to develop client apps for web-like services is not because the tech is inherently superior (it isn’t… see ) but because it has allowed them to break free of the assumption that they have to use the same IA, URL structure, theme elements etc as their desktop site – all of which probably seems like too much of a drag.”

There are many reasons why people choose to do native apps. I’ve written about five of them here:

To your point of breaking free with a clean slate so that they can design an experience that is truly mobile, I think we’re saying similar things. My point would be that you can’t break free until you rethink your architecture.

One of the great things about native clients is that they can skip all of the legacy systems and interact directly with web services APIs. If APIs don’t exist, then they have to be built.

But when someone sits down to figure out the mobile web, they look at their CMS and try to figure out how to get their CMS to output mobile content. That becomes a much bigger barrier.