BlogmyQuery – BMQ

Grid systems are a key component of graphic design, but they’ve always been designed for canvases with fixed dimensions. Until now. Today we’re designing for a medium that has no fixed dimensions, a medium that can and will shape-shift to better suit its environment—a medium capable of displaying a single layout on a smartphone, a billboard in Times Square, and everything in between.

We’re designing for an infinite canvas—and for that, we need an infinite grid system.

It’s common to think of responsive design as multiple layouts: mobile, tablet, desktop, etc. The problem is the “in-between� sizes tend to suffer, so we end up with layouts that look great at specific dimensions (320, 720, 960), but less than great for everything else. So while a site may look perfect on your 640x960 iPhone 4, it’s going to be a bit off on a visitor’s Nokia Lumia (480x800), or the 685x308 browser window you have open on your desktop. It might even look a little off on that shiny new iPhone 5 (640x1136) your cousin just bought, not to mention the countless other older or less-popular devices out there.

As the spectrum of device resolutions gets wider and smoother, focusing all our attention on “key dimensions� for each page is going to result in a subpar experience for more and more users. Instead, we need to create a grid system that embraces the medium’s lack of fixed dimensions, resulting in a single layout with multiple states that transition seamlessly from one to another, and bring structure to our content whatever the screen size.

What is an infinite grid system?

Grids are simply a tool for visual problem solving. Creating a layout is like doing a jigsaw puzzle; you have a bunch of pieces and you have to figure out how they should fit together. When we construct a grid, we’re creating layout boundaries: known relationships and constraints that define an environment wherein an appropriate solution can occur. But when we construct an infinite grid, we’re not just setting the boundaries for a layout, but a layout system, with too many variables for us to nail everything down. If we define the important relationships, the blanks will fill in themselves.

For a grid to be useful, it has to be based on the things we know. In traditional media, canvas dimensions are a known constraint, so it makes sense that we start with the edges and define a grid’s relationships relative to them. With digital, however, the canvas is an unknown, making it a poor foundation to base a layout on.

Instead, we need to build on what we do know: content.

In order to embrace designing native layouts for the web—whatever the device—we need to shed the notion that we create layouts from a canvas in. We need to flip it on its head, and create layouts from the content out.

— Mark Boulton, “A Richer Canvas"

When designing from the canvas in, the canvas dimensions are the constant on which the whole grid is anchored. Everything is sized and positioned relative to them. Designing from the content out means finding a constant in your content—be it the ideal measure of a paragraph or the dimensions of an ad unit—and building your grid out from there to fill the space available.

Now, layouts that expand to fill the space available are nothing new—after all, fluid layouts are basically the web’s default—but very few layouts can be stretched or squashed indefinitely without the relationships between components breaking down, and that’s where states come in.

States

Fluid layouts are often compared to water, but water isn’t always fluid. H₂O has three different states, and depending on the temperature can be a solid, liquid, or gas, transitioning seamlessly from one to another at specific points (0ºC, 100ºC). An infinite grid also has multiple states (single column, multi-column, etc.), and should transition as seamlessly as possible between them at specific breakpoints as well. For example, just as ice is an appropriate state for water when the temperature is low, a single-column layout may be the appropriate state for an infinite grid on smaller devices.

Water’s state change is caused by the rearrangement of its molecules. When an infinite grid changes state, we rearrange its components.

Components

Each state in a responsive layout tends to be made up of the same components, such as an image gallery or navigation menu. However, as Ethan Marcotte recently outlined, the form these components take can vary dramatically between one state and another, usually involving a change in one or more of the following attributes:

1. Hierarchy: What’s its order and prominence in the layout?
2. Density: How much detail do you show?
3. Interaction: Should it be a list of links or a dropdown? A carousel or a group of images?
4. Width: Is it fixed (a specific width), flexible (set with max-width), or fractional (set with percentages)?

Considering how each component’s attributes may change between states helps ensure that the grid system produces the right layout for the space available. In this example, watch how the different components adjust their width (between fixed and flexible) and position between states.

Designing an infinite grid system

Though we’re only beginning to scratch the surface of designing infinite grids, a few techniques are already proving useful. To get started, here are a few guidelines:

