Comments on Responsive Web Design

100 Reader Comments

Back to the Article
  1. All this is inferring that the mobile browser supports media queries. Otherwise, we’re sunk.

    Copy & paste the code below to embed this comment.
  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.


    Copy & paste the code below to embed this comment.
  3. It’s possible that I’m mistaken, but I’m fairly certain it’s quite unnecessary to specify percentage widths to 18 decimal places.

    Copy & paste the code below to embed this comment.
  4. 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…

    Copy & paste the code below to embed this comment.
  5. 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.


    Copy & paste the code below to embed this comment.
  6. 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.

    Copy & paste the code below to embed this comment.
  7. 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?

    Copy & paste the code below to embed this comment.
  8. 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?

    Copy & paste the code below to embed this comment.
  9. 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?

    Copy & paste the code below to embed this comment.
  10. 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??

    Copy & paste the code below to embed this comment.
  11. 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!

    Copy & paste the code below to embed this comment.
  12. I was pointed to this article that addresses my earlier question about resolution and device-width. Sounds promising. :)

    Copy & paste the code below to embed this comment.
  13. 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.

    Copy & paste the code below to embed this comment.
  14. @ngscheurich

    I’ll give it a try also.

    Copy & paste the code below to embed this comment.
  15. 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?


    Copy & paste the code below to embed this comment.
  16. 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.

    Copy & paste the code below to embed this comment.
  17. I wrote a userstyle that crudely implements this along with CSS3 multicolumn layout on article pages so that they are more readable across the page on wide screens;

    Perhaps this will help designers stuck in the print/fixed-width mindset to see how a flexible medium like the web can be used to the designer’s advantage, and not as a hindrance.

    Copy & paste the code below to embed this comment.
  18. 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.

    Copy & paste the code below to embed this comment.
  19. 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.

    Copy & paste the code below to embed this comment.
  20. 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!

    Copy & paste the code below to embed this comment.
  21. 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 ;-)

    Copy & paste the code below to embed this comment.
  22. 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?

    Copy & paste the code below to embed this comment.
  23. 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”:, here’s a snippit. Thanks for the inspiration!

    Copy & paste the code below to embed this comment.
  24. 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!

    Copy & paste the code below to embed this comment.
  25. 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.

    Copy & paste the code below to embed this comment.
  26. 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.

    Copy & paste the code below to embed this comment.
  27. 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.

    Copy & paste the code below to embed this comment.
  28. 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!

    Copy & paste the code below to embed this comment.
  29. 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.

    Copy & paste the code below to embed this comment.
  30. 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?

    Copy & paste the code below to embed this comment.
  31. 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

    Copy & paste the code below to embed this comment.
  32. 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.

    Copy & paste the code below to embed this comment.
  33. 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.

    Copy & paste the code below to embed this comment.
  34. Congratulations Ethan ! I just have bought Handcrafted CSS VidEd. your chapter is really awesome and this article pushes the limits way further !  8-)

    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

    Copy & paste the code below to embed this comment.
  35. 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.

    Copy & paste the code below to embed this comment.
  36. 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.

    Copy & paste the code below to embed this comment.
  37. 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!

    Copy & paste the code below to embed this comment.
  38. I’m a little bit confused about the maths in this article.  Where do we get the figure 633 from?  or 197 for the figures?

    Copy & paste the code below to embed this comment.
  39. Thanks Ethan, I shall read that article and hopefully understand things a litte more.

    Copy & paste the code below to embed this comment.
  40. 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!

    Copy & paste the code below to embed this comment.
  41. 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?

    Copy & paste the code below to embed this comment.
  42. Is it just me, or is the cool ‘responsive’ design demo a lot less responsive now? (using Safari 5.0.2)

    Copy & paste the code below to embed this comment.
  43. 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?

    Copy & paste the code below to embed this comment.
  44. 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?


    Copy & paste the code below to embed this comment.
  45. Don’t really code much for different screen sizes so this has been a big help.
    Thanks Ethan

    Copy & paste the code below to embed this comment.
  46. 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?

    Copy & paste the code below to embed this comment.
  47. 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!

    Copy & paste the code below to embed this comment.
  48. 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?

    Copy & paste the code below to embed this comment.
  49. 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.

    Copy & paste the code below to embed this comment.
  50. 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?

    Copy & paste the code below to embed this comment.
  51. 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).

    Copy & paste the code below to embed this comment.
  52. 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!

    Copy & paste the code below to embed this comment.
  53. 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.

    Copy & paste the code below to embed this comment.
  54. 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. :-)

    Copy & paste the code below to embed this comment.
  55. 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.

    Copy & paste the code below to embed this comment.
  56. In your CSS declarations percentages are expressed thus:


    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.

    Copy & paste the code below to embed this comment.
  57. Firstly, thanks for this post - it’s really helpful and insightful.

    Unfortunately, I’ve run into a small bug. In Firefox 3.6.13 (latest update as of 1-13-2011), the media query isn’t working below 400px min-width when called. I reviewed this in the site referenced in this article ( It still works in Chrome…

    Any help on this would be appreciated…

    Copy & paste the code below to embed this comment.
  58. 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.

    Copy & paste the code below to embed this comment.
  59. 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.

    Copy & paste the code below to embed this comment.
  60. 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);

    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..


    Copy & paste the code below to embed this comment.
  61. 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.

    Copy & paste the code below to embed this comment.
  62. 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?

    Copy & paste the code below to embed this comment.
  63. Your article was very insightful and mind-opening.

    Thank you.

    Copy & paste the code below to embed this comment.
  64. Excellent article, which I am revisiting to ask when your Responsive Web Design book is going to move to the *physical* world? ;-)

    Yours, patiently


    Copy & paste the code below to embed this comment.
  65. 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!



    Copy & paste the code below to embed this comment.
  66. 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.

    Copy & paste the code below to embed this comment.
  67. 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;

    Copy & paste the code below to embed this comment.
  68. thank you 4 the good article!
    one minus - IE (6,7) not correctly handle this… :(

    Copy & paste the code below to embed this comment.
  69. 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?


    Copy & paste the code below to embed this comment.
  70. 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.

    Copy & paste the code below to embed this comment.
  71. 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.

    Copy & paste the code below to embed this comment.
  72. 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.

    Copy & paste the code below to embed this comment.
  73. 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?

    Copy & paste the code below to embed this comment.
  74. 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.

    Copy & paste the code below to embed this comment.
  75. 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.

    Copy & paste the code below to embed this comment.
  76. You can find my thoughts about applying responsive web design on forms in an article I wrote:

    Copy & paste the code below to embed this comment.
  77. Navigation and ease of use are very important in designing a website. Thanks for effort you have put forth on the subject! - David = A Work Of Art, Inc. Fort Lauderdale, FL

    Copy & paste the code below to embed this comment.
  78. 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 ?

    Copy & paste the code below to embed this comment.
  79. 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.

    Copy & paste the code below to embed this comment.
  80. I’ve have been using this blog for excellent infomation for a time now and find that it’s a helpful resource for people trying to find the suitable information. Keep up the good work.

    “Web Design Company”:

    Copy & paste the code below to embed this comment.
  81. Great post. I was checking continuously this blog and I’m impressed! Extremely useful info specially the last part :) I care for such information a lot. I was looking for this particular information for a very long time. Thank you and good luck.

    “Technology News”:

    Copy & paste the code below to embed this comment.
  82. If you wanted to be a responsible web designer, you should be more dedicated to yourself as a web designer.

    Copy & paste the code below to embed this comment.
  83. 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.

    Copy & paste the code below to embed this comment.
  84. I just got into RWD and everyone was pointing to this place. Nice! writing! I enjoyed reading it!

    Copy & paste the code below to embed this comment.
  85. “... 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

    Copy & paste the code below to embed this comment.
  86. Excellent post! Thanks for sharing. I wrote a post introducing Responsive design to someone new to the topic: Responsive Design — an introduction:

    Copy & paste the code below to embed this comment.
  87. 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.

    Copy & paste the code below to embed this comment.
  88. Just want to say a big thanks, Ethan, for what I think is a much better way to design web sites!
    D Morris

    Copy & paste the code below to embed this comment.
  89. 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.

    Copy & paste the code below to embed this comment.
  90. We would love to find people who can do this and hire someone.  Where do you find these people? :)

    Copy & paste the code below to embed this comment.
  91. Sorry, commenting is closed on this article.