Device-Agnostic Approach To Responsive Web Design


This is a different take on Responsive Web design. This article discusses how we can better embrace what the Web is about by ignoring the big elephant in the room; that is, how we can rely on media queries and breakpoints without any concern for devices.

The Challenge

Let’s start our journey by looking at these online tools:

Those pages let people check websites through a set of pre-built views based on various device sizes or orientations. Bricss5 goes one step further as it allows you to "customize" viewports by setting any dimensions you want.

Now check the-great-tablet-flood of 20116.

Do you get my drift? Trying to check layouts against specific sets of dimensions is a losing battle. Besides, using existing devices to set break-points is not what I’d call a "future proof" approach, as there is no for standard sizes or ratios.

I don’t want to go the "consider it to be harmful7" route, but I want to point out that tools like these, or articles promoting a device approach (i.e. Device Diagram for Responsive Design Planning8), make people focus on the wrong end of the problem, reinforcing the idea that responsive is all about devices.

To me, it seems more realistic to check our layouts through viewports of arbitrary dimensions and shapes. We don’t need anything fancy, we can simply drag the bottom right corner of our favorite desktop browser to enter: “Device Agnostic Mode”.

The Goal

The goal is to surface content, to style boxes as columns so they bring sections above the fold. The question is: when should we bring a box "up"?

Content Is King!

If we consider that content is king, then it makes sense to look at it as the corner stone of the solution. In other words, we should set break-points according to content instead of devices.

The Principle

The content of a box dictates its width. It is the minimum width of adjacent containers that create break points (a size at which we can display boxes next to each other).

Decisions are made keeping these points in mind:

  • The width of a box should be as small or as wide as possible without impairing readability.
  • The max-width of a box should take into consideration the importance of following boxes. This is because the wider the box, the wider the viewport must be to reveal subsequent boxes.
  • The goal is not to bring everything above the fold (we don’t want to fill the viewport with clutter).

In Practice


For this exercise, we will consider 5 main blocks:

<div class="grid-block" id="header"></div>
<div id="wrapper">
    <div class="grid-block" id="main"></div>
    <div class="grid-block" id="complementary"></div>
    <div class="grid-block" id="aside"></div>
<div class="grid-block" id="contentinfo"></div>

The wrapper will allow us to:

  • mix percentages and pixels to style boxes on the same row
  • set a maximum width for a group of boxes


To build our grid we will rely on display:inline-block mainly for horizontal alignment and inline flow. But note that this choice also gives us an extra edge to play with (more on this later).

Also note that we will override this styling with float to achieve some specific layouts.

