Simple Responsive Images With CSS Background Images

Advertisement

Editor’s Note: This article features just one of the many, suboptimal solutions for responsive images. We suggest that you review different approaches before choosing a particular responsive image solution, including these two: How To Avoid Duplicate Downloads In Responsive Images and Choosing A Responsive Image Solution.

With all the talk of new HTML5 standards such as the srcset attribute and <picture> element, as well as server-side techniques such as Responsive Web Design + Server Side Components (RESS), you'd be forgiven for concluding that simple, static websites can’t support responsive images today. That conclusion might be premature, however. In fact, there’s an easy, straightforward way to deliver responsive images that’s supported by all of today’s Web browsers: CSS background images.

However, the approach has some limitations, and it doesn’t work in all cases. But if your requirements aren’t complicated, and if you’re willing to make an extra effort to ensure your images are accessible, CSS background images may be all you need.

In this article we’ll look at the CSS background approach in several steps:

  1. First, we’ll review the goals and requirements for responsive images.
  2. Then we’ll see how CSS media queries can help identify important characteristics of our users’ devices.
  3. We’ll explore the key CSS background-image property that lets us respond to those characteristics.
  4. We’ll look at a strategy for optimizing the individual images that make up a responsive set.
  5. We’ll examine the limitations of this approach; in many cases there are simple techniques to overcome them.
  6. And finally, we’ll describe the problems with this approach for which there are no workarounds.

Note: This approach requires explicit control of your website’s style sheets as well as its HTML markup. If your website relies on a content management system (CMS), you might not have enough control over those aspects of the website.

The Need For Responsive Images

Responsive images are an important component of responsive Web design (RWD), a design strategy developed by Ethan Marcotte to cope with the amazing popularity of mobile devices for viewing the Web. Ethan recognized that the previous best practice — developing separate websites for different types of devices — simply couldn’t cope with the astonishing variety of devices Web users might employ to access the websites we build.

RWD takes a completely different approach: create a single website but let that website recognize and respond to its context. If the user has a desktop browser with a wide screen, for example, allow the website content to spread across multiple columns. On a smartphone, however, rearrange the content to confine it to a single column.

In many cases, that’s where responsive design stops — simple adjustments to layout and presentation. If that’s all we consider, however, we’re not honoring the goal of responsive design, and we’re selling our users short.

Truly responding to users’ context requires a design that considers all aspects of the experience, and that often includes images. For a real life example, consider a website such as contfont.net. That single page website has one main image and a typical set of HTML, style sheets, fonts, and JavaScript files.

Resource Type Compressed Size
Main page HTML 6 KB
Style sheet CSS 10 KB
Fonts Web Font 221 KB
Scripts JavaScript 21 KB
Supporting images Image 48 KB
Main site image Image ??

The website looks gorgeous on computers with super–high-resolution displays because it includes a high-resolution version of the main image. Delivering that image file doesn’t come cheap, though; its 1940 × 1229 pixels make the image 446 KB in size after compression.

The website could use that same image file for all users without compromising the visual experience. Web browsers on smaller devices such as smartphones would resize it to fit the display. While that approach would preserve the visual appeal of the website, the overall user experience would suffer significantly.

On an iPhone, a 290 × 183 pixel image that is 18 KB in size looks identical to the 452 KB, 1940 × 1229 pixel image on the MacBook Pro.
On an iPhone, a 290 × 183 pixel image that is 18 KB in size looks identical to the 452 KB, 1940 × 1229 pixel image on the MacBook Pro. Larger view.

What does that mean for a user browsing to the website on, say, an earlier generation smartphone? For that user, a 290 × 183 pixel image that is 18 KB in size looks identical to the larger version. Without a responsive image approach, the website would force the user to download an extra 429 KB of data that is completely wasted. This excess is not just academic; it has a substantial effect on the website’s load time. The smartphone user may be accessing the website over a typical 3G connection at 2 Mb/s. Failing to deliver a responsive image increases the load time from 1.3 seconds to 3 full seconds, significantly more than doubling it!

The full size image takes 3.0 seconds to load over a 3G network, compared to 1.3 seconds for a responsive image.
The full size image takes 3.0 seconds to load over a 3G network, compared to 1.3 seconds for a responsive image. Larger view.

The primary goal for a responsive image approach is simple: deliver only the pixels that the user’s device can actually use.

Identifying The User’s Context

If our websites are going to respond to our users’ context, we need a way to identify that context. Today, CSS offers the most effective way to distinguish different devices. CSS gives us the answers to two critical questions: what is the size of the user’s display? And does the display support Retina-style images?

The CSS tool that gives us this information is a media query. Media queries define a set of CSS style properties that apply only to devices with specific qualities. Originally, media queries were limited to media types. The CSS specification defines a large number of them including, for example braille (for braille tactile feedback devices), speech (for speech synthesizers), tty (for devices with only monospaced fonts, such as teletypes) and tv (for television-type devices with low resolution and no scrolling). Currently, the only two media types that most browsers support are print (for printed, paged material) and screen (for computer screens).

CSS3 expanded the use of media queries, however, by allowing style sheets to specify specific features of devices as well as the media type. And in the case of screen devices, the features can include many characteristics of the display, including its width, orientation, resolution and pixel ratio. Those features provide just the information we need to select an appropriate responsive image.

Here’s how media queries can help us solve the dilemma of the previous section. As an example, a 15-inch MacBook Pro has a screen width of 1440 pixels (ignoring for the moment the Retina display option). To identify styles that apply to screens of this size (and larger), we can write our style sheet as:

@media only screen and (min-width: 1440px) {
	/* styles for MacBook Pro-sized screens and larger */
}

Any styles defined in that block will only apply when the user accesses the Web page using a device with a screen size of 1440 pixels. There’s a catch, though. The media screen size doesn’t apply to the device’s hardware; rather, it applies to the Web browser’s viewport. The viewport is the size of the browser window after subtracting any browser chrome, such as toolbars.

Unless the user is browsing in full screen mode, the browser window will actually be somewhat less than 1440 pixels in width. For this more common case, therefore, we might want to rewrite the style sheet a bit. Perhaps 1200 pixels is more realistic.

@media only screen and (min-width: 1200px) {
	/* styles for wide screens */
}

The media query has two parts. The first part, only screen, indicates that the styles shouldn’t apply to printed copies of the page or other non-standard devices. (The only keyword doesn’t actually affect the media query; it’s there strictly for really old browsers that don’t support media features. Because those browsers don’t understand the only syntax, they’ll simply ignore the entire block of styles.) The second part of the query, min-width: 1200px, gives the minimum screen width at which the styles will be applied. The and that joins those parts means that both must be true for the styles to apply.

We can use a similar technique to define styles for portrait-mode smartphones.

@media only screen and (max-width: 320px) {
	/* styles for narrow screens */
}

In this case we can go ahead and use the actual device screen size in the query. Web browsers on smart phones are always full-screen width.

The min-width and max-width feature specifications make it easy to determine the width of the user’s device. Unfortunately, identifying a Retina display isn’t quite as straightforward. Different browsers use different syntaxes for this feature, so we must resort to vendor prefixes. To make things slightly worse, many versions of Firefox had a bug in their syntax, so we need to use both a fixed and a “broken” syntax for Mozilla browsers. As of now, the recommended query for Retina-quality displays looks like the following.

@media
only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and (min--moz-device-pixel-ratio: 2),
only screen and (-moz-min-device-pixel-ratio: 2),
only screen and (-o-min-device-pixel-ratio: 2/1),
only screen and (min-device-pixel-ratio: 2),
only screen and (min-resolution: 192dpi),
only screen and (min-resolution: 2dppx) { 
	/* styles for Retina-type displays */
}

Eventually browsers will all support the standard dots per pixel notation (dppx) and we can drop the vendor prefixes from our style sheets.

The CSS Background-Image Property

If CSS can reliably identify a user’s context, you might think it would be easy to support responsive images. One approach that might seem logical would be to set display: none for those images we don’t wish to download. Here’s an attempt based strictly on screen size. (We’re omitting Retina considerations for brevity.)

<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="utf-8">
		<title></title>
		<style>
		img.smallscreen { display: none; }
		@media only screen and (max-width: 320px) {
			img { 
				display: none; 
			}
			img.smallscreen { 
				display: inline; 
			}
		}
		</style>
	</head>
	<body>
		<img src="largeimage.jpg">
		<img class="smallscreen" src="smallimage.jpg>
	</body>
