Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

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 Link

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 Link

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! Link

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 Link

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 Link

Markup Link

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

CSS Link

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 Link

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.

Header
content: logo, navigation, search box
type: banner
minimum width: n/a
maximum width: n/a
Main
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]
Complementary
content: directory entries, tweets, etc.
type: multi-line text box with media
minimum width: 280px
maximum width: 380px
Aside
content: Ads
type: 230px wide images
fixed width: 250px or 490px (2 ads side by side)
Contentinfo
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.

Breakpoints Link

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.

470px Link
  • header
  • Main
  • Complementary
  • Aside (250) + Contentinfo (220)
530px Link
  • header
  • Main
  • Complementary (280) + Aside (250)
  • Contentinfo
700px Link
  • header
  • Main (420) + Complementary (280)
  • Aside
  • Contentinfo

or:

  • header
  • Main (420) + Complementary (280)
  • Aside + Contentinfo
950px Link
  • Main (420) + Complementary (280) + Aside (250)
  • Contentinfo
1170px Link
  • Main (420) + Complementary (280) + Aside (250) + Contentinfo (220)
1190px Link
  • Main (420) + Complementary (280) + Aside (490)
  • Contentinfo
1410px Link
  • 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 Link

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 {
        display:block;
        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 {
        display:block;
        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;
    }
    #aside,
    #complementary {
        float: right;
        width: 280px;
    }
    #contentinfo {
        clear: both;
    }
}

/**
 * 950
 */
@media only screen and (min-width: 950px) and (max-width: 1169px) {
    #wrapper {
        display:block;
        -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) {

    #main,
    #complementary,
    #aside,
    #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 {
        display:block;
        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;
        width:100%;
        padding-left: 17%;
        padding-right: 16%;
        margin-right: -16%;
        border-right: solid 250px transparent;
    }
    #header {
        float: left;
        width:17%;
        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.

Demo Link

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]>
    <style>
    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 {
        clear:both;
    }
    </style>
<![endif]-->

Conclusion Link

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

Footnotes Link

[1] According to Ideal line length for content19 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 be20), this translates as 400 pixels and 528 pixels.

(jvb) (il) (vf)

Footnotes Link

  1. 1 http://mattkersley.com/responsive/
  2. 2 http://responsive.is/
  3. 3 http://www.responsinator.com/
  4. 4 http://www.benjaminkeen.com/misc/bricss/
  5. 5 http://www.benjaminkeen.com/misc/bricss/
  6. 6 http://punchcut.com/perspectives/the-great-tablet-flood
  7. 7 http://meyerweb.com/eric/comment/chech.html
  8. 8 http://www.metaltoad.com/blog/simple-device-diagram-responsive-design-planning
  9. 9 http://www.css-101.org/articles/responsive_design/demos/step-1.html
  10. 10 #footnote
  11. 11 #footnote
  12. 12 http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cts=1330897432181&ved=0CDEQFjAA&url=http%3A%2F%2Fdev.w3.org%2Fcsswg%2Fcss3-grid-align%2F&ei=weFTT5GwKbGPigKm3sm0Bg&usg=AFQjCNEH7KSiARjkdtGd1vgBuESld-hUYg
  13. 13 http://www.css-101.org/articles/responsive_design/demos/demo.html
  14. 14 http://www.lukew.com/ff/entry.asp?1514
  15. 15 http://www.tangledindesign.com/blog/deciding-what-responsive-breakpoints-to-use/
  16. 16 http://www.w3.org/community/respimg/2012/03/15/polyfilling-picture-without-the-overhead/
  17. 17 http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/
  18. 18 https://www.smashingmagazine.com/responsive-web-design-guidelines-tutorials/
  19. 19 http://www.maxdesign.com.au/articles/em/
  20. 20 https://www.smashingmagazine.com/2011/10/07/16-pixels-body-copy-anything-less-costly-mistake/
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook

Advertisement

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, css-101.org and ez-css.org. His twitter handle is @thierrykoblentz.

  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.

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

      0
  2. 3

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

    1
  3. 4

    Brett Jankord

    March 22, 2012 7:41 am

    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.

    0
  4. 5

    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.

    0
  5. 6

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

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

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

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

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

          0
      • 11

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

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

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

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

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

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

      0
  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!

    0
  8. 18

    Jim Silverman

    March 22, 2012 11:38 am

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

    0
  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?

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

      0
  10. 21

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

    0
  11. 22

    Sérgio Lopes

    March 22, 2012 6:15 pm

    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.

    0
  12. 23

    William Golden

    March 22, 2012 7:24 pm

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

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

    0
  14. 25

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

    0
  15. 26

    VERY Helpful article Thierry!
    Thanks for sharing )

    0
  16. 27

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

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

    0
  18. 29

    Filip Zamorsky

    March 23, 2012 5:52 am

    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 …

    0
    • 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”).

      0
  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!

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

      0
  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!

    0
    • 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? :-)

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

        0

↑ Back to top