1. Use proportional units

Designing a grid is about deciding what should be proportional to what. When you choose a unit, you bind a dimension to a particular variable:

• Pixels size an element relative to a particular resolution
• Ems size an element relative to its font size; large rems size it relative to the document’s base font size
• Percentages size an element relative to its container
• VH and VW units size an element relative to the viewport

Absolute units like pixels effectively give a layout a sell-by date, locking it to a finite resolution range in which it will “work.� Proportional units (ems, rems, and percentages) enable you to define the important relationships between elements, and are a crucial first step on the road to resolution independence.

2. Start with the extremes, then work out the in-betweens

Every layout has a natural “optimum� range for its content. How wide can you stretch it before it starts to break? How small can you squish it before it starts to collapse? For example, if the width available is less than 45 characters per line, your layout starts to feel cramped; if there’s more than a column’s worth of white space on either side of your layout, the content starts to feel dwarfed. Where these extremes occur differs for every design, and depends largely on your content.

Designing for the extremes first forces you to consider how best to present your content at either end of the spectrum. Consider the hierarchy, density, interaction, and width of each component at the smallest state, then do the same for the largest state.

For example, lets say my largest state is 75em wide (any larger and the white space starts to dwarf the content), and my smallest is 34em (any smaller and the measure is less than optimal). In the largest state it makes sense for my navigation to be a horizontal list (interaction) at the top (hierarchy), but in the smallest state it might make more sense to move it to the bottom of the layout (hierarchy), or collapse it into a show/hide list (interaction). Designing these independently of one another helps you be more objective about what is best for each state, rather than stretching a one-size-fits-all solution across every state.

3. Change state where relationships break down

Once you’ve worked out the extremes, it’s time to consider how and where one state should transition to another. Just like water changes to steam when its molecules get too far apart, one state should change to another when the relationships between its components begin to break down, such as when the measure is getting too wide, or the left-aligned logo is getting so far from the right-aligned menu that the visual connection between them is broken.

This is where live prototypes come in handy. It’s incredibly difficult to predict exactly at what width (in relation to the content) a layout needs to change from one state to another. A prototype allows you to easily resize your browser to find the exact point at which relationships break down, so you can add a breakpoint there. New tools (like Gridset and Responsive.is) are making it easier than ever to create and test responsive prototypes, so there’s no excuse not to.

The number of states you require will depend on how much your layout changes from one extreme to the other. For example, my smallest state has a single column with a collapsed menu, and my largest state has three columns and an expanded menu. However neither state looks quite right between 34em and 53em, so I’ve added an “in-between� state which maintains the smallest state’s single column article, but expands the menu and divides the footer into three columns to make the most of the space available. This smooths out the transition from one extreme to another quite nicely.

With each state change, remember to reconsider the hierarchy, density, interaction, and width of each component. Perhaps your main content column should be fixed width now to ensure the measure doesn’t get too wide, or maybe you have room to add more information (density) to your navigation?

4. Go beyond the extremes

So we now have a responsive layout with multiple states, that transitions smoothly from the smallest state to the largest. But that’s only a range of 34 to 75em. What about when the available space is smaller or greater than those states? How do we get a layout that truly goes from zero to ??

At the smaller end of the scale space is precious, so we need to make the most of what we have. For under 20em, I’ve reduced (but not removed) margins, decreased line height, and indented bulleted lists. Basically, I’ve done what I can to optimize readability, even though I have a less-than-optimum amount of space available.

At the other end of the scale, the problem is too much space, specifically whitespace. This makes content feel dwarfed, so we need to find ways to balance it out. Unfortunately, simply scaling up a layout indiscriminately doesn’t always work, as we start to come up against reading distance. If you scale up your text size to maintain approximately sixty characters per line, but the type is so big that I have to physically turn my head to read it, that’s not a good experience.

Instead, look for elements such as headers, dividers, or images that you can scale up with the canvas, which helps anchor a layout visually without ruining readability. In my example, the ruler element that stretches full-width helps “anchor� the design in the whitespace, and at 75em I start scaling up the elements relative to the viewport size using VW units. The body text starts to get uncomfortably large at 90em so I use rem units to keep it at a comfortable reading size while the other elements scale around it.