body {
        margin:auto;            /* you'll see why later */
        text-align:center;      /* to center align grid boxes */
        letter-spacing: -0.31em;/* webkit: collapse white-space between units */
        *letter-spacing: normal;/* reset IE < 8 */
        word-spacing: -0.43em;  /* IE < 8 && gecko: collapse white-space between units */
    .grid-block {
        letter-spacing: normal; /* reset */
        word-spacing: normal;   /* reset */
        text-align:left;        /* reset */
        display:inline-block;   /* styling all grid-wrapper as inline blocks */
        vertical-align:top;     /* aligning those boxes at the top */
        *display:inline;        /* IE hack to mimic inline-block */
        zoom:1;                 /* part of the above hack for IE */
        width:100%;             /* boxes would shrink-wrap */

     * rules below are meant to paint the boxes

    .grid-block {
        height: 150px;
    #header {
        background: #d6cac1;
    #main {
        background: #ad9684;
    #complementary {
        background: #7a6351;
    #aside {
        background: #000000;
    #contentinfo {
        background: #3d3128;

This produces a bunch of rows9.

Content-Driven Process

We define the width of each box according to its content. These values will then be used to set breakpoints. Note that the values below take into consideration a 10px gutter between columns.

content: logo, navigation, search box
type: banner
minimum width: n/a
maximum width: n/a
content: diverse (article, blog entry, comments, etc.)
type: main box that holds the meat of the page
minimum width: 420px [11110]
maximum width: 550px [11110]
content: directory entries, tweets, etc.
type: multi-line text box with media
minimum width: 280px
maximum width: 380px
content: Ads
type: 230px wide images
fixed width: 250px or 490px (2 ads side by side)
content: resources, blog roll, etc.
type: lists of links
minimum width: 220px
maximum width: 280px

The minimum and maximum widths above only come into play when the box is displayed as a column.


The width of the containers establishes our breakpoints. Breakpoints are viewport’s widths at which we decide to display a box as a column (instead of a row).

How Do We "Pick" Breakpoints?

Until we are able to use something like grid layout12, we are pretty much stuck with the HTML flow, and thus should rearrange boxes while respecting their source order. So we go down our list, and based on the minimum width values, we create various combinations. The values below show widths at which we rearrange the layout, styling rows as columns, or changing the width of a specific column.

  • header
  • Main
  • Complementary
  • Aside (250) + Contentinfo (220)
  • header
  • Main
  • Complementary (280) + Aside (250)
  • Contentinfo
  • header
  • Main (420) + Complementary (280)
  • Aside
  • Contentinfo


  • header
  • Main (420) + Complementary (280)
  • Aside + Contentinfo
  • Main (420) + Complementary (280) + Aside (250)
  • Contentinfo
  • Main (420) + Complementary (280) + Aside (250) + Contentinfo (220)
  • Main (420) + Complementary (280) + Aside (490)
  • Contentinfo
  • Head (240) Main (420) + Complementary (280) + Aside (250) + Contentinfo (220)

All of the above are potential breakpoints — each value could be used to create different layouts for the page. But is that something we should automatically do? I think not. At least not without considering these two points:

How close are the breakpoints?
We have 2 that are 20 pixels apart (1170px and 1190px); should we set both of them or should we drop one? I think that above 900px, chances are that desktop users may easily trigger a re-flow in that range, so I would not implement both. In other words, I think it’s okay to go with close breakpoints if the values are below 800px — as there is less chance to confuse users when they resize their browser window.

Should we try to create as many columns as we can?
Bringing more ads above the fold may make more sense than bringing up a list of links that you’d generally keep buried in your footer. Also, you may choose to give more breathing room to your main content before bringing up boxes that the user does not really care for.

Getting Ready for Media Queries

For the purpose of this article, we’ll use every single one of our breakpoints to create a new layout, which should also demonstrate that it is not necessarily a good idea.

 * 470
@media only screen and (min-width: 470px) and (max-width: 529px) {
    #aside {
        width: 250px;
        float: left;
    #contentinfo {
        display: block;
        width: auto;
        overflow: hidden;

 * 530
@media only screen and (min-width: 530px) and (max-width: 699px) {
    #wrapper {
        margin: auto;
        max-width: 550px; /* see comment below */
    #complementary {
        -webkit-box-sizing: border-box;
        -moz-box-sizing: border-box;
        box-sizing: border-box;
        padding-right: 250px;
        margin-right: -250px;
    #aside {
        width: 250px;

 * 700
@media only screen and (min-width: 700px) and (max-width: 949px) {
    #wrapper {
        margin: auto;
        max-width: 830px; /* see comment below */
    #main {
        float: left;
        -webkit-box-sizing: border-box;
        -moz-box-sizing: border-box;
        box-sizing: border-box;
        padding-right: 280px;
        margin-right: -280px;
        height: 300px;
    #complementary {
        float: right;
        width: 280px;
    #contentinfo {
        clear: both;

 * 950
@media only screen and (min-width: 950px) and (max-width: 1169px) {
    #wrapper {
        -webkit-box-sizing: border-box;
        -moz-box-sizing: border-box;
        box-sizing: border-box;
        padding-right: 250px;
        margin: auto;
    #main {
        width: 60%;
    #complementary {
        width: 40%;
    #aside {
        width: 250px;
        margin-right: -250px;

 * 1170
@media only screen and (min-width: 1170px) and (max-width: 1189px) {

    #contentinfo {
        float: left; /* display:inline here leads to rounding errors */
    #main {
        width: 36%;
    #complementary {
        width: 24%;
    #aside {
        width: 21%;
    #contentinfo {
        width: 19%;

 * 1190
@media only screen and (min-width: 1190px) and (max-width: 1409px) {
    #wrapper {
        box-sizing: border-box;
        padding-right: 490px;
        margin: auto;
    #main {
        width: 60%;
    #complementary {
        width: 40%;
    #aside {
        width: 490px;
        margin-right: -490px;

 * 1410
@media only screen and (min-width: 1410px) {
    body {
        max-width: 1740px;
    #wrapper {
        float: left;
        -webkit-box-sizing: border-box;
        -moz-box-sizing: border-box;
        box-sizing: border-box;
        padding-left: 17%;
        padding-right: 16%;
        margin-right: -16%;
        border-right: solid 250px transparent;
    #header {
        float: left;
        margin-right: -17%;
    #main {
        width: 60%;
    #complementary {
        width: 40%;
    #aside {
        width: 250px;
        margin-right: -250px;
    #contentinfo {
        width: 16%;

For the 530px and 700px breakpoints, there is a design choice to make. Without a max-width, we’d get everything flush, but the main box (#main) would be larger than the maximum width we originally set.


Please feel free to check out the demo13 of this technique.

The last thing to do is to create a layout to cater for IE6/7/8, as these browsers will ignore the media queries. To do so, we can use a Conditional Comment:

<!--[if lt IE 9]>
    body {
        margin: auto;
        min-width: 850px;
        max-width: 1000px;
        _width: 900px;
    #main {
        width: 55%;
    #complementary {
        width: 25%;
        *margin-right: -1px; /* rounding error */
    #aside {
        width: 20%;
    #contentinfo {


Not once in this article I referenced the width of a device, be it an iPad, a Xoom, or something else. Building a "content-aware grid" is a simple matter of choosing the "layout patterns14" that you want, based on breakpoints that you set according to page content.

After I sent this piece to Smashing Magazine, I ran into Deciding What Responsive Breakpoints To Use15 by @Stephen_Greig16. So obviously, we are at least two who share the sentiment that relying on devices to create layouts is the wrong approach. But I’m curious to know what everyone else is doing, or even thinking? If we had more people pushing for this, the community could be less device-centric, and could start focusing on content again.

Next Step: Responsive Media


[1] According to Ideal line length for content20 this box should be styled width a min-width of 25em and a max-width of 33em. So if your base font-size is 16px (as it should be21), this translates as 400 pixels and 528 pixels.

(jvb) (il) (vf)


  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10 #footnote
  11. 11 #footnote
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16!/Stephen_Greig
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21

↑ Back to topShare on Twitter

Thierry is passionate about Web Design and CSS. He loves the challenge of solving problems and dreaming up original ideas that get him out of bed in the morning and keep him working late at night. He is a front-end engineer at Yahoo! and owns TJK Design, and His twitter handle is @thierrykoblentz.


Note: Our rating-system has caused errors, so it's disabled at the moment. It will be back the moment the problem has been resolved. We're very sorry. Happy Holidays!

  1. 1

    I take a similar approach which uses percentages and is also device agnostic.

    The site is designed at our max width, and coded at full width. Once we have the site coded at max width we start scaling the browser down till it breaks or just looks bad. We then note the size and add a media query to re-position, hide or whatever else we need to do at that width. Then once we have fixed everything there we start the process over again.

    The process take a little longer but the end result is fantastic and should scale for all devices regardless of size.

    • 2

      Agustín Amenabar

      March 22, 2012 11:44 am

      Matt, I’m with you, it’s the easiest fastest way to code, device breakpoints keep breaking content. I would like to add that in the long run, the process is way faster if you start doing the breakpoints from the begining, beause once you are ready that’s it, no turning back to do the media queries which end filled with time consuming hacks.

      Great article, the first time I heard about the content driven breakpoints, I think it was from Ethan Marcotte, in the Web Ahead podcast, but he just mentioned it. This digs a lot deeper.

  2. 3

    I completely agree with this approach. This is how I decide where to set my breakpoints. Re-size the browser, and see where the layout breaks. I’m pretty sure this is the method Ethan describes in his book, it’s been a while since I’ve read through it though. I’m always surprised to see device specific media queries, for example, media queries specifically for iPads, etc…

    If you need to target specific devices, a server side solution will be more accurate than media queries. Lest we forget, we can pair the two also.

  3. 4

    Thank you. I have grown rather tired of all the talk around responsive design that focuses on sets of existing device sizes. So much so that I just ranted about it on my own

    Breakpoints just aren’t something that can be pre-defined. They change with your design so don’t go into a project knowing what your breakpoints are going to be.

  4. 5

    Yes! someone with comon sence!
    Totally agree and nicely written, that’s all i have to say

  5. 6

    Could you explain why you pick each breakpoint? Which is for which device, etc? Thanks!

    • 7

      Thierry Koblentz

      March 22, 2012 4:43 pm

      These breakpoints are not set according to devices. The whole idea behind this article is to calculate breakpoints using the minimum width of adjacent boxes. The addition of these widths are our breakpoints.

      Check the section that says “HOW DO WE “PICK” BREAKPOINTS?” You’ll see where these values come from.

      • 8

        I understand your approach of making your layout look nice in every size, and making sure the content is presented properly, but responsive-design is still also about devices, no? I mean, someone using a mobile phone will have other uses for the website than someone using a desktop pc or laptop.

        • 9

          I think the device can cause someone to lean more towards some features than others, but ultimately I think people want everything a site has to offer, regardless of what they’re using.

          That said, you still have to make some decisions regarding the emphasis that everything on your site receives under varying conditions, but I believe that’s true whichever approach you take.

        • 10

          Thierry Koblentz

          March 23, 2012 8:10 am

          ok, I see your point now and I agree with you. I don’t think content needs to be the same across the board.
          But this article is only about layout. How content should be delivered is a totally different story.

      • 11

        Do you have links to websites who put this technique into practise?

        • 12

          Thierry Koblentz

          March 23, 2012 8:13 am

          Check the comments where people say they are already using this approach. They can’t post links, but you should be able to find their sites.

  6. 13

    I like the idea of this approach but even this is somewhat flawed, not only are the more device sizes to more or less worry about. We have pixel densities to figure a way around. Take for example the new Ipad, it’s resoution is higher but the size is still the same as before. Take 1024px and 2048px way different but same physical size would render to different sites and possibly tiny text. In this case i think using ems is a better approach as the device/browser sets this and is more future proof than mere pixels. Though this is a realm that we are just now exploring so there is a lot to learn. Though the approach above is a great way of thinking differently in designing for the web today.

    • 14

      Thierry Koblentz

      March 23, 2012 8:18 am

      I’m not sure of what you’re saying here. You mention pixels, but the CSS rules for these layouts are set in percentages. So I don’t think the issue you mention comes into play.

      • 15

        I’m not sure I follow. I think it’s not just about size.

        The ability to use a device while walking means we need a button that is physically large enough to tap while in motion, and maybe that always stays near the bottom of the device’s display. Neither pixels nor percentage tell me the physical size or location of the button, right?

        A touch device has different scrolling than a mouse device in it’s ability to scroll within a page or frame or div, so sometimes I’ll want to force a scrollbar be visible and sometimes not. For instance, an iPad scrolls the page with one finger, the frame with 2 fingers — but so few people know that 2 finger trick that a site better not depend on it and draw a scroll bar just in case. Small devices cannot be assumed to have touch — some have a stylus — so what I think we really want to test is device abilities, not size. (think jQuery feature tests)

        Some devices display dim colors weakly, so you might want to know if a brightness-detecting device is in use and adjust colors and/or boundaries to compensate.

    • 16

      This is incorrect. The iPad renders the page at 1024×768 points. A point normally would equal a pixel, but in the retina displays case, it equals 4 pixels. Basically the browser is smart enough to render it at the size of 1024×768, but at the quality of 2048×1536. So, the breakpoints on the new iPad are the exact same as the previous ones…which is 1024 and 768. The same goes for the iPhone and nearly every other high pixel density device.

  7. 17

    Outstanding article! I’ll read it again and again at least a dozen times today later. This one is definitely a smashing article! A must read for all those trying to build their own responsive layouts. Me included. Now I can see (how and why) that breakpoints must obey a content criteria. I agree with the common sense of you guys about device widths are not real breakpoints for layouts. Its hard to figure this out unless you dive into a real project and its issues. Even more when we do it under “mobile first” concept. Well at least for me. Thank you SM for share this approach!

  8. 18

    agreed. setting device-specific breakpoints serves to only perpetuate the problem that responsive design was meant to solve.

  9. 19

    Steven D. Sanders

    March 22, 2012 3:03 pm

    Why not use something like respond.js to add media query support for IE6-8 rather than using a conditional style?

    • 20

      Thierry Koblentz

      March 22, 2012 4:40 pm

      In my opinion, it’d better to use both. Adding some logic to make sure the layout in the conditional comment applies if there is no script support.

  10. 21

    Lovely and very useful article, I’ll guess I have to double-check for breakpoints!

  11. 22

    Nice article! I totally agree with you. Full responsive sites shouldn’t target specific devices. They should work at all sizes!

    I have this opensource project called “Responsive Play” that enables you to visualize your true responsive design working in all resolutions. There’s a tool to generate a nice video of your page opening in hundreds of different resolutions.

  12. 23

    I was hoping to see my Responsive design bookmarklet that you guys tweeted about on the list of available tools too :)

  13. 24

    This is a great article, it talks so much sense.

    Anyone who has worked with fluid layouts (forget devices, for a moment) will know that desktop displays will require breakpoints anyway. My research around the large organisation I work for shows that most people with large monitors don’t maximize their browser windows – tending rather to have various windows open side by side. Therefore when working on our corporate applications we can’t take the default desktop size as a given. Education developers to organise their applications/content to work in a fluid context is an uphill struggle, but we’re getting there.

    I think there is still a case for having breakpoints that also match the “most common” device viewports – particularly the smaller ones – where an increase in font -size may be required for buttons or readability of copy.

  14. 25

    Why are you using “only screen” in your media queries?

  15. 26

    VERY Helpful article Thierry!
    Thanks for sharing )

  16. 27

    Awesome useful tutorial.Nicely implemented break point.Thank you for sharing.

  17. 28

    Crazy this article came out this morning. We just launched a website yesterday for a Ski/Snowboard movie company that uses this kind of approach to responsive design. Would love any feedback or comments. Clearly not allowed links on here, so if you’re interested, Just google Toy Soldier Productions.

  18. 29

    This is a nice article with great links – thank you.

    But unfortunately your demo doesn’t work within iPhone simulator (Xcode) properly.

    Check out my website – I am still working on it and I am almost there …
    You can google shotworldwide …

    • 30

      Thierry Koblentz

      March 23, 2012 8:25 am

      Things work just fine on my iPhone. Note that if you switch from portrait to landscape, you may need to pintch to bring everything inside the viewport. But this is a design decision as I do not like to prevent the user from zooming (user-scalable=no”).

  19. 31

    While I agree with the approach, it seems to me that the element widths that were selected are fairly common widths for varying devices anyways. It almost seems as if the selection of element widths is somewhat “tainted” by already existing knowledge of the breakpoints of device-centric responsive design.

    I also question whether including the reset styles in your examples was relevant or not.

    All this said, great article and I really hope it makes a difference!

    • 32

      Thierry Koblentz

      March 23, 2012 8:29 am

      I can assure you that these widths were not chosen to match the dimensions of common devices. Actually, the footnote says that the widths of the main content was chosen according to what’s consider best practice when it comes to line width.

      And if you look at the demo, you’ll see that in three cases I had to set a maximum width to prevent the width of the boxes from being greater than the chosen dimensions.

  20. 33

    Really weird that people would try to test different devices. Isn’t the whole point of responsive design to NOT ask the question “What device (speak: display) are you using?” but to ask the much better question “How wide is your display?”. We basically asked the first question long enough (“What browser and display resolution are you using?”).

    One comment on your CSS: I think it’s better to start with a “mobile first approach”: The “global” (no query) CSS settings would be responsible for the smallest resolution and everything adds onto it via
    @media screen and (min-width: 470px) {…}
    @media screen and (min-width: 520px) {…}
    @media screen and (min-width: 700px) {…}

    For example, right now, you have to redefine “display:block” for #wrapper every time. If you use the mobile first approach you only have to do it once – in the min-width media block where it should occur first if you go from narrow to wide. Makes for smaller and easier maintainable stylesheets!

    • 34

      Thierry Koblentz

      March 23, 2012 8:41 am

      This is not the case, believe me :)

      If you start building on top of these, you’ll find out that it is much easier to sandbox any rules related to construct. This is because what you see as an “advantage” becomes very difficult to manage if you ever decide to set new breakpoints or change anything in one of the MQs.

      Now, if you want to discuss the styling of #wrapper in there (display:block;), you could better say that it is not needed at all as this is the default styling for this block element. How did I miss that? :-)

      • 35

        I guess you are right with display:block :-) I also see your point. I think that it depends on the specific layout and responsive grid. One or the other might be better to build depending on what one is trying to achieve. With my suggestion, inserting a new breakpoint might then be just a matter of moving some CSS definitions to the new breakpoint and adjusting its properties. Other layouts might make this a more cumbersome task.

  21. 36

    I’m the author of “Device Widths for Responsive Design Planning” you refer to in the post.

    Overall, I agree with you and I like the focus on content rather than widths. I also like your methodology for selecting breakpoints.

    However, to clarify the primary intent of my post, it was simply that until Photoshop invents responsive PSDs, design comps have to target something, whether with a device in mind or just a device-agnostic width. A good designer will create a design that is fluid and informs layouts in a width range rather than at a specific width, but since a PSD is a set width, it often makes sense to design the PSD at a common device width such as an iPhone/iPad.

    Thanks for the post!

  22. 37

    Great article Thierry and huge thanks for linking to my article in the conclusion :-) But the link is incorrect! It has an extra quotation mark at the end of the link – do you think you could sort this out please :-)

    • 38

      Thierry Koblentz

      March 23, 2012 9:20 am

      You’re welcome and sorry for the broken link. That should be fixed now! :)

  23. 39

    Great article – but are we not forgetting using this technique that the various devices used to browse have very different screen resolutions, and so the 800px that will be about 15-20cm wide on my monitor will be something like 8cm wide on an average smartphone ?
    I’m always amazed at the resolution of my smartphone’s screen (and it’s not even retina !) ; I could browse the desktop-versions of most websites with it, but I won’t do it because everything looks so small it’s impossible to read !

    TL;DR: 1000px in your browser doesn’t look the same as 1000px on your phone.

  24. 40

    I took this exact approach when designing my latest blog, All my breakpoints were based on what looked good when resizing my desktop browser. As a result I’ve got some pretty non-standard breakpoints, but the end result means that it looks good in ANY browser, mobile or otherwise.

  25. 41

    Well said about the breakpoints.

  26. 42

    Great read and vision on how to (not) use breakpoints.
    However sometimes I need to take a different approach when it comes to positioning.
    I place the main content at the top of my html and the header at the bottom. All because of SEO optimalisation.
    I then have to adjust the positioning of the main content to move it below the header by using fixed -px margins.

    Is it possible to combine this with responsive web design when using multiple content blocks?
    Especially in the case of 3 columns when absolute positioning has to be used to position the left and right column.

    • 43

      Thierry Koblentz

      March 28, 2012 8:44 pm

      I’m not really for putting SEO before user experience. If you cheat with the source order, then users who navigate via keyboard can get confused. Also, relying on position:absolute is bad practice as it removes elements from the flow and make the layout “weak” (designs break when users increase the font-size or when the content is dynamic).

      But note that you can create a three column layout and cheat with the order in which the columns appear *without using position:absolute*.

  27. 44

    Sebastien Gignoux

    March 28, 2012 5:32 am

    Hi Thierry,

    Thanks for this very useful article. I am trying to find how widespread responsive design is for web designer, do you know of any survey or polls?

    Since I haven’t found anything I am trying to do my own poll. You can access it here: and the results are here:

    If you could spread the word with a twit or something, that would be great. I think the results will interest everybody in the web design community.

    Thanks in advance for any help

  28. 46

    I am triying to find the comment I wrote two days ago and can´t find it.. I don´t know why it was erased.

    In it, I steted that the most devide-agnostic approach I have found is the goldie lock´s approach to responsive design created by Front.


  29. 47

    Hiya Thierry,

    Excellent principles at work, although I’m not sure why arbitrary measurements set in pixels are used in the layout at all (border-widths are an arguable exception). When we consider the iPad3 and other devices that make the present world one where pixel-to-physical-measurement ratio is a complete liability, I think it’s far safer to deal exclusively in ems for significant layout dimensions. This is a given in the Goldilocks Approach (.com), which presupposes that the native em gives an indication of readable text-size, and thus can be used to set meaningful widths where the width of our content blocks is defined in terms of content (would you want to read prose set in less than 10ems per line length?) as opposed to a pre-determined fraction of our viewport.

    I think if content really determines layout decisions, when viewport width and pixel-size are unknown quantities, we have to rely on the EM as the last bastion of a meaningful measurement.

    • 48

      Thierry Koblentz

      March 29, 2012 7:29 am

      Hi Barney,

      The initial width values are set using percentage, based on EM (see the footnote). The 250px width for the ad container is tied to the fixed width of the ads (images). What I think should be specified in EMs are min/max-width values.

    • 49

      Thierry Koblentz

      March 29, 2012 8:00 am

      Unless you’re talking about the breakpoints themselves :-)
      Also, there is something else we could play with when designing responsive sites, it’s the new unit: vw (which may reduce the need of wrappers).

  30. 50

    While I agree with the notion that we need to figure out solutions that transcend the 4 most common device widths defined on Mediaqueries, I wonder if your idea would really work on content heavy site with well thought out communication hierarchy. I’m struggling with imagining clients signing off on a layout of their site that positions all the content regions side by side. Content and messaging hierarchy are challenging to nail down in one state, let alone a version where all of the content is stacked side by side. Additionally, I feel like complexities exist within those regions from page to page which may make this solution challenging.

    However, I appreciate your thoughts and ideas, because it touches on the core of where we’re heading for sure.

  31. 51

    Excellent article!

  32. 52

    Why are you going above 980px? it should be 980 down to 320. most people centre their content in the middle of the page. so if you go bigger it will always be centred. – least this is what I have experienced.

    Also How are you dealing with forms? such as comment forms or email submissions? I find that as the screen get smaller lots of hacks have to be implemented that are very – touch and shatter – because inputs, labels, text areas and input[type=”submit”] like to go all over the place when the screen shrinks >_<

    Any articles, tips, suggestions to dealing with forms and what not in responsive design?

    • 53

      Thierry Koblentz

      March 31, 2012 10:04 am

      > It should be 980px down to 320

      Where do these pixels come from? While I am typing this, my browser window is close to 2000 pixels wide :)

      Regarding forms, I like to display labels above form fields (vs. side-by-side). Not only because it facilitates styling in narrow containers, but also because it’s a bit more accessible (i.e. for screen magnifier users).

      • 54

        The reason he mentioned 980px is that realistically fitting your content into 2000px and down to 320px and making it really look good is a stretch. The majority of responsive design tops out at 1024 screen resolution support. This might change as computer monitors continue to go up to around 1600, but at the present time the majority of internet users still don’t have screens that go up to 2000px.

  33. 55

    I still don’t understand why there is no mention of using rem’s for creating responsive websites in articles that write about it. And i don’t mean just for text, build everything with rem, set the font size on html to 10px, then let’s say on body it is : font-size: 24px; font-size:2.4rem.

    This way 1rem=10px, 2rem=20px, 35px=3.5rem, and so on.
    Then just use media queries to change font size on html at various breakoints, and voila you have a nice responsive website, which is also device independant, as it depends on width and height of the viewport.

    • 56

      Thierry Koblentz

      April 7, 2012 12:55 pm

      Hi Mirko,

      I’d say because REM is not well supported yet.
      But as a side note, if you read the comments, you’ll see that EMs were suggested already.

  34. 57

    Since the time has finally come in my company, I’ve recently been developing a new responsive layout for our primary website. I’ve referenced this and other similar articles in using a device agnostic approach. Really appreciate the thought you’ve put into this Thierry!

    However, I have to play devil’s advocate for a moment. As I work on this, I find myself wondering: what’s the difference? That is, if I end up using a breakpoint at 768px or 700px… 480 or 470… since it’s all arbitrary, why not just use the most common current “standard” viewport sizes anyway? It will still accommodate every size in-between, and will remain future proof (only if you do it right – but that’s true for both approaches).

    I get the “where it looks good” concept, but as designers, it’s not like it’s difficult for us to work with the standard widths to achieve the same goal as the agnostic method – and let’s face it the difference is only a few pixels either way. I’m not saying one is better than the other, in fact that’s my point – when you get down to it I see no difference. Both methods are responsive, and both methods will adapt to viewport size accordingly. I now see it as simply a matter of preference.

    • 58

      > “why not just use the most common current “standard” viewport sizes anyway?”

      Because there is no such things as “standard”. By definition “current” is a moving target ;-)

  35. 59

    Ravi Suryawanshi

    May 16, 2012 3:35 am

    Best article !

  36. 60

    Great article indeed.

    The real question for me and associates in the development community is is “responsive web design the best multi-screen solution?”

    Microsoft and Google seem to think responsive webdesign is all that with their recent adoption of the technique. Some think separate mobile sites and/ or is adaptive web design technique the best future answer.

    We set-up a blog to talk about the latest on responsive web design and what’s trending in this direction here:

  37. 61

    Good article. One thing I never understood was, why does the headline cover half of my mobile device screen when I visit on my mobile phone?

  38. 62

    Love the post! Here’s a question…

    How do you feel about using a responsive framework like Foundation or Bootstrap where there are usually around 4 sets of predetermined MQs? (i.e. xlarge, large, large-up, medium-down, medium, small). These are built in for visibility classes like “hide-on-xlarge” or “hide-for-small” and other things.

    The frameworks help get our entire dev / design team on the same page between different CMS’s drupal, joomla and wordpress. Any direction you have would be awesome.

  39. 63

    Thanks Thierry!

    I’m applying this technique in a new website where the minimum width based on content is 500px.

    The problem is when I view the site on a 320 wide mobile screen, the mobile doesn’t automatically zoom-out to accommodate the mininum 500px, and I get a view of 320px. Only zooming out fixes the mobile browser on the 500px.

    What am I missing?

  40. 64

    Can anyone please suggest me a workaround for this?

    I don’t want to show the website ( in landscape orientation for devices, instead I would like to show the user
    a message saying ‘view in portrait mode for best user experience’.

    Can anyone give me a solution or any reference to a site which already has a workaround for this please?

  41. 65

    Awesome post Thierry!

    Here’s an online Responsive Test tool I built for the latest and greatest devices (iphone 5, etc):

    Let’s make the Mobile Web a better place!

  42. 66

    What an Awesome post this is.
    Cheers to you Thierry!

  43. 67

    I admit I have only read the first few paragraphs of this article but that already confirmed what I knew anyway and what I thought of many people that call themselves “web developers”:

    This whole article is basically a different view on progressive enhancement (“content is king” etc.), and if everybody was applying progressive enhancement properly in the first place this article could very well have been spared because you are basically discussing a problem that wouldn’t exist if people were not so stupid to only look at the obvious (e. g. their iPhone).

    I don’t know, to me it seems totally logical and without question to design a website that doesn’t rely on specific devices or browsers. But apparently not everybody is as considerate as me.

  44. 68

    thank you for the article. it was easy to follow along and I appreciate the examples you give.

↑ Back to top