</html>

The code above will display the correct image based on the screen size; however, the display: none property won’t actually prevent browsers from downloading the hidden images. Smartphone browsers will download the large image even though it’s never displayed. Unfortunately, this obvious approach doesn’t accomplish the main goal for responsive images.

The problem occurs because browsers handle the HTML separately from the CSS. The HTML markup requests two image files, so the browser dutifully fetches both. Afterwards, it parses the CSS styles only to discover that one of the images is not displayed, but by then it's too late.

Our CSS media queries will only work if we can use them strictly for CSS properties and not HTML content. That may seem impossible, but it turns out that there is a sneaky way to only use CSS for imagery — the background-image property. Here’s how we do that:

  1. In the HTML markup, don’t include references to any image files. Instead simply use empty <div> or <span> elements.
  2. Place an image in the empty <div> or <span> by setting its background-image property.
  3. Use media queries to substitute the appropriate responsive images, depending on screen size and resolution.

Using these rules, we can modify the above example so that responsive images actually work correctly.

<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="utf-8">
		<title></title>
		<style>
		#image { 
			background-image: url(largeimage.jpg); 
		}
		@media only screen and (max-width: 320px) {
			#image { 
				background-image: url(smallimage.jpg); 
			}
		}
		</style>
	</head>
	<body>
		<div id="image"></div>
	</body>
</html>

That, in a nutshell, is how to support responsive images with CSS background images. Any real application will require a bit more code (for example, we need some way to indicate the image size). The additional code, however, is standard CSS without any tricks.

Creating The Responsive Images

With an understanding of how to use responsive images, the next step is actually creating the image variations. The original source image should have the highest resolution possible, at least as high as the most detailed image your website will deliver. (In the case of contfont.net, the source image is 3888 × 2592 pixels.) Your graphics program of choice should be able to resize that source image to fit your website's breakpoints.

As long as you’re working in your graphics program, be sure to optimize even the high-resolution images as much as possible, for example, by using the lowest quality setting feasible for the image. Even users on high-resolution displays will appreciate the faster page load time. If the image is in JPEG format, you can also enable the progressive option when you export it. This option lets the browser display a low-fidelity version of the image quickly while it continues to download the full image.

When it comes to the breakpoints themselves, you shouldn’t fall into the temptation of using the same breakpoints for your images as you’re using for the website’s layout. It’s rarely the case that the best layout breakpoints are also the best image breakpoints. Instead, optimize your image breakpoints for the image. Here’s a strategy I like for finding the optimum image sizes.

First determine the smallest resolution image that is practical for your website to deliver. In the case of contfont.net, the smallest practical viewport size is 320 pixels, corresponding to a non-Retina iPhone in portrait orientation. (Devices with smaller viewports exist, and are likely to exist in the future — smart watches, anyone? — but those devices aren’t likely to visit the website.) On the contfont.net website, a viewport size of 320 pixels leaves 290 pixels for the image width, so the lowest resolution image we need is 290 × 183 pixels. Have your graphics program resize the source image to that size.

Next create a simple test page for that image. Here’s the markup I use:

<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="utf-8">
		<title></title>
	</head>
	<body>
		<img src="test.jpg" width="100%">
		<p>Window size: <span id="size"></span> pixels</p>
		<script>
		window.onresize = function() {
			document.getElementById("size").innerHTML = window.innerWidth;
		};
		</script>
	</body>
</html>

This page displays the test image and the current window size. Open it in your browser, and resize the browser window so that its width is about the size of your smallest breakpoint. Because the test image matches this width, it should look fine.

Now slowly resize your browser window by increasing its width. As the width grows, the browser will automatically interpolate and resize the image. As the amount of interpolation increases, the image quality suffers and, at some point, the image will look unacceptably poor. Note the screen width when that point occurs, as that screen width is your first breakpoint.

Resize your browser window until the width at which the image looks unacceptably poor. That screen width will be your breakpoint.
Resize your browser window until the width at which the image looks unacceptably poor. That screen width will be your breakpoint. Larger view.

When you’ve found the first breakpoint, use your graphics program to create a new test image at that size from the original source. Repeat the process with the new test image to find the next breakpoint, and continue until you’ve reached the maximum viewport width your website will support.

At this point you’ll have your image breakpoints and a set of images to match. For Retina displays, create additional images at double resolution. Here’s the full list of images for the contfont.net website:

Image File Resolution Size (no compression)
candc290.jpg 290 × 183 19,378 Bytes
candc290@2x.jpg 290 × 183 (Retina) 56,277 Bytes
candc538.jpg 538 × 341 52,914 Bytes
candc538@2x.jpg 538 × 341 (Retina) 159,867 Bytes
candc970.jpg 970 × 614 132,766 Bytes
candc970@2x.jpg 970 × 614 (Retina) 451,939 Bytes

You can use this approach separately for each image on your website, as there’s no reason that all images have to use the same breakpoints. If your website has a lot of images, however, it might be more efficient to find some common breakpoints using a few of the website’s images and then repeat those breakpoints for all of the images on the website.

Overcoming Limitations

In the simplest cases, the steps above are all it takes to support responsive images. Of course, websites are rarely that simple, and, indeed, there are several steps we can take to improve the approach.

Making Images Accessible

The standard <img> tag supports an alt attribute that provides an alternative, textual description of the image. That description is important for accessible websites, as users with screen readers rely on the alt content to describe the image. CSS background images don’t have an <img> tag and thus no alt attribute, but we can still make them accessible to vision-impaired users. To do that, we add two additional attributes to our markup.

<div id="image" role="img" aria-label="Textual Description"></div>

The first extra attribute, role, lets screen readers know that the <div> is serving the role of an <img> tag, even though it’s not explicit in the markup. The second attribute, aria-label serves the same purpose as an alt attribute in an <img>. With those two additions, screen readers can announce to their users that the element is an image, and they will read the alternate text description that you’ve provided for that image.

Scaling Images in the Browser

There’s another helpful property of the <img> tag that our simple approach doesn’t support: automatic sizing and scaling by the browser. With a standard <img>, we can simply set the width as a percentage of the containing element and the browser automatically calculates the width and scales the height proportionally. For example, consider the fragment below displaying the image file image.jpg which has natural dimensions of 600 × 300 pixels.

<div style="width: 400px">
	<img src="image.jpg">
</div>

The browser automatically fits the image into the containing <div>, reducing its width from 600 to 400 pixels. It also preserves the image’s aspect ratio, scaling the image height from 300 to 200 pixels at the same time. The result is an undistorted image that fits perfectly on the page.

Thanks to an approach first described by Grady Kuhnline, we can achieve the same effect with a CSS background image for modern browsers. (Warning: The approach this subsection describes does not work in Internet Explorer version 8 and below, as those browsers don’t support the necessary CSS properties.)

The easiest part to tackle is scaling the width. As with the <img> tag we can set our element within a <div> of fixed width; we just have to explicitly indicate that the background should fill that <div>. The HTML markup doesn’t look very different.

<div style="width: 400px">
	<span id="image"></span>
</div>

We have to combine several CSS properties to set the width; let’s take them one at a time:

  1. Set the display property of the #image element to inline-block. Without this property, CSS will display the <span> element as inline and we won’t be able to give it a width or (in a minute) a height.
  2. Set the width of that element to 100% so that our image fills the containing <div>.
  3. Set the font-size and line-height properties to 0 so that any contents within the span don’t factor into its size.
  4. Set the vertical-align property to middle to vertically center the image element in the containing <div>.
  5. Set the background-size property to 100% so our image fills the image element.
  6. Set the background-position property to 50% 50% to align the background image within the image element.
  7. Set the background-repeat property to no-repeat to prevent the browser from tiling the image horizontally or vertically.

The resulting CSS sets the styles for the image element (the <span> element with an id of "image").

#image {
	display: inline-block;
	width: 100%;
	font-size: 0;
	line-height: 0;
	vertical-align: middle;
	background-size: 100%;
	background-position: 50% 50%;
	background-repeat: no-repeat;
	background-image: url(image.jpg); 
}

Those steps take care of giving the image a width, but we haven’t yet tackled the height. Nothing in the above markup or styles tells the browser the height of the image element. As a result, it will default to its natural height which is, alas, zero, as there is no actual content in the <span>. Fortunately, we can fix that with a few minor additions.

First we need to add an extra <span> element to our markup. This extra element is placed within the image element.

<div style="width: 400px">
	<span id="image">
		<span id="image-inner">
		</span>
	</span>
</div>

Now we define a few style properties for this inner <span>.

  1. Set its display property to block so it will have a height and width.
  2. Set its height to 0 since it doesn’t have any actual content.
  3. Add a padding-top property specifying a percentage equal to the height-to-width ratio of the image.

That last step is the key. Even though the <span> inherits no height from its content, padding-top forces the element to take up vertical space. Furthermore, the padding-top property accepts percentage values where the percentage is relative to the element’s width. Our image is 970 × 614 pixels, so the percentage value we use is (614 ÷ 970) × 100%, or 63.3%. Now the browser will ensure that our image maintains its aspect ratio as it’s scaled up or down.

#image-inner {
	display: block;
	height: 0;
	padding-top: 63.3%;
}

All Together Now

To see how all these components fit together, here is the code for the contfont.net website we’ve used as an example. First is the HTML markup that includes the main website image.

<div class="hero">
	<span id="cafe" role="img" aria-label="Coffee and croissant.">
		<span class="inner">
		</span>
	</span>
</div>

The style sheet defines properties that make the image scale proportionally.

.hero #cafe {
	width: 100%;
	display: inline-block;
	vertical-align: middle;
	font: 0/0 serif;
	text-shadow: none;
	color: transparent;
	background-size: 100%;
	background-position: 50% 50%;
	background-repeat: no-repeat;
}
.hero #cafe .inner {
	padding-top: 63.35%; /* height/width of image */
	display: block;
	height: 0;
}

And finally, a set of media queries pick the appropriate image file based on the user’s context. (The example below omits vendor prefixes for brevity.)

/* default screen, non-retina */
.hero #cafe { background-image: url("../img/candc970.jpg"); }

@media only screen and (max-width: 320px) {
    /* Small screen, non-retina */
    .hero #cafe { background-image: url("../img/candc290.jpg"); }
}
@media
only screen and (min-resolution: 2dppx) and (max-width: 320px) {
    /* Small screen, retina */
    .hero #cafe { background-image: url("../img/candc290@2x.jpg"); }
}
@media only screen and (min-width: 321px) and (max-width: 538px) {
    /* Medium screen, non-retina */
    .hero #cafe { background-image: url("../img/candc538.jpg"); }
}
@media
only screen and (min-resolution: 2dppx) and (min-width: 321px) and (max-width: 538px) {
    /* Medium screen, retina */
    .hero #cafe { background-image: url("../img/candc538@2x.jpg"); }
}
@media
only screen and (min-resolution: 2dppx) and (min-width: 539px) {
    /* Large screen, retina */
    .hero #cafe { background-image: url("../img/candc970@2x.jpg"); }
}

Potential Problems

CSS background images are a convenient way to deliver responsive images today, but the approach isn’t perfect. At a basic level, it violates one of the fundamental philosophies of modern Web standards — separating content from presentation. Advanced versions of the approach also suffer from browser compatibility concerns, and the approach doesn’t address some of the deeper problems with responsive images in general.

Separation of Style and Content

CSS was developed specifically to separate style from content. On the modern web, HTML pages provide all of a website’s content, while style sheets only affect the presentation of that content. Style sheets should not define the content itself. Of course, the separation between style and content has already been breached somewhat with the CSS content-before and content-after properties, but those properties are typically used to enhance the presentation (for example, by adding an icon to an element).

Specifying primary website images with CSS is a different level entirely. By specifying primary content with CSS rather than HTML, we make our websites harder to troubleshoot, we make them more difficult to maintain and we create barriers for systems that might try to parse our websites automatically.

Unfortunately, there really is no getting around this problem. If strict separation of style and content is important to you, then you’ll have to consider alternative approaches for responsive images.

Browser Support for Scaled Images

As noted above, the enhancements we added to the basic approach for scaled images won’t work in Internet Explorer version 8 and below. Standardized approaches such as srcset may be backwards compatible with such browsers, but, of course, srcset itself isn’t available on any mainstream browser today.

If you need to support IE8 right now, you might consider creating a separate style sheet for IE8 that specifies fixed image sizes rather than scaling the images. Of course you’ll want to include that style sheet within an IE conditional comment so that other browsers won’t see it.

The Real Problem of User Context

Perhaps the most fundamental problem with this approach is a problem with responsive images in general. We’re using screen width and pixel density to determine user context, but it’s not clear that such an approach is always appropriate. Consider, for example, a notebook user accessing the Web via a smartphone’s Wi-Fi hotspot.

Accessing the Web via a smartphone’s Wi-Fi hotspot.

That user’s Web browser will show all the characteristics of a high-density, wide-screen device, and a responsive website will delivery large, high-resolution images. Anything less will look poor on our user’s display, but these images may take a long time to load over a wireless network. They could significantly increase the website’s load time, and they may ultimately cost our user real money on their wireless bill. Given the choice, they might prefer lower resolution imagery.

It turns out that this problem is a really hard one to solve. Smart people in the Web community are definitely discussing it, but so far there has been little consensus on an practical solution. For now, CSS-based context discovery is the best technique available.

Acknowledgements

A special thanks to Grady Kuhnline for first describing how to style images that can scale proportionally. Also, the contfont.net website that this article uses as an example is available for reference on github.

(cp)

↑ Back to top

Stephen Thomas is a Front End Developer at The Georgia Institute of Technology with experience in all aspects of modern Web design and development with a special focus on data visualization. He writes at http://sathomas.me/blog, and his talks may be found at https://speakerdeck.com/sathomas. Find out more on GitHub.

  1. 1

    In April 2012, I wrote a solution for using background images on img tags, to get the benefits that real images provide with the benefits that background images provide for responsive design. You should check it out: http://mattstow.com/responsive-and-retina-content-images-redux.html

    2
    • 2

      Using background images as a content replacement is a “no go”. Web content must be semantic. Abusing decoration and formatting (CSS) to simulate content (HTML) is a bad foul. Developers who are using such solutions do not understand the fundamental basics of modern web-development.

      9
  2. 5

    Great article in general, but I do have reservations about your last statement of user context. While for some users it might be true that serving the full-sized website when they are tethering, might not be good (esp if you have bandwidth caps), this is certainly not always the case, especially as the amount of data we consume grows, networks speeds grow, and networks realize that limitations to bandwidth are a bad business model, this will become irrelevant.

    0
    • 6

      Chris Burbridge

      July 23, 2013 4:32 pm

      Well, but that could probably be said about bandwidth considerations for mobile–someday, it may not be an issue. Yet, it is now, and we must respond to the situation, now.

      For the same reason, I think it’s rather clever to point out that it would be nice not to assume what a user, such as a desktop user, might want. It would not be hard for browsers to set bandwidth preferences, for instance, that could be standardized, and read by servers.

      -2
  3. 7

    Anthony Garritano

    July 22, 2013 4:38 am

    I respect the amount of effort that went into this, and until we have something more native to use in the browser this is a good work around.

    Also, I think it’s important all ideas be discussed, even the ones that have potentially harsh drawbacks as it starts conversations that lead to even greater solutions.

    That being said, I can’t sit idle, I have to comment on the major issue this solution brings.

    What I can’t escape is the fact that this solution breaks the very purpose of the web: access to content. This strips away access to people who aren’t able to visually see the images. I’m not just talking about people with vision impairment; anyone that can’t download the images has no other indicator of what the content is.

    This solution also undermines the work of folks who have worked really hard to get web workers to a place of understanding that it is content that has value, otherwise everything we do as designers is just decoration.

    This type of solution is really not an option for me, and I have to strongly recommend others to avoid using it.

    9
  4. 8

    Gonzo the Great

    July 22, 2013 4:56 am

    Hi Stephen,

    I wrote an article about responsive background-images a half year ago, used image compression to make the file size as small as possible -> without any JS!

    In this experiment I serve another background-image per media-query:
    http://www.gonzoblog.nl/2012/12/24/wishing-you-a-responsive-and-retina-friendly-xmas/

    3
  5. 9

    img-tags support backgrounds as well, but I don’t think there is a way to remove the actual img-source with CSS. That way you could use the properly semantic img-tag instead of div’s with background images.

    3
    • 10

      Technically see you could create a 1px image which is transparent. But such a hack will not remove the SEO issues and other concerns regarding breaking web-standards.

      0
  6. 11

    John Flickinger

    July 22, 2013 8:36 am

    When setting the images so the width is 100% so they scale it’s also useful to set the height to “auto” if you’re making the site for a large audience that still has IE7 and IE8 users. Even if you aren’t it’s nice to define both the width and the height even though the auto value is default.

    -1
  7. 12

    Jason Featheringham

    July 22, 2013 9:14 pm

    What a horribly non-semantic, SEO-unfriendly and inaccessible idea. I’m thoroughly surprised Smashing Magazine signed off on this.

    23
    • 13

      Have to agree with Jason – completely the wrong way to use background images.

      By using this method you are not making it accessible to everyone – something we aim for in every new build.

      Surprised at this recommendation from Smashing Magazine

      5
    • 14

      I’m not positive that SEO-unfriendly and inaccessible are accurate statements. The ARIA label and the ARIA role have to account for something. Non-semantic is probably a valid criticism. However, HTML5 and ARIA are designed to allow for more novel use cases, such as allowing JavaScript-less responsive images that avoid double-download issues. Admittedly, it’s a huge hack.

      -1
    • 15

      The solution is very good for some cases when you want responsive backgrounds or images that are related to the design or presentation.

      besides there is many different types of websites and not all of them needs to be SEO friendly or highly accessible to old browsers, on these cases this solution maybe is very useful.

      Thanks Stephen for the nice article

      0
  8. 16

    This proposal is a SEO disaster and ignores all efforts to create a standard-conform, semantic web. I am shocked that such a nonsense gets published in the Smashing Magazine. If we are looking to such “hacks” then they must make sense and not interfere negatively with web-standards. Take a look to this much, much better solution: http://litesite.org/holygrail/stage2/

    -4
    • 17

      Hi Harald,

      Thank you for sharing your solution with us! Please keep in mind that the solution presented within this article is not to be seen as our personal recommendation, but rather as an approach which the author had developed from his very own workflow and personal experience. It is important for us to provide the community with a platform where everyone can exchange their various workflows and solutions… Hope that makes sense. ;)

      3
      • 18

        Jason Featheringham

        July 23, 2013 1:16 pm

        It would make sense if it fell under current best-practice guidelines. I would expect Smashing Magazine to review and reject an article promoting table layouts. As such, I would also expect the same level of filter regarding accessibility and other implications by this example.

        Just because something is a hot topic does not mean we should throw current concerns to the wind just to accommodate.

        0
  9. 19

    Be careful, some browsers download both pictures if serving one with default & one with media query.

    You really want to have a look at the tests at http://timkadlec.com/2012/04/media-query-asset-downloading-results/

    0
  10. 20

    Great article! Nice solution BUT…

    I feel that we live in 2013 and still re-inventing the wheel with all this new HTML5/CSS3/RWD stuff. You have 54 rows of CSS for a single image!

    Imagine in a more complex site with user uploaded images.

    5
    • 21

      Much of the CSS can be reused for other images that need the same treatment. You’d only have to count the lines of JavaScript proposed in other solutions to realize the the amount of CSS isn’t the real problem here. Additionally, this technique has some real upsides for integrating with a CMS or in a scenario like the user uploaded content you mention. The CSS needed for a specific image (versus the initial CSS needed to make the technique possible) is pretty small. A width. A percentage for padding. Some media queries to switch the background. That’s not going to be much more verbose than the element techniques.

      Imagining a more complex scenario doesn’t make this technique less compelling. But, some of the arguments about how this seems a little hacky definitely hold water. Mostly because it IS totally hacky.

      My original article was written before clowncar came out. And clowncar is basically this exact technique but wedged into an SVG document (making it less hacky, more sexy).

      0
  11. 22

    The web’s filled with interim solutions patiently waiting for a “standard” to arise. I think what this article does nicely is demonstrate that it can be done and is. It’s just not as pretty or pleasant as most would like it to be.
    Thanks for outlining the important bits when using this approach.

    5
  12. 23

    I agree with a lot of the folks here. This just doesn’t seem like a viable solution for developers that care about semantic and accessible markup. I can understand adding an empty element every now and then for an icon or subtle detail, but adding a span tag with top padding just to create height for an image seems hacky.

    Kudos on writing a detailed explanation. I’m optimistic that one day we’ll find a solution that everyone can agree with!

    1
  13. 24

    “Smartphone browsers will download the large image even though it’s never displayed.”

    That means smartphone browsers need to get smarter.

    1
  14. 25

    Assuming you can fix the accessibility problem using Aria as shown in the article, and fix SEO using “Image Sitemaps”, does anyone see another drawback in this approach?

    I like it a lot. Of course it would be better to have srcset now, but a CSS background is an easy, fast and portable solution. I know a div hasn’t the same semantic than a img, but are there *practical* drawbacks to this? Accessibility and SEO are fixable…

    -1
  15. 26

    Why do we keep trying to solve this problem in the WRONG PLACE? We want an image to be delivered from the server based on the context of the image. We should have server-side X-Media header string being offered by the user-agent and let the server decide what to serve up. This has the advantage of letting the markup be simple and letting the standard content-negotiation logic to kick in. I (and others) suggested this back in February, 2012.

    http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/#comment-874755

    After all, Cool URIs Don’t Change

    1
  16. 27

    This is a nice technique, but am I the only confused about how this would actually be used in practice specifically with a CMS?

    Seeing that the vast majority of sites are utilizing some type of CMS these days, I think quite a bit more work would be required than just the code you have above. I think a heavy bit of JavaScript would be required to inject the url’s in to the appropriate styles.

    1
    • 28

      Actually I recently used a very similiar approach on a WordPress website, which features around 100 posts each one showing an image. Ok I have to admit I used some inline styles but otherwise it works perfectly.

      I used only one div and set the aspect ratio on it, then I inserted the image urls into the corresponding media queries as background-images and set background-size: 100% auto.

      For retina I only used the following media queries:
      http://css-tricks.com/snippets/css/retina-display-media-query/

      To support IE I used this filter property after the normal css inside a conditional comment and set background: none:
      http://msdn.microsoft.com/en-us/library/ms532920%28v=vs.85%29.aspx

      The content of the image is heavily described in the text content anyway so I think SEO-wise this should work out.

      I guess it’s definitely not a best practice but until there is a better semantic cross browser solution I’m happy with this one.

      Frank

      0
  17. 29

    Very good article about the responsive websites, explanation with examples how the images act in RWD.

    vara –

    0
  18. 30

    Good article, that makes sense.
    I’d like to suggest people interested in using this solution store only the largest image on their computer, then use PHP or Node.js to serve up a custom-sized version of the image.
    Though this uses processing power, I think most will agree that keeping multiple different sizes of all your images is difficult to maintain.

    0
  19. 31

    I like the technique, SEO or not ARIA or even a simple Title tag put on the Div or other element tag would be a great solution.

    I do have to agree with Mike about a CMS solution being an issue. Especially with a CMS that dynamically generates the images paths when they are uploaded through the CMS.
    There may be plugins, etc that may help get around this, but I have not seen anything out of the box in most cases. Inline CSS may be an solution in that case as Frank brought up.
    Srcsets may be nice, but I don’t see that being used much because of the inherit need to to support older browsers in most professions who deal with school districts and business who are reluctant or can’t upgrade their huge vast computer networks in on foul swoop.
    Javascript is a possibility to switch the SRC, especially if there is an image source in the first place on the IMG tag, that would work fine for accessibility since the SRC is there in the HTML.
    Serverside solutions are nice, but not everyone has the know how or the cash to hire a back end developer to write PHP, .Net, Ruby, etc code on their server to handle the SRC issues.
    1 Image and forget it is still one way to go, although it does slow the pages a bit of course, but like Daniel mentioned, the shear time consuming process of managing multiple images at varying sizes per image needed is not for me.
    It just seems like so much work right now to write so much extra server side, and maintain so many extra images is kind of a pain at this point.
    Until technology, internet speeds and processor speeds keep up with our wants, I am a little reluctant to keep changing the way I do things everytime some new idea comes out.
    Like I said, I do like the background image solution, but for a CMS solution, this may not be the best way to do this.

    0
  20. 32

    It’s a great solution, I’ll totally keep that in mind!
    I hate to have to create responsible designs… I think is a huge back to the 90s when I had to write html to netscape and internet explorer! And, in the end, I don’t know a single person that, in real life, does not click on “view desktop version” in their mobile screens!

    0
  21. 34

    What’s the point of using a fixed with div for a responsive background image implementation? You lost me there.

    0
  22. 35

    How to insert content in there with that padding-top hack is the question…

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top