Either way, the goal is to make the most of the space available, relative to your content, to maximize readability and presentation.

To infinity, and beyo—

Actually, infinity would be enough.

Using a predefined grid seems to make as much sense as using a predefined colour scheme.

— Jeremy Keith

I’ve tried to stay away from specifics here, because there are none. Each layout is different, and there are no magic numbers that will work every time.

Instead, we have to nail down the relationships between elements, and then let the specifics take care of themselves. We don’t have all the answers yet, but doing this will help us ask the right questions.

This is a problem worth solving. And we’re not just solving it for ourselves, but for everyone who designs for digital media in the future—and that could be a lot of people. An infinite number, even.

WordPress is one of the world’s most popular Content Management Systems. It is used by a wide range of people, from English-speaking journalists to French entrepreneurs, from Japanese-speaking students to Arabic-speaking political activists, and so on. Thus, owing to its support for multiple languages as well as localization and translation standards, WordPress serves a target audience that speaks and interacts in various languages. Furthermore, such translation standards help WordPress developers to code and build themes and plugins to make life easier for the end users of WordPress, no matter what their first language may be!

Howdy, folks! Welcome to more Smashing Magazine CSS Q&A. It works like this: you send in questions you have about CSS, and at least once a month we’ll pick out the best questions and answer them so that everyone can benefit from the exchange. Your question could be about a very specific problem you’re having, or it could even be a question about a philosophical approach. We’ll take all kinds.

If you’re interested in exploring more Q&A, there’s a bunch more in my author archive.

CSS Project Structure

Stephen Beiler asks:

“Could you please explain your strategy for building CSS? How do you start and what does the structure of your style sheet look like? Do you use something like tip/comment helpers (e.g. the color style guide) or perhaps the related markup, or anything else? How do you structure your code?”

These days I’m using Sass for all my projects. Sass provides things that I’m sure you are all aware of — like variables and mixins, but it also provides a very simple and vital feature: includes. Just like you might use an include() function in PHP, or render a partial in Rails, you can @import another Sass file in Sass. Unlike the native CSS @import, which simply makes a request for that file, Sass goes and gets that file and includes the file’s content when compiling down to CSS.

I use this feature heavily while organizing and structuring CSS for a project. It allows me to break my styling into whatever files make sense for me, as the author. It allows me an ASCII drawing:

On my recent redesign of CSS-Tricks, I ended up with 28 .scss files, most of which were modular bits only ever @imported into bigger style sheets. This worked really well for me, matching how I naturally organize things, and not an organization scheme forced upon me, nor one built from artificial hacks (like enormous files with commented separators).

Regarding the color style guide, one of those .scss files is always one I call _bits.scss, which is were I put all my re-usable “bits” that any of my other .scss files might need. Color variables, my own custom @mixins, etc. I’m a fan of setting up colors as variables right away in a project, so that you can reference them easily whenever needed. If you need variations on that color, you can use Sass functions like darken() and lighten() to adjust.

Slightly controversially, I like naming my colors based on their color, like $red, $blue, and $green, because then it takes me zero seconds to remember and actually use them. Whereas in the past, when I’ve tried to be super semantic about my colors and name them $brand, $secondaryHighlight, and $moduleBackground or things like that, I could never remember my own cleverness, and it slowed me down.

When To Use OOCSS

Michael Winczewski asks:

“Chris, what do you think of OOCSS? Do you use it in your code, and if so, how? When would you advise against using it? And when would you advise using it?”

I think it’s fantastic. It’s more of a way of thinking than a strict set of rules. I doubt that I understand OOCSS in the same way that Nicole Sullivan does, or that I understand SMACSS in the same way Jonathan Snook does. But I think I understand the spirit behind these movements and use them in ways that make sense to me.

What it boils down to for me is usually: write super semantic markup, but use a class name on just about every important “chunk”. Then style things largely based on those class names. It’s about identifying patterns and styling that pattern in a smart way. That way, this pattern can be re-used easily, efficiency is inherent, and no semantics are harmed. And this doesn’t mean going nuts with class names, it means using just the right amount.

Specifically to your question, I think these concepts work for every project. There isn’t anything I can think of that would warrant not doing it this way. It’s just a grown up way to approach CSS.

Selecting All Link Pseudo Classes

Ren Walker asks:

Is there a quick trick in either LESS, Sass, or with the tried and true CSS where you can select all the pseudo classes of an element? For example, instead of writing:

a, a:visited, a:active { }

You could conceivably do:

a:* { }

Sure. If you’re using Sass, you could craft your own @mixin to your needs. For instance:

@mixin all-link-psuedos($col) {
  &:link     { color: darken($col, 10%); }
  &:visisted { color: darken($col, 20%); }
  &:hover    { color: darken($col, 30%); }
  &:active   { color: darken($col, 40%); }
}

$linkColor: red;
a {
  color: $linkColor;
  @include all-link-psuedos($linkColor);
}

There is a selector combiner type of thing in just CSS as well.

:-webkit-any(a:link, a:visited, a:hover, a:active) {
  color: red; 
}
:-moz-any(a:link, a:visited, a:hover, a:active) {
  color: red; 
}

But this isn’t really the intended use case for it, since you could just comma separate those selectors just as easily. Plus, the browser support isn’t great. Double plus, chances are you want different styling for those things instead of the same.

Fallbacks For SVG

Angelo D’Ambrosio asks:

“What’s the simplest and most efficient way to let the browser choose whether to load the SVG or the bitmap version of an img or a CSS background, according to browser support?”

1. Download a version of Modernizr that is trimmed down to just testing SVG (assuming that’s the only test you need).
2. Run the test. If it passes, put in the SVG. If it fails, put in the bitmap.

Essentially:

if (!Modernizr.svg) {
  $("#logo").css("background-image", "url(fallback.png)");
}

Modernizr isn’t needed on every website in the world — it’s needed on websites where you need to very specifically fork style or behavior for browsers that do or don’t support a feature. For instance, if you have a geolocation feature on your website (but the feature works just fine by typing in an address manually), you may not need Modernizr to tell you about the lack of support, since you may not need to do anything anyway.

SVG is a perfect use case for Modernizr, because there is no simple native way to provide a fallback.

Modernizr gives you the clean fork you need.

Just for the record: the only reason you would need a fallback for SVG these days if you have to support IE 8 and down, or older Android.

Maintaining Vertical Rhythm

David Casey asks:

“Chris, what’s your strategy for maintaining vertical rhythm for typography / design elements in responsive design?”

Looking at a page of pure typography — where someone has set up a background of lines where you can see the vertical rhythm matching up perfectly — is pretty cool. You can get a sense for why that makes for nice reading (with the lines removed of course):

But I think it’s a bit of a fool’s errand to enforce perfection on it up and down every page of a website. One image inside the content will most likely throw the whole thing out of whack. Yeah, we could crop it, but do we want to be making choices like that for the design de jour? We could resize it, but then perhaps it’s not lining up to our vertical grid lines like we want. In a world of flexible media, I don’t think it’s worth it.

If you do think it’s worth it, do note Dan Eden’s Baseline.js which does image resizing to combat the baseline grid issue. Molten leading may also be of interest.

Does it matter if the rhythm gets off? I don’t think so. Well set text will still look good. Remember: the type will still be in rhythm with the text right around it. So who cares if it’s off with text thousands of pixels away from it, and perhaps off screen? Making sure the type looks good in general is far more important than adhering to an invisible grid dogmatically.

Responsive + Retina Background-Image

Smarajit Dasgupta asks:

“How to tackle CSS background images for both responsive and retina display. If we use a background-size of 100% to make sure the image resizes on smaller devices, how do we set the same background-size in media query (-min-device-pixel-ratio: 1.5) to half of the @2x image?

Also, to tackle images this way, should we set initial scale to one in meta viewport that we normally would for responsive websites? Would that be a problem as far as retina displays are concerned?”

This is a difficult question to answer because so much depends on the particular implementation and what your goals are. Presumably, your goals are:

1. Make it look good all the time.
2. Don’t waste bandwidth.

I can share with you how this works on a particular area of CSS-Tricks, in which I use a background-image that is both responsive (in that it works in a flexible width area) and retina (looks sharp on retina displays). The area is called The Lodge, and I used a snowy cabin graphic for the background.

That’s actually the “medium” breakpoint (I call it the “mama bear”) that many tablets see. There is a wider and narrower breakpoint as well. Like you, I want this website to look great on retina displays, but also worry about its bandwidth. Serving a background image that is big enough to look great on retina at the largest breakpoint to a non-retina display at the smallest breakpoint is not good.

What I do is put all the background-images in media queries.

/* Reverso Baby Bear */
@media (min-width: 320px) {
  .lodge-wrap {
     background: url(lodge-bg-small.jpg);
  }
}

/* Reverso Mama Bear */
@media (min-width: 800px) {
  .lodge-wrap {
     background: url(lodge-bg-medium.jpg);
  }
}

/* Reverso Papa Bear */
@media (min-width: 1400px) {
  .lodge-wrap {
     background: url(lodge-bg-large.jpg);
  }
}

Doing it this way means that only one of those will match and only one resource will be downloaded. There is also is no “default” (outside a media query) which runs the risk of starting to download before being overridden.

I also make each of those three different images larger than they need to be, and let them scale down with background-size: 100%;. That way they are retina ready all the time, whether or not the device is. A bit of a waste sometimes, but at least I’m smart enough not to supply the largest image all the time.

If you want to get extra fancy, you’d need two media queries for each breakpoint: one for retina and one for non-retina. In my case, I’d have six total media queries… they’d be pretty complex, but it’s do-able. Here’s the two for the smallest breakpoint:

@media only screen and (min-width: 320px) {

  /* Small screen, non-retina */

}

@media
only screen and (-webkit-min-device-pixel-ratio: 2)      and (min-width: 320px),
only screen and (   min--moz-device-pixel-ratio: 2)      and (min-width: 320px),
only screen and (     -o-min-device-pixel-ratio: 2/1)    and (min-width: 320px),
only screen and (        min-device-pixel-ratio: 2)      and (min-width: 320px),
only screen and (                min-resolution: 192dpi) and (min-width: 320px),
only screen and (                min-resolution: 2dppx)  and (min-width: 320px) { 

  /* Small screen, retina, stuff to override above media query */

}

You’d repeat that for the next size breakpoint(s), overriding the background as you go down. Here’s more code and some more information on that.

---

© Chris Coyier for Smashing Magazine, 2012.

Howdy, folks! Welcome to more Smashing Magazine CSS Q&A. It works like this: you send in questions you have about CSS, and at least once a month we’ll pick out the best questions and answer them so that everyone can benefit from the exchange. Your question could be about a very specific problem you’re having, or it could even be a question about a philosophical approach. We’ll take all kinds.

If you’re interested in exploring more Q&A, there’s a bunch more in my author archive.

CSS Project Structure

Stephen Beiler asks:

“Could you please explain your strategy for building CSS? How do you start and what does the structure of your style sheet look like? Do you use something like tip/comment helpers (e.g. the color style guide) or perhaps the related markup, or anything else? How do you structure your code?”

These days I’m using Sass for all my projects. Sass provides things that I’m sure you are all aware of — like variables and mixins, but it also provides a very simple and vital feature: includes. Just like you might use an include() function in PHP, or render a partial in Rails, you can @import another Sass file in Sass. Unlike the native CSS @import, which simply makes a request for that file, Sass goes and gets that file and includes the file’s content when compiling down to CSS.

I use this feature heavily while organizing and structuring CSS for a project. It allows me to break my styling into whatever files make sense for me, as the author. It allows me an ASCII drawing:

On my recent redesign of CSS-Tricks, I ended up with 28 .scss files, most of which were modular bits only ever @imported into bigger style sheets. This worked really well for me, matching how I naturally organize things, and not an organization scheme forced upon me, nor one built from artificial hacks (like enormous files with commented separators).

Regarding the color style guide, one of those .scss files is always one I call _bits.scss, which is were I put all my re-usable “bits” that any of my other .scss files might need. Color variables, my own custom @mixins, etc. I’m a fan of setting up colors as variables right away in a project, so that you can reference them easily whenever needed. If you need variations on that color, you can use Sass functions like darken() and lighten() to adjust.

Slightly controversially, I like naming my colors based on their color, like $red, $blue, and $green, because then it takes me zero seconds to remember and actually use them. Whereas in the past, when I’ve tried to be super semantic about my colors and name them $brand, $secondaryHighlight, and $moduleBackground or things like that, I could never remember my own cleverness, and it slowed me down.

When To Use OOCSS

Michael Winczewski asks:

“Chris, what do you think of OOCSS? Do you use it in your code, and if so, how? When would you advise against using it? And when would you advise using it?”

I think it’s fantastic. It’s more of a way of thinking than a strict set of rules. I doubt that I understand OOCSS in the same way that Nicole Sullivan does, or that I understand SMACSS in the same way Jonathan Snook does. But I think I understand the spirit behind these movements and use them in ways that make sense to me.

What it boils down to for me is usually: write super semantic markup, but use a class name on just about every important “chunk”. Then style things largely based on those class names. It’s about identifying patterns and styling that pattern in a smart way. That way, this pattern can be re-used easily, efficiency is inherent, and no semantics are harmed. And this doesn’t mean going nuts with class names, it means using just the right amount.

Specifically to your question, I think these concepts work for every project. There isn’t anything I can think of that would warrant not doing it this way. It’s just a grown up way to approach CSS.

Selecting All Link Pseudo Classes

Ren Walker asks:

Is there a quick trick in either LESS, Sass, or with the tried and true CSS where you can select all the pseudo classes of an element? For example, instead of writing:

a, a:visited, a:active { }

You could conceivably do:

a:* { }

Sure. If you’re using Sass, you could craft your own @mixin to your needs. For instance:

@mixin all-link-psuedos($col) {
  &:link     { color: darken($col, 10%); }
  &:visisted { color: darken($col, 20%); }
  &:hover    { color: darken($col, 30%); }
  &:active   { color: darken($col, 40%); }
}

$linkColor: red;
a {
  color: $linkColor;
  @include all-link-psuedos($linkColor);
}

There is a selector combiner type of thing in just CSS as well.

:-webkit-any(a:link, a:visited, a:hover, a:active) {
  color: red; 
}
:-moz-any(a:link, a:visited, a:hover, a:active) {
  color: red; 
}

But this isn’t really the intended use case for it, since you could just comma separate those selectors just as easily. Plus, the browser support isn’t great. Double plus, chances are you want different styling for those things instead of the same.

Fallbacks For SVG

Angelo D’Ambrosio asks:

“What’s the simplest and most efficient way to let the browser choose whether to load the SVG or the bitmap version of an img or a CSS background, according to browser support?”

1. Download a version of Modernizr that is trimmed down to just testing SVG (assuming that’s the only test you need).
2. Run the test. If it passes, put in the SVG. If it fails, put in the bitmap.

Essentially:

if (!Modernizr.svg) {
  $("#logo").css("background-image", "url(fallback.png)");
}

Modernizr isn’t needed on every website in the world — it’s needed on websites where you need to very specifically fork style or behavior for browsers that do or don’t support a feature. For instance, if you have a geolocation feature on your website (but the feature works just fine by typing in an address manually), you may not need Modernizr to tell you about the lack of support, since you may not need to do anything anyway.

SVG is a perfect use case for Modernizr, because there is no simple native way to provide a fallback.

Modernizr gives you the clean fork you need.

Just for the record: the only reason you would need a fallback for SVG these days if you have to support IE 8 and down, or older Android.

Maintaining Vertical Rhythm

David Casey asks:

“Chris, what’s your strategy for maintaining vertical rhythm for typography / design elements in responsive design?”

Looking at a page of pure typography — where someone has set up a background of lines where you can see the vertical rhythm matching up perfectly — is pretty cool. You can get a sense for why that makes for nice reading (with the lines removed of course):

But I think it’s a bit of a fool’s errand to enforce perfection on it up and down every page of a website. One image inside the content will most likely throw the whole thing out of whack. Yeah, we could crop it, but do we want to be making choices like that for the design de jour? We could resize it, but then perhaps it’s not lining up to our vertical grid lines like we want. In a world of flexible media, I don’t think it’s worth it.

If you do think it’s worth it, do note Dan Eden’s Baseline.js which does image resizing to combat the baseline grid issue. Molten leading may also be of interest.

Does it matter if the rhythm gets off? I don’t think so. Well set text will still look good. Remember: the type will still be in rhythm with the text right around it. So who cares if it’s off with text thousands of pixels away from it, and perhaps off screen? Making sure the type looks good in general is far more important than adhering to an invisible grid dogmatically.

Responsive + Retina Background-Image

Smarajit Dasgupta asks:

“How to tackle CSS background images for both responsive and retina display. If we use a background-size of 100% to make sure the image resizes on smaller devices, how do we set the same background-size in media query (-min-device-pixel-ratio: 1.5) to half of the @2x image?

Also, to tackle images this way, should we set initial scale to one in meta viewport that we normally would for responsive websites? Would that be a problem as far as retina displays are concerned?”

This is a difficult question to answer because so much depends on the particular implementation and what your goals are. Presumably, your goals are:

1. Make it look good all the time.
2. Don’t waste bandwidth.

I can share with you how this works on a particular area of CSS-Tricks, in which I use a background-image that is both responsive (in that it works in a flexible width area) and retina (looks sharp on retina displays). The area is called The Lodge, and I used a snowy cabin graphic for the background.

That’s actually the “medium” breakpoint (I call it the “mama bear”) that many tablets see. There is a wider and narrower breakpoint as well. Like you, I want this website to look great on retina displays, but also worry about its bandwidth. Serving a background image that is big enough to look great on retina at the largest breakpoint to a non-retina display at the smallest breakpoint is not good.

What I do is put all the background-images in media queries.

/* Reverso Baby Bear */
@media (min-width: 320px) {
  .lodge-wrap {
     background: url(lodge-bg-small.jpg);
  }
}

/* Reverso Mama Bear */
@media (min-width: 800px) {
  .lodge-wrap {
     background: url(lodge-bg-medium.jpg);
  }
}

/* Reverso Papa Bear */
@media (min-width: 1400px) {
  .lodge-wrap {
     background: url(lodge-bg-large.jpg);
  }
}

Doing it this way means that only one of those will match and only one resource will be downloaded. There is also is no “default” (outside a media query) which runs the risk of starting to download before being overridden.

I also make each of those three different images larger than they need to be, and let them scale down with background-size: 100%;. That way they are retina ready all the time, whether or not the device is. A bit of a waste sometimes, but at least I’m smart enough not to supply the largest image all the time.

If you want to get extra fancy, you’d need two media queries for each breakpoint: one for retina and one for non-retina. In my case, I’d have six total media queries… they’d be pretty complex, but it’s do-able. Here’s the two for the smallest breakpoint:

@media only screen and (min-width: 320px) {

  /* Small screen, non-retina */

}

@media
only screen and (-webkit-min-device-pixel-ratio: 2)      and (min-width: 320px),
only screen and (   min--moz-device-pixel-ratio: 2)      and (min-width: 320px),
only screen and (     -o-min-device-pixel-ratio: 2/1)    and (min-width: 320px),
only screen and (        min-device-pixel-ratio: 2)      and (min-width: 320px),
only screen and (                min-resolution: 192dpi) and (min-width: 320px),
only screen and (                min-resolution: 2dppx)  and (min-width: 320px) { 

  /* Small screen, retina, stuff to override above media query */

}

You’d repeat that for the next size breakpoint(s), overriding the background as you go down. Here’s more code and some more information on that.

---

© Chris Coyier for Smashing Magazine, 2012.

The easiest way to decorate your boring computer desktop is with creative wallpapers. It only takes a few clicks to beautify even the dullest workspace. In the following collection you will find little pieces of art, hand-crafted by talented Photoshoppers from around the world. The wallpapers are colorful, elaborately designed and unique at the same time. As they come in a variety of resolutions, we have equipped the collection with the necessary information. Now find your next desktop wallpaper!