Responsive Web Design
Issue № 306

Responsive Web Design

by
Published in CSS, Interaction Design, Layout & Grids, Mobile/Multidevice, Responsive Design

The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility. But first, we must 'accept the ebb and flow of things.'

John Allsopp, “A Dao of Web Design”

The English architect Christopher Wren once quipped that his chosen field “aims for Eternity,” and there’s something appealing about that formula: Unlike the web, which often feels like aiming for next week, architecture is a discipline very much defined by its permanence.

Article Continues Below
Article Continues Below

A building’s foundation defines its footprint, which defines its frame, which shapes the facade. Each phase of the architectural process is more immutable, more unchanging than the last. Creative decisions quite literally shape a physical space, defining the way in which people move through its confines for decades or even centuries.

Working on the web, however, is a wholly different matter. Our work is defined by its transience, often refined or replaced within a year or two. Inconsistent window widths, screen resolutions, user preferences, and our users’ installed fonts are but a few of the intangibles we negotiate when we publish our work, and over the years, we’ve become incredibly adept at doing so.

But the landscape is shifting, perhaps more quickly than we might like. Mobile browsing is expected to outpace desktop-based access within three to five years. Two of the three dominant video game consoles have web browsers (and one of them is quite excellent). We’re designing for mice and keyboards, for T9 keypads, for handheld game controllers, for touch interfaces. In short, we’re faced with a greater number of devices, input modes, and browsers than ever before.

In recent years, I’ve been meeting with more companies that request “an iPhone website” as part of their project. It’s an interesting phrase: At face value, of course, it speaks to mobile WebKit’s quality as a browser, as well as a powerful business case for thinking beyond the desktop. But as designers, I think we often take comfort in such explicit requirements, as they allow us to compartmentalize the problems before us. We can quarantine the mobile experience on separate subdomains, spaces distinct and separate from “the non-iPhone website.” But what’s next? An iPad website? An N90 website? Can we really continue to commit to supporting each new user agent with its own bespoke experience? At some point, this starts to feel like a zero sum game. But how can we—and our designs—adapt?

A flexible foundation#section2

Let’s consider an example design. I’ve built a simple page for a hypothetical magazine; it’s a straightforward two-column layout built on a fluid grid, with not a few flexible images peppered throughout. As a long-time proponent of non-fixed layouts, I’ve long felt they were more “future proof” simply because they were layout agnostic. And to a certain extent, that’s true: flexible designs make no assumptions about a browser window’s width, and adapt beautifully to devices that have portrait and landscape modes.

Huge images are huge. Our layout, flexible though it is, doesn’t respond well to changes in resolution or viewport size.

But no design, fixed or fluid, scales seamlessly beyond the context for which it was originally intended. The example design scales perfectly well as the browser window resizes, but stress points quickly appear at lower resolutions. When viewed at viewport smaller than 800×600, the illustration behind the logo quickly becomes cropped, navigation text can wrap in an unseemly manner, and the images along the bottom become too compact to appear legible. And it’s not just the lower end of the resolution spectrum that’s affected: when viewing the design on a widescreen display, the images quickly grow to unwieldy sizes, crowding out the surrounding context.

In short, our flexible design works well enough in the desktop-centric context for which it was designed, but isn’t optimized to extend far beyond that.

Becoming responsive#section3

Recently, an emergent discipline called “responsive architecture” has begun asking how physical spaces can respond to the presence of people passing through them. Through a combination of embedded robotics and tensile materials, architects are experimenting with art installations and wall structures that bend, flex, and expand as crowds approach them. Motion sensors can be paired with climate control systems to adjust a room’s temperature and ambient lighting as it fills with people. Companies have already produced “smart glass technology” that can automatically become opaque when a room’s occupants reach a certain density threshold, giving them an additional layer of privacy.

In their book Interactive Architecture, Michael Fox and Miles Kemp described this more adaptive approach as “a multiple-loop system in which one enters into a conversation; a continual and constructive information exchange.” Emphasis mine, as I think that’s a subtle yet powerful distinction: rather than creating immutable, unchanging spaces that define a particular experience, they suggest inhabitant and structure can—and should—mutually influence each other.

This is our way forward. Rather than tailoring disconnected designs to each of an ever-increasing number of web devices, we can treat them as facets of the same experience. We can design for an optimal viewing experience, but embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them. In short, we need to practice responsive web design. But how?

Meet the media query#section4

Since the days of CSS 2.1, our style sheets have enjoyed some measure of device awareness through media types. If you’ve ever written a print style sheet, you’re already familiar with the concept:

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

In the hopes that we’d be designing more than neatly formatted page printouts, the CSS specification supplied us with a bevy of acceptable media types, each designed to target a specific class of web-ready device. But most browsers and devices never really embraced the spirit of the specification, leaving many media types implemented imperfectly, or altogether ignored.

Thankfully, the W3C created media queries as part of the CSS3 specification, improving upon the promise of media types. A media query allows us to target not only certain device classes, but to actually inspect the physical characteristics of the device rendering our work. For example, following the recent rise of mobile WebKit, media queries became a popular client-side technique for delivering a tailored style sheet to the iPhone, Android phones, and their ilk. To do so, we could incorporate a query into a linked style sheet’s media attribute:

<link rel="stylesheet" type="text/css"
  media="screen and (max-device-width: 480px)"
  href="shetland.css" />

The query contains two components:

  1. a media type (screen), and
  2. the actual query enclosed within parentheses, containing a particular media feature (max-device-width) to inspect, followed by the target value (480px).

In plain English, we’re asking the device if its horizontal resolution (max-device-width) is equal to or less than 480px. If the test passes—in other words, if we’re viewing our work on a small-screen device like the iPhone—then the device will load shetland.css. Otherwise, the link is ignored altogether.

Designers have experimented with resolution-aware layouts in the past, mostly relying on JS-driven solutions like Cameron Adams’ excellent script. But the media query specification provides a host of media features that extends far beyond screen resolution, vastly widening the scope of what we can test for with our queries. What’s more, you can test multiple property values in a single query by chaining them together with the and keyword:

<link rel="stylesheet" type="text/css"
  media="screen and (max-device-width: 480px) and (resolution: 163dpi)"
  href="shetland.css" />

Furthermore, we’re not limited to incorporating media queries in our links. We can include them in our CSS either as part of a @media rule:

@media screen and (max-device-width: 480px) {
  .column {
    float: none;
  }
}

Or as part of an @import directive:

@import url("shetland.css") screen and (max-device-width: 480px);

But in each case, the effect is the same: If the device passes the test put forth by our media query, the relevant CSS is applied to our markup. Media queries are, in short, conditional comments for the rest of us. Rather than targeting a specific version of a specific browser, we can surgically correct issues in our layout as it scales beyond its initial, ideal resolution.

Adapt, respond, and overcome#section5

Let’s turn our attention to the images at the base of our page. In their default layout, the relevant CSS currently looks like this:

.figure {
  float: left;
  margin: 0 3.317535545023696682% 1.5em 0;   /* 21px / 633px */
  width: 31.121642969984202211%;             /* 197px / 633px */
}li#f-mycroft,
li#f-winter {
  margin-right: 0;
}

I’ve omitted a number of typographic properties to focus on the layout: Each .figure element is sized at roughly one third of the containing column, with the right-hand margin zeroed out for the two pictures at the end of each row (li#f-mycroft, li#f-winter). And this works fairly well, until the viewport is either noticeably smaller or wider than our original design. With media queries, we can apply resolution-specific spotfixes, adapting our design to better respond to changes in the display.

First of all, let’s linearize our page once the viewport falls below a certain resolution threshold—say, 600px. So at the bottom of our style sheet, let’s create a new @media block, like so:

@media screen and (max-width: 600px) {
  .mast,
  .intro,
  .main,
  .footer {
    float: none;
    width: auto;
  }
}

If you view our updated page in a modern desktop browser and reduce the size of your window below 600px, the media query will disable the floats on the design’s major elements, stacking each block atop each other in the document flow. So our miniaturized design is shaping up nicely, but the images still don’t scale down that intelligently. If we introduce another media query, we can alter their layout accordingly:

@media screen and (max-width: 400px) {
  .figure,
  li#f-mycroft {
    margin-right: 3.317535545023696682%;    /* 21px / 633px */
    width: 48.341232227488151658%;          /* 306px / 633px */
  }  li#f-watson,
  li#f-moriarty {
    margin-right: 0;
  }
}

Our figures can responsively change their layout to better suit smaller displays.

Don’t mind the unsightly percentages; we’re simply recalculating the widths of the fluid grid to account for the newly linearized layout. In short, we’re moving from a three-column layout to a two-column layout when the viewport’s width falls below 400px, making the images more prominent.

We can actually take the same approach for widescreen displays, too. For larger resolutions, we could adopt a six-across treatment for our images, placing them all in the same row:

@media screen and (min-width: 1300px) {
  .figure,
  li#f-mycroft {
    margin-right: 3.317535545023696682%;    /* 21px / 633px */
    width: 13.902053712480252764%;          /* 88px / 633px */
  }
}

Now our images are working beautifully at both ends of the resolution spectrum, optimizing their layout to changes in window widths and device resolution alike.

By specifying a wider min-width in a new media query, we can shift our images into a single row layout.

But this is only the beginning. Working from the media queries we’ve embedded in our CSS, we can alter much more than the placement of a few images: we can introduce new, alternate layouts tuned to each resolution range, perhaps making the navigation more prominent in a widescreen view, or repositioning it above the logo on smaller displays.

By designing responsively, we can not only linearize our content on smaller devices, but also optimize its presentation across a range of displays.

But a responsive design isn’t limited to layout changes. Media queries allow us to practice some incredibly precise fine-tuning as our pages reshape themselves: we can increase the target area on links for smaller screens, better complying with Fitts’ Law on touch devices; selectively show or hide elements that might enhance a page’s navigation; we can even practice responsive typesetting to gradually alter the size and leading of our text, optimizing the reading experience for the display providing it.

A few technical notes#section6

It should be noted that media queries enjoy incredibly robust support among modern browsers. Desktop browsers such as Safari 3+, Chrome, Firefox 3.5+, and Opera 7+ all natively parse media queries, as do more recent mobile browsers such as Opera Mobile and mobile WebKit. Of course, older versions of those desktop browsers don’t support media queries. And while Microsoft has committed to media query support in IE9, Internet Explorer currently doesn’t offer a native implementation.

However, if you’re interested in implementing legacy browser support for media queries, there’s a JavaScript-tinted silver lining:

  • A jQuery plugin from 2007 offers somewhat limited media query support, implementing only the min-width and max-width media properties when attached to separate link elements.
  • More recently, css3-mediaqueries.js was released, a library that promises “to make IE 5+, Firefox 1+ and Safari 2 transparently parse, test, and apply CSS3 Media Queries” when included via @media blocks. While very much a 1.0 release, I’ve personally found it to be quite robust, and I plan to watch its development.

But if using JavaScript doesn’t appeal, that’s perfectly understandable. However, that strengthens the case for building your layout atop a flexible grid, ensuring your design enjoys some measure of flexibility in media query-blind browsers and devices.

The way forward#section7

Fluid grids, flexible images, and media queries are the three technical ingredients for responsive web design, but it also requires a different way of thinking. Rather than quarantining our content into disparate, device-specific experiences, we can use media queries to progressively enhance our work within different viewing contexts. 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.

But that kind of design thinking doesn’t need to be our default. Now more than ever, we’re designing work meant to be viewed along a gradient of different experiences. Responsive web design offers us a way forward, finally allowing us to “design for the ebb and flow of things.”

100 Reader Comments

  2. Thank you Ethan, for a very well written article. I love your architectural references and completely agree with the direction you’re suggesting. With css transitions added to the mix we can give media queries some smoothness when they kick in, which makes for beautiful transitions when you switch a device from portrait to landscape.

    Which brings me to another point: the mere fact that millions of people are now playing with devices that can be held in 2 ways (portrait/landscape) means that the statement “nobody resizes their browser window” is no longer valid. Now everybody resizes their browser window all the time.

    Cheers.

  3. First of all, Ethan — your name is awesome. Just FYI.

    But seriously, thanks for your note. I don’t think we’re sunk, though: media query support is fairly robust in the current generation of non-desktop devices, and will likely only improve from there. In devices (or browsers) that don’t natively understand media queries (or the JS patches for them), I believe that only strengthens the case for working with a flexible foundation.

    Thomas, you’re exactly right about how viewport resolution is much more flexible than it used to be. And I do believe you just blew my mind on mixing in transitions. I have no idea how (or if) that would work, but I’d love to try it. Brilliant.

  4. It’s possible that I’m mistaken, but I’m fairly certain it’s quite unnecessary to specify percentage widths to 18 decimal places.

  5. I discovered the the style sheet itself is ignored in IE if you use media queries. Which means I can use IE conditional comments to includes the correct stylesheets for IE on the desktop.

    Who uses internet explorer on a mobile device?? Well I don’t, and most people won’t. So does it matter that the media queries are not suppoprted?

    You can still get a website to render correctly on IE, and still use the media queries for your mobile browser (which will be mozilla,webkit,opera based). It may not perfect – but it’s a good solution which I have used myself successfully…

  6. I think media queries are a step in the right direction but don’t quite get at the real information we’re trying to attain. Screen resolution works great for the basic Web experience when you are toggling between desktop and mobile device; but falls short when we reach tablets, netbooks and other devices with varying levels of interaction.

    As your average netbook will have the same resolution as something like a modern tablet, the experience is night and day different between the touch device and using a mouse. You touched on this briefly with Fitt’s Law, and anyone who has tried to use Yahoo! Fantasy Sports on an iPad can contest to the vastly different UX a larger-than-phone touch device has. And that it is pretty independent of the screen size.

    I totally agree that media queries probably are the answer we have for now, but I think the real thing we will want to target is general screen size for layout AND peripheral device being used (be it finger or mouse/stylus). Then we’ll really be able to create responsive sites and applications.

    Very interesting and thought-provoking read, thanks for putting this together.

    my2cents

  7. Ethan, thank you so much. This article opened my mind for the possibilities. I also enjoyed the way you took attention to the example layout. It’s so beautifully designed and well planned. I always hated fluid layouts because of their common trend of having narrow columns and giant width main areas, making body text awful to read. Designing for bigger resolutions is something people forget to do, and you worked out this in such a intelligent way. Finally I can see the power of fluid, adaptable layouts.

  8. Great article, Ethan. I’ve enjoyed watching this topic of yours progress over time and this article is another nice improvement on the approach.

    I’ve been wondering though: do you think the resolution-based media query is a forward-looking solution? How can it scale to support higher resolution phones like the Nexus One (or perhaps even the next iPhone)? When handheld resolutions start to blur with screen resolutions, will device-max-width be relevant for delivering finger-friendly layouts?

  9. Great article, Ethan.

    I just wanted to point out what I think is a small error in the article. When you talk about adding a query for larger screen sizes, your code reads (min-width: 1300px;)… however, the caption for the example image reads, “By specifying a wider max-width…”

    Don’t you mean to say “…wider min-width” in the caption?

  10. Why do you think the semi-colon is omitted from the end of the declaration? This contradicts the way we have been writing CSS since the beginning of time. Any idea why the switch to using “and” instead of the commas & semicolons we are used to?

    Why not this:

    
media screen, (min-width: 1300px) {
media screen, (min-width: 400px; max-width: 700px) {

    instead of this:

    
media screen and (min-width: 1300px) {
media screen and (min-width: 400px) and (max-width: 700px) {

    Any thoughts?

  11. Came across this article while searching for the answer to the question “What are the performance implications of using @media?”

    Yslow recommends using <link rel=”stylesheet”, and pageSpeed reccomends combining multiple style sheets, best to suit both rules using @media inside the unified style sheet, but is this any better performance-wise??

  12. I second the question brought up by @Toby.

    What are the performance implications in using the @media query in the stylesheet as opposed to the media attribute in the LINK tag?

    But I have to say Ethan, this is a brilliant article. Bravo!

  14. Firstly, allow me to jump on the (justly-deserved) bandwagon of praise; absolutely fantastic article, Ethan!

    A brief proposal regarding rectifying too-long lines of text at very wide resolutions:

    What if you were to use a media query to activate CSS column properties for bodies of text when the viewport exceeds a certain width? I realize that CSS columns are still in their infancy, support-wise, but I tested my idea with your classy “Baker Street Inquirer” example and the results were quite nice, I think.

  16. I’ve been offline today, but thanks so very much for the great feedback—I really appreciate the thoughtful discussion.

    camerondaigle, that’s a casualty of using TextMate to parse calculations with Google Calculator. I used to use Calculator.app, but started relying on TM because it’s so easy to use.

    deanoj, I haven’t seen the IE issue you mentioned. My experience has been that @@media@ blocks are ignored by IE, but the rest of the CSS is still parsed successfully. But I’d have to investigate that further.

    Tim Wright, thanks very much for your feedback. And I completely agree: as we saw with media types, the market can quickly outpace the spec, and our detection methods may (or may not) play out. Time will tell. But I’m optimistic that media queries are right for, well, right now.

    Scott, you grabbed the very resource I was going to respond with. PPK(Peter-Paul Koch) and lukew are two of the people I’ve learned the most from on that intermediary resolution layer.

    Dave Warfel, thank you for catching that typo! I’ll investigate. As for your syntax question, I don’t have any real insight. Though I believe the sample code you pasted in though would divorce the media type (media screen) from the query (min-width: 1300px) that follows it. Does that help at all?

    Toby and Sean, great question. I’m no performance guru, but divvying up your @media queries into separate link elements would just cost additional HTTP requests. But I’d defer to the experts on that one. In either event, you’d want to pair the approach to your site’s needs.

  17. A request, and a question.

    Request first:

    I loved the example you crafted for the demonstration. Did you find any other web pages out there that work on phone bandwidth and maintain aesthetics and usability across the range of viewport sizes? I’d love to see more examples.

    My question:

    In the iPad Human Interface Guidelines Apple recommends, “When possible, avoid reformatting information and rewrapping text on rotation. Strive to maintain a similar format in all orientations. Especially if people are reading text, it’s important to avoid causing them to lose their place when they rotate the device.”

    The native iPhone email application follows this recommendation. The number of words per row is maintained when changing from portrait to landscape — the words just get bigger in landscape. Is there any way to pull this trick in your approach to fluid layouts?

    Thanks!

  18. This is a great article – and no question media query’s are a step in the right direction when working on a liquid grid, but I’ll be the first to stand up and say that I don’t think fixed-width has entirely lost it’s place in the world.

    Our industry is unique in that the mediums for delivery shift so rapidly, but our methods for delivery do not. We need these evolutions to keep us on the right track, but they shouldn’t become hard rules.

    Anyway, I’m not suggesting that’s what you were getting at, just that I don’t think fixed width will ever shift from being anything but necessary in many situations. It’s a sensitive subject for me. Just like Little Debbie cakes in the morning.

    Both are appropriate in the right circumstance.

    I could be proven wrong in the future though. Just saying…

    Regardless, this is a great resource I’ll be using as a reference for my liquid grids.

  20. Apart from enjoying this topic, I was interested that the issue of scaling images hasn’t even been raised, either in the article or in the discussion so far. Often in these discussions, people state that it’s not a good idea to allow images to resize, but I don’t see why not, even though IE / Windows can make a mess of it.

    I did check the example page in IE7, though, and the imgSizer script seems to be a bit clunky at best.

    Anyway, I’m glad that the discussion seems to have moved beyond whether or not to resize images. I’m looking forward to playing with @media some more.

  21. Ethan, Only chrome is able to smoothly render the transitions while you resize the window. Webkit & Safari only play well when you quickly resize and let go of your mouse button. As iPad’s aren’t available in Spain until the day after tomorrow, so I’m not sure how well it does there, it looks good in the simulator though.

  22. Great article. I was concerned about how, in order to scale the images, you didn’t include height or width properties in the HTML. I thought those were required attributes, but apparently they are only recommended because they make it easier for the browser to render the images.

    Thanks for this introduction to flexible layouts as well as the kick in the head regarding the necessary attributes of the img element. An element which I thought I knew so well!

  23. I approached your article with scepticism (I’m and academic and not a fan of flexible layouts for the desktop) but ended up being most impressed by the way you addressed the problems poised by mobile devices and offered solutions. I can’t judge how well the solutions will work in general, and I balk at the work involved, but I can only applaud your approach.

    Have I anything useful to add to the discussion? Not really, but here’s a thought provoked by the typography of your Sherlock Holmes extract. Apart from the lack of left/right justification, it is unusual for the web in that it looks just like, well, a book. No dreadful block paragraphs. There seems to be a superstition that the computer screen demands we discard indents for block paras (a justification of lazy use of the

    imho) but my experience with the iPhone is that there is no way of justifying the waste of space of block paras there. Screen real estate is at a premium. So perhaps people (like ALA) who insist on block paras need a css transition to indented paras for mobile devices 😉

  24. Excellent article Ethan. Once again very helpful. Based on your previous writings on fluid grids and since the beginning of the year we’ve been working under the same premise, that fluid grids are one way forward which allows us to account for the different sizes in devices, viewports and changing orientations.

    A technical question…

    One interesting issue we’ve run into is the zooming behavior of Mobile Safari (initial-scale, minimum-scale, maximum-scale). This may relate to the “intermediary resolution layer” in Scott’s comments. Our current conclusion is that we have to remove the Mobile Safari user’s ability to zoom to be able to control the width of the site that is rendered in the browser/on the device. This has been a fairly significant technical/design/experience issue to deal with. Very long winded but, but do you have any comments or observations on dealing with the scaling in Mobile Safari?

  25. joshua.drake, I don’t have any great examples handy. There are compelling mobile designs—MSNBC being a recent favorite—and no lack of beautiful desktop sites, but few designs that provide a graded experience across multiple devices and viewports.

    As for your point about Apple’s HiG, you raise a great question. For what it’s worth, very few apps on my iPhone actually follow this guideline; even Mail.app loses its position when I switch to landscape mode. That said, I believe it’s valuable to responsively optimize the reading experience. But that’s something each designer would have to weigh for themselves, and choose the best way forward. That’s why they’re called _guidelines_, after all. 😉

    I’m not sure I follow your feedback, Caleb. Could you say a bit more?

    Thomas Maas, that looks damned promising. Beautiful stuff.

    Our current conclusion is that we have to remove the Mobile Safari user’s ability to zoom to be able to control the width of the site that is rendered in the browser/on the device. This has been a fairly significant technical/design/experience issue to deal with. Very long winded but, but do you have any comments or observations on dealing with the scaling in Mobile Safari?

    I’m with you, Travis — the choice between design responsiveness and user zoom is an awful one. That said, there might be a WebKit-specific solution, though I’m not personally aware of what that is: maybe once the iPhone supports the orientation media query in iPhone OS 4.0, that’ll help alleviate some of our problems. I’ll have to research that a bit further.

    Thanks again, all. Keep the feedback coming!

  26. Thanks Ethan. Both links were very informative. If only we had a good (IE-supported) way to say media=”screen… really. just screen” so we’d have the option to send stylesheets to desktop browsers without sending them to handhelds, that’d be nice for situations where cascading between screen and mobile isn’t desirable (for dramatically different UIs for instance, or even to keep filesize low on mobile). Maybe for now we you could use “screen and (max-width: 9999999px)” followed by the same style sheet included in a conditional comment? Maybe not…

    BTW, if you want to “apply some JS to match your CSS queries”:http://gist.github.com/414657, here’s a snippit. Thanks for the inspiration!

  27. Sorry about that, it was a little off topic. I was just having a debate with a co-worker about the advantages of fluid vs. fixed grids and brought the question here. In general, I disagree that fluid grids give more benefit. I think it is entirely appropriate for many projects, but I view it as an option, or even preference vs. a standard. Like you said, we think in terms of weeks, we aren’t “aiming for eternity” with our designs. So as a result I think the advantages and disadvantages of both zero out in the end. Also, I don’t think it degrades the efficacy of responsive design to opt for a fixed width.

    Anyway, you are 100% on with the topic though. As we grow into the future the responsiveness of the devices (and apparently architecture!) that surround us will play a large role in the user experience.

    This article really opened my eyes to the possibilities of responsiveness in design. Like you said, this kind of forward thinking turns the desired attributes of the print medium into a handicap, and lets us explore the possibilities of the web. Excited to implement the concepts taught here!

  28. The “need” to develop separate sites for the Blackberry, iPhone, iPad, and whatever new device turns up next week is becoming a serious waste of time and money – so the technique you suggest strikes me as an excellent solution to the balkanization of the channel.

    I’d suggest that it could be improved upon by addressing images – scaling down an image file may make it better fit a smaller screen size, but still consumes the bandwidth to download the image at its original size – and by considering which content is appropriate to display in each medium (design for mobile devices often means stripping out some content that is a nice-to-have but not strictly essential).

    My mention of these needs is not intended as a criticism of the article – what you’ve discussed is an excellent start that covers many of the greatest concerns. I hope the notion catches on and, with continued refinement, alleviates the problem of accommodating device capabilities.

  29. From the W3C’s “Mobile Best Practices” under section 3.1, they talk about a “One Web” approach:

    bq. One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices.

    I came across this a fair while ago and figured it wasn’t a terrible goal. However it did come across as idealistic and mostly not practical. Like Jim I really didn’t like the idea of creating separate pages and styles for every possible mobile device, but figured that was just the way of the world. Especially since we can’t seem to count on media="handheld" very much at all.

    And then I read your article. media queries aren’t altogether new to me, but the idea of a “Responsive Design” made possible by media queries and other techniques were. And it’s the sort of thing I’ve been hoping to come across for a while. I’ve already introduced this in my own work on a basic level to provide a mobile specific layout when visitors with smaller screens load up our contact page. Larger displays see the entire layout as normal. No new mobile specific content or pages, no Javascript required and no content to repeat and duplicate. I look forward to integrating the technique further as I get better at this.

    I really hope support for media queries only improves.

  30. Ethan, very useful article, also very well written, I love the architecture metaphor.

    The concept of a responsive design realized with media queries really got me, I instantly had to play around with it on my recent project, CouchCamp. I think this might turn out as a great way to progressively enhance even small budget projects for mobile devices. Looking forward to experiment more with it on future projects.

  31. In case anyone needed further proof that Scott Jehl is some sort of mad scientist, look no further than his JS snippet to detect/test whether your media queries are working. Thanks for sharing that, Scott!

    And Jim, you raise a very valid point. And I think you’ve nailed what I think responsive web design really means: it’s not _simply_ about ensuring that your content is able to scale/adapt to different viewports and resolutions, though that’s certainly a large part of it. Designing for a reference resolution, and then considering which elements are appropriate for another medium is another part of it—and to use your oversized image example, that may mean suppressing them altogether.

    Kristina, I love the CouchCamp site. Beautiful (and quick!) take on being more responsive.

  32. A real eye-opener and what we can expect to be doing more often. Personally, I’m not a fan of fluid everything but it’s nice to see it used so skilfully here.

    A couple of notes regarding performance: img height and width are essential for fast rendering as the browser can reserve the space before downloading the images so you will have a (possibly negligible) performance hit if you go with scalable images. But performance isn’t everything. It must serve usability.

    Secondly, YSlow and PageSpeed are fallible. If you can get all your JS and CSS into single URLs then that can be desirable for faster home page loads. But if you have dynamic elements in there you will be counteracting the browsers’ caching strategies if people move through the site. In fact, the number of requests is becoming less important as browsers and bandwidth develop. All of Opera >= 10, FireFox >= 3.5, Safari >= 4, Chrome and IE >= 8 are very fast on modern hardware.

    CSS 3 and HTML5 are giving us the tools to give the users more control. More!

  33. Great article, however most designers still have to design for compatibility across all browsers (even the crappy ones) and will have to for years to come so I don’t know how useful this will be until about 2013. I keep reading all these articles about doing things in new ways and i get excited and then I come to the realization that I cant use them because not everything supports them. By the time all the browsers do I probably will have forgotten about this article.

  34. Currently, we’re not developing in fluid because it’s too time consuming and clients here don’t want to pay for it.

    However, I was pondering about the fact today – optimization (or, responsiveness), towards displaying web content consistently in various devices. From your desktop to the mobile and even, LCD TV.

    After reading this article and stopping to think for a bit. I’d agree this method to be the best to maintain consistency.

    On the other hand, should everything in a website resize to fit the screen? Or, should we only resize the blocks and images like the example created?

  35. Instead of rallying “why”, I’ll just present this idea: add a “image size ratio” attribute to the “img”-tag and make it a standard in browsers.

    img.example { image-size-ratio: 5 3 33 none; margin: 0 10px 0 0; }
    5= height (ratio)
    3= width (ratio)
    33= percentage of containing div’s width taking horiz. margin declaration into account
    none = percentage of containing div’s height taking vert. margin declaration into account

  36. A very interesting way to look at it. I agree, let’s end the perpetual cycle of device specification, and look at the big picture.

    Nice article, Ethan.

  37. ziadh, I’m not sure I follow: if you read my article on the topic, images actually resize proportionally by default, and work wonderfully in non-fixed containers. Or perhaps I’m not understanding your proposal?

    Charlie Clark and bpaul, I dig that your two comments showed up together. You’re obviously both are thinking about constraints, but from two different angles.

    Charlie Clark, you raise some interesting questions. I don’t know how @media@ queries affect performance. But as you say: there’s got to be some negotiation there.

    bpaul, I’m not sure which part of responsive web design you’re referring to, but all of the components—fluid grids, flexible images, and media queries—are widely supported today. Of the three, the latter’s obviously the most nascent, at least on the desktop. As I mentioned, there are patches available to help close that gap, and support is only going to improve.

  38. Thanks for this excellent article. I have to give a session on this next month and this has crystallised what I ought to aim for.

    I don’t see any reason to avoid this because ie doesn’t play ball, after all it appears ie users won’t be any worse off. I’m heartily fed up with avoiding great possibilities usually because of ie.

  39. Congratulations Ethan ! I just have bought Handcrafted CSS VidEd. your chapter is really awesome and this article pushes the limits way further ! 😎

    I can’t understand something about this article design : when I open the final example in my iPhone 3GS or in Safari on my MacPro, there are 2 photos for each line in the vertical mode 320 pixels) and 3 photos in the horizontal mode (480 pixels). But when I try to narrow the window to 320 pixels in my MacPro with Firefox 3.6.3, the design don’t display 2 photos in a row. Instead, the third photo of each line is clipped out of the window. Is there a way to force Firefox to behave like Safari and Safari Mobile for this “detail” ?
    Thanks very much for all ! ;-D

  40. Great article and well argued, however, there is a substantial degradation in performance when using conditional statements in CSS. It is widely recommended to avoid them at all costs. I think every project is unique and for some, this solution is warranted. For the vast majority of projects however, performance is of major concern – especially on mobile devices. A targeted CSS file would result in lower file size, increased client performance, and more legible and maintainable code.

  41. Rod, I’ll investigate that—thanks so much.

    WHelman, thanks for the note. Media queries aren’t conditional comments, however; I was just making a comparison between the two in the article. Are you aware of performance-related issues with the former, however? If so, could you share a few references with us? Thanks!

  42. Great article, the fact that I just noticed a hit to my site from Opera for the Wii reinforces this article. I can recommend to clients the need for optimizing for the web or for mobile, but I hadn’t even thought of the Wii. And what’s next, so once again, very helpful article.

  43. At the bottom area of the code, you can find this:

    <!–[if lte IE 6]>[removed][removed]

    That particular “ddpng.js” file seems to be missing? I can’t find it anywhere.

    Great article, btw!

  46. Thanks for the question, Nick. The layout’s actually a fluid grid, so the 633 and 197 are just the “context” values taken from my PSD. Not especially useful if you haven’t seen the original artwork, I admit, but hopefully “my original article on fluid grids will clear up some of the confusion.

  48. Can/have you attempted to design a responsive layout containing an extensive, multi-column form? Building an enterprise web application that’s heavily form-based, yet optimized for a variety resolutions would be HUGE. Yet I can’t seem to find anyone who can describe how to layout a multi-column form well, let alone one that would work in what you’ve shown.

    Beyond that, this is sooo awesome!

  49. I’ve been working very carefully on trying to get an adaptive design working that, on hand-held devices, will automatically produce a simplified, space optimised display at (e.g.) here.

    I’m using

    <link type=”text/css” rel=”stylesheet” href=”/scenehere/styles/default.css” media=”screen and (min-width: 600px)”>
    <link type=”text/css” rel=”stylesheet” media=”print” href=”/scenehere/styles/print.css”>
    <link type=”text/css” rel=”stylesheet” href=”/scenehere/styles/handheld.css” media=”handheld, screen and (max-width: 599px)”>

    On desktop browsers, this works admirably: shrink the window width smaller than 600px and the pages display using my ‘handheld’ design. However, both iPhones and Android phones simply lie. They lie about their sceensize, pretending to be far wider than they are. They ignore the ‘handheld’ selector. They insist on rendering the large screen version of the page, which is completely unusable on a small screen.

    Anyone found a solution to this?

  51. Hi, simon_brooke. Two quick things:

    1. By default, Mobile WebKit will render a web page at @980px@. You’ll need to include a viewport meta element to override this behavior; personally, I recommend setting the value to width=device-width, initial-scale=1.0, and then use min-width/max-width to design for different resolution ranges.
    2. I believe Mobile WebKit simply ignores the handheld media type altogether.

    Hope that helps.

    bradybd, the final demo page works just fine for me in Safari 5.0.2. Not sure what the error could be on your end—sorry!

  52. Great article, cant wait to start using these!

    Was wondering, if you have multiple versions of images which load depending on browser width, are all three images being downloaded even though only the appropriate one is being displayed?If its loading them all, will this not be a problem for page size, especially now google is meant to be using size as a factor is its results?

  53. I’m trying to use css3-mediaqueries.js to make media-queries work in IE, but don’t know how to do it.

    Could you put an example of how to do it?

    Thanks!

  55. Nice examples, and a compelling argument for a single page. But for a well-featured application or site, it is naive to send the same content and IA to every browser.

    Firstly, the constraints of certain browsers aren’t just related to their media-queryable screen size. Input techniques, supported gestures, local APIs, network profile… A mobile browser certainly doesn’t enjoy having to download huge images simply so it can resize them itself or ‘display:none’ them. (Let alone the user whose quota you’re cheerfully using up.)

    But the most important caveat is this: *media queries tell you about glass and plastic*. Presumably one should rather be designing for the human on the other side? If the site you designed for sedentary users provides exactly the right services and content for your mobile users too, then it’s only by highly suspicious accident.

    Imagine the perfect airline web site for a desktop user (ticket booking, holiday planning, pretty animation of the new flat beds in business class). Now imagine the perfect airline web site for a mobile user (on-line checkin, flight status, geo-location, registering for SMS alerts).

    What CSS media query allows me to turn the former into the latter?

  56. Thanks a lot Ethan for this well explained article. I must agree with James Pearce though on the content side of things.

    For most of the sites we make a responsive layout will not be enough. We need responsive content. But for the more basic websites we will sure going to use your well documented article on how to handle this!

  57. These techniques hold a lot of promise for better design and more findable information (due to same URLs used for different devices/viewports). I wonder if the criticisms related to the necessity to show different content or functionality (as well as better performance) could be handled using AJAX (where AJAX is supported) in conjunction with media queries to provide a more appropriate experience?

  58. Ever since I read this article a few months ago it has stuck with me. I try to be a progressive thinker, but I thank people like you ALA’ers that help push the discussion!

    Also, good choice on the content of your example layout- I’ve been making my way through all of the old Sherlock Holmes books for a while now.

  59. I have a couple of question about this method. I work for a popular e-commerce site as a user experience designer. Recently the engineers in my company have been pushing for us as designers to start incorporating responsive web design concepts into our new projects, referring us back to your article to support their argument. The problem I run into time and time again is that many of the examples illustrated are of relatively simple layouts where elements, usually similar in nature are repeat and thus can move freely without creating confusion for the user.

    However, when we decided to go fixed width on our site it wasn’t applied to every page but to those pages where elements needed to remain in key location on the page. Elements such as Mini Carts, Buy Boxes, Checkout forms, and other highly complex elements needed to remain locked and clear to a user in order to prevent confusion. If I was to constantly float elements up around these very important key components they may cause what I refer to as “information overload” for the user.
    Boxes appearing next to the “Add to Cart” button may scare our customers away.

    My next question is consistency. At my work we know two things, that people almost never resize their browsers once the page loads and that many of our customers will browser our site from one computer but purchase from another, Often these screen resolution do not match each other. If we present one layout to the user and they go home from work and are presented with another layout on their home computer how does that affect their experience?

    Dave Snyder’s article in Practical Web Designer October Magazine seems to lack the same focus and completely ignores User Experience, as I believe most of the articles around this idea do. I’m not saying that fluid is completely wrong, in fact I agree with it when the content is repetitive and easily digestible like in your examples or on something like a search results page, but I believe that fixed is also just as valid where information needs to be consistent.

    Please I’m not trying to disrespect your article, but I’d love to see some solutions that involve more complicated interfaces such as checkouts or product pages.
    Any thoughts?

  60. Talk about a sudden influx of questions. Thanks for the responses, all.

    bnt, the JS library I mentioned in the article will interpret any media queries in your main CSS file. It seems to have a few limitations: queries on link elements are disregarded, and I don’t believe that the library can read stylesheets included via @import. Hope that helps.

    James Pearce, I disagree with your odd characterization that responsive design is somehow intrinsically “naive.” I’ve partnered with several clients for whom a responsive approach was, in fact, the best approach for their clients and audience. But as I explicitly stated in the article, a responsive approach isn’t for every project: if your research guides you to believe that the goals of your mobile users are, in fact, different, then a separate, small screen-friendly site is perfectly appropriate.

    For more on this, the second and third paragraphs of this comment by Jeffrey Zeldman neatly sum up my thoughts on the topic.

    Mich8060, you raise a number of fantastic questions. I’m not sure I can properly answer them in a simple comment form. I would say, however, that if you’re experimenting with fluid grids, you might experiment with introducing max-width constraints as best serves your audience. I’d also recommend leaning on your media queries to spotfix design issues as the viewport changes, addressing some of those overload points as needed. I hope that helps, and thanks again.

  61. bq. the choice between design responsiveness and user zoom is an awful one

    I agree with you Ethan, it’s sad we have to set the zoom to 1 for the design to look great both in portrait and landscape orientation.

    I would like to ad another example that may help or inspire some of you : Juslisen. It’s a personal website i redesigned recently. Thanks to css3 media queries it fits well on small, medium and large screens (ie: smartphones, tablets, desktop).

  62. Great article! Thanks!

    What about the markup though? A site for desktops obviously needs to include content that can’t been displayed on a mobile, e.g. showing a slimmed-down version of the site.

    I’m torn between serving a whole new site to mobile users, just so we can omit the extra markup / larger images used on the full site, as opposed to used media-queries. By scaling images, or using display: none ; the mobile is still loading a hefty site. Where do your draw the line? How can I leverage the benefits of media-queries, but also those of serving a site with 1/2 the markup and weight?

    Thanks for the thoughts!

  63. Thanks for the article. I’m still on the fence about fluid vs fixed layout, though I like the idea of tailoring the experience to the device. I think things like fluid grids and flexible images are alright for websites, but I think it would be terrible building a decent sized web app with them. I’m still undecided about the best direction for the mobile web. I can’t tell you how many times I’ve gone to a site on my iPhone and been completely lost because it looks nothing like the “desktop version” I’m used to. So many sites implement the generic “mobile version” and I can hardly stand to use them. It will certainly be interesting to see how the industry solves these problems.

  64. I loved the article, it certainly opened a world of possibilities. However, when Thomas Maas (above) writes, “everybody resizes their browser window all the time”, isn’t that a huge assumption? Do they?

    Who are we designing for? The end user or our clients? Perhaps there’s something too old school about suggesting that we should design for the end user. If our websites win awards for the client but do not sell their product or service, haven’t we failed?

    There’s also something peculiar about the apparent assumption that fluid websites that expand to the size of the user’s browser are ‘readable’. To understand this, don’t we have to go back to the roots of readability; i.e. ye olde broadsheet newspaper?

    We have long been taught that people find it difficult to read the width of a broadsheet newspaper, which is why the broadsheet (or tabloid for that matter) is broken down into bite size columns; i.e. because people read in bite size chunks! Times change, people don’t.

    Usability gurus tell us it hurts the eyes (and the brain) to have to read across a huge expanse of browser and therefore, we should design for readability. The human eye finds it more comfortable to read in bite size chunks.

    So how do we measure the success of a website? By it’s fluidity or by the increased enquiries and/or sales it brings to the client who trusted our opinions and experience? The problem I see with fads and fashions is that they are here today and gone next year, or at the very least, they have evolved into another fad or fashion which in turn, is here today and gone next year.

    I remember when Flash was lauded as, well, the best things since other flashy blinky things, but now, jQuery does the job more efficiently and effectively, and actually gets more respect from search engines for doing it!

    Are we, as website designers, in the business of creating usable – and readable – websites for the end user, or in the business of patting ourselves and our clients on the back for the bright sparkly new fangled diggery doo of a website we’ve created that uses all the current fashionable technology but doesn’t actually sell itself to the end user?

    Just a thought… or three. 🙂

  65. Great article Ethan. This is well written with perfect examples. I think you’ve done a nice job providing the web design community with creative solutions to a problem/opportunity that we’re all facing and have been facing. I was particularly happy to see your point about what can be done about increasing the size of the hot spot for links on smaller devices (great for touch devices too!). Since all the touch devices hit the market, I’ve been worried about how to resolve this. Thanks for the article.

  66. In your CSS declarations percentages are expressed thus:

    3.317535545023696682%

    There’s really no need for this level of accuracy. The browser renders to the nearest pixel, and even if you have a 10,000px wide window 3 decimals places is more than safe: 100% is 10,000px so 0.001% is 0.1px. The rest of the digits really have no effect.

  68. Great article! I would love to start working like this. 

    There are two additional challenges I see with the same design being used across all media but reflowing accordingly, as would happen with the use of Responsive Design:

    (1) Designers would also have to be developers to be able to create comps of pages that would reflow to display appropriately in different media types. Otherwise, a designer with no technical experience could create a desktop view and mobile view that are impossible or extremely difficult to implement from the same code, and get that signed off by the client.

    Unless this designer was extremely good, they’d probably have to actually build out their comp in order to ensure what they were proposing was actually doable. This just means design phase would take longer (and presumably development phase would be shorter).

    Anywhere I have worked, design and development have been two separate domains. For this to work in that kind of environment, close collaboration between designer and developer would be even more important than in the past. Developers would have to teach designers what techniques are possible that could inform their designs.

    (2) Clients would have to decide what media they need to see the design on before signing off. If they needed to see the design on several media types, they’d have to wait longer to see that. Or, they would have to trust to the designer’s and developer’s judgement when implementing a desktop sized design on different displays (in my experience, the client would never agree to this).

    With these challenges, it’s still an approach I’d love to try out, especially in an ideal world where I could design and develop (I’m a developer only where I work) and the client would trust me to create the reflowed design versions on various media types for a single approved desktop design.

  69. I was trying to use @import for my media queries, but it didn’t seem to work. I can only have it as @media inside the main style. Also it looks like using @media I’m actually overriding the main style, so I have to write !important; to enforce the new rules for the smaller screen.
    Any thoughts?
    Thank you for the article.

  70. Firstly, thanks Ethan for a fantastic article 🙂

    I’m using @import to import more advanced styles is causing my CSS to fail validation (against CSS3), with the error
    “Parse Error and (min-device-width: 130px);”

    Code being:
    <link rel=”stylesheet” type=”text/css” href=”v7style.css” />
    <style type=”text/css”>
    @import url(“v7stylebasic.css”) screen and (min-device-width: 130px);
    </style>

    It works, it just doesn’t validate. I’ve read a few conversations about there being bugs in the CSS validator. Does anyone know anything? It’s driving me mad..

    Thanks!

  71. The way you’ve gone about this, along with how you explain it is beautiful. This will work very well for small to medium-sized websites, but for sites with exceedingly large amounts of content that are not completely controlled through a small handful of dynamic scripts, implementing, controlling and maintaining this method may prove to be more t=work that separating out completely different templates for different media devices.
    I do agree that your method is intelligent, but implementing this on a large scale may prove to be more work that most companies are willing to invest.

  72. As the owner and creator of an online website builder I always look at new layouts and ways of presenting data at a much higher level than the average web designer/developer. I create the tools that so many other people use to create their websites.

    Is it really feasible in any way or form to consider such layouts for a CMS or website builder used by novice designers? I say this from experience as I know that millions of website are created using tools like ours. Custom web designers might rejoice at the thought of such layouts being to complicated for CMS or website builders, but I can assure you there will not be huge spike in demand for such designs because of $$$. Not unless custom designers are willing to create custom designs for $10 a month (which they are not).

    That said, I wonder what your thoughts are about implementing such technologies into CMS systems and website builders. Is it even a possibility? Knowing that so many of our users don’t even know the difference between their email address and their domain address, I don’t think it will ever be possible at that level. Your thoughts?

  74. Excellent article, which I am revisiting to ask when your Responsive Web Design book is going to move to the *physical* world? 😉

    Yours, patiently

    Dan

  75. Many thanks for this article Ethan.

    I recently had this discussion with a fellow web designer about “Responsive Web Design” so I did some research and found your article here.

    Plenty to think about for future projects (or indeed modifying existing client sites).

    Many thanks once again!

    Regards

    Karl

  76. Hi! I am thinking about one problem. Why is convenance screen width resolution only 950px (plus minus)?

    Because I understand, that a few years ago, it was because screen resolution (1). I know that you can’t use long rows because when you want design website with progressive enhancement you have to do a rules for better legibility and use only a some specific count of word and letter for one row (2).

    But I understand that there is a lot of people with 1024px (about 22% – and it will be a less and less) and 800px is only about 2%, I think.

    But isn’t better for design maybe use media queries like less-fw with one more parameter for .. maybe 950px – 1200px? It will solve problem with little resolution and we can help many peoples with a better resolution. You can paste every informations for one page (it have to be readable of course). It could be better for maybe aplication on web.

    I know, that a lot of peoples with a better screen resolution (like me on my mac) have open two windows in one time, but when you will use media queries its not problem. When you will design text only in some rules for better legibility you can maybe use empty space for something else like some aside.

    Of course i am talking about design with px width, no with % width.

  77. I couldn’t resist to check the CSS of an article talking about flexible web designs. Then I found the irony in base.css at line 203:

    #main {
    voice-family: inherit;
    width: 750px;
    }

  79. Thanks for a great article (and great book)!

    I have a question for you about the best design strategy for responsive design in the following case. the website in which i’m involved with is a big government site where we have control over the mark-up and css for most of the different pages and layouts (that we can make responsive) BUT some pages include web-applications developed by other consultancy firms and here we don’t have 100% control.

    What do you do in a situation like this, where maybe 95% of all pages would benefit from a responsive design and width set to device-width:
    <meta name=”viewport” content=”initial-scale=1.0, width=device-width” />

    But the remaining 5% would probably be best viewed in the shrinked default view…

    Seems like switching between them would create an inconsistent experience.

    What do you reckon is the best strategy here?

    cheers

  80. It is not “Web Responsive Design” we are discussing. In my (humble) opinion, you rather call the beast something like “web Templating Architecture With Design In It”.
    As it seems the worry here is not the way it looks, but the way it renders across devices. Technical worry vs Aesthetic worry.

  81. The biggest problem I have with responsive sites is that it does not provide a choice to the user.
    I guess most people like to see the same site presented differently to them on different devices, but I do not. I like it that I can click that “classic” link at the bottom on Google’s page on my phone.
    In fact this whole discussion about responsive design takes me back a few years when it was advocated to procide diffent stylesheets for different display types like tv-screens, pages (printing) and screenreaders. Of which only printing has taken a foothold it seems.
    As a user I want to keep at least be given control over this. If I like the whole website to just load on my phone instead of a fluid, smaller version than that should be possible.

  82. I believe that due to the simple implementation as a CSS layer this is the most promising mobile technology that I have ever seen.

    The simple implementation is the key.

  83. As has been mentioned by others, why isn’t bandwidth on the forefront of responsive web design? It defines whether I add extra animations, images, and flares, or strip away the extra, and stick primarily to CSS styling alone.

    I’m getting the impression it’s because there isn’t a good way to test bandwidth, is that right? How hard would it be to develop a good way?

    User downloads CSS file, with images, time measurement taken, ajax request sent while other info continues to download. Granted, you’d only have a clear bandwidth picture after half the page is loaded, but that’s when the javascript is loaded anyway. Not to mention a lot of media is loaded “below the fold,” in which bandwidth would determine amount/quality.

    Ok, so I don’t really know what I’m talking about, but given that everything else IS possible, and bandwidth can be measured with other analytics and methods, I don’t see why someone isn’t tackling this issue.

    So what am I missing?

  84. Hm, now I can’t go back and editing my comment to show the fool of myself. However, I still think that there are applications that do need to be talked about. The below stack overflow discussion touches on it, and mentions, and I agree, it’s applicability to video sites. What about other features? Large javascript applications? I guess I feel like rather than a blank topic that gets a sprinkling of conversation inspired by new developers, it needs to be addressed definitively.

    Ex. Here’s how it’s done, here’s why it’s rarely practical, here’s when it its practical, and this is when and how it’s best implemented. That kind of a thing.

    http://stackoverflow.com/questions/3943016/php-speed-test-for-user-connection-speed-without-echo-in-current-page

  85. this has been a perfect solution for my app websites both view-able on tablets and mobile devices! Thank you very much for you in-debt article.

  88. I think responsive web design it’s great but what about performance ?
    Usually responsive tends to hide elements instead of use only necessary things…and we know that mobile devices and connections are slower than Laptop or Pc ones.
    Which is the best approach to solve this issue ?

  89. Hi,

    I have read the article and your book Ethan, but I cannot figure it out how I can position fixed, relative or absolut a div with Responsive Web Design.

  93. This kind of technology is great for coping with the many different platforms that people access the internet from these days.

    There is an argument of course that designing a separate mobile site is better than building an all encompassing responsive site.

    Perhaps we just need to practice more but right now it feels that convincing a client to spend more to get a responsive site (i.e. it takes a lot more work to do) isn’t the right thing to do when a normal site and quick rework for a mobile site (assuming it’s CMS driven it’s quite easy) will fit the bill.

  94. I just got into RWD and everyone was pointing to this place. Nice! writing! I enjoyed reading it!

  95. “… margin-right: 3.317535545023696682%;”

    What are all those digits doing there? That last “682” is enough to pin the item down to either the left or right side of a silicon atom!

    “3.33%” would be fine, and take fewer bytes

  97. Look back fellows. Before we’ve got into html5 and css3 to standard things more-less, there was time when major players were trying to push their very own “way of life” to concur the market (my opinion). Now since everyone (aside of MS IEXXX) comes to final conclusion, hardware folks are still jiggling around with their very own “proprietery” ideas. How about to come-up with several standards for their screens? It will be much easier for W3C to came-up with a solution. And then we’ll only compete by human characteristics (which affects any visual expressions, including designing things). But no, freedom of enterprize and unbounded competition is “The Mantra”, right?
    So where is the plain logic and functionality?
    As an analogy – look at cars or airplanes.

  98. Just want to say a big thanks, Ethan, for what I think is a much better way to design web sites!
    Cheers,
    D Morris

  99. Ethan I agree that one website can now be built to accommodate all platforms if done right. We have a lot of customers ask for a separate mobile website. We tell them that in most cases it is unnecessary and a waste of money. I was surprised by this stat: “Mobile browsing is expected to outpace desktop-based access within three to five years.” but I don’t think we as designers should be intimidated by this.

  100. We would love to find people who can do this and hire someone. Where do you find these people? 🙂

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA