Skip to main content

Responsive IMGs: Choosing between semantic markup and working code

By Jason Grigsby

Published on October 23rd, 2011


I asked recently what responsive IMG technique we should teach in our book? Unsurprisingly, there wasn’t a clear winner in the comments.

After agonizing over this for a couple of weeks, I’m leaning towards using the noscript technique as the primary example in the chapter with additional information on where to find the other approaches.

I’m towards this approach despite the fact that Scott Jehl, Ethan Marcotte and Brad Frost all feel that the noscript technique isn’t future friendly. So as you can imagine, I’m terrified that I’m making a big mistake. 🙂

As I understand it, the argument against noscript as a technique is that it isn’t semantic markup. The attributes for the eventual img tag are put on the noscript tag which isn’t where they belong. Attributes for images belong on the img tag.

I’m probably butchering the arguments against noscript which is why I’m writing this post in hopes of understanding it better before it is too late for the book.

Here are the reasons why I’m leaning towards using the noscript technique in the book:

  • We need to use one technique to build a web page in the chapter.
    A few people suggested talking about a few different techniques and their relative merits instead of teaching one technique. That might work in a different kind of book, but won’t cut it for a Heads First book. Every chapter is structured to include a real project, exercises and working code.

    We can talk about how all of this is very new, but at some point we need to show how to the handle images on the web page that the learner is building in the chapter.

    It is easiest to think of the chapters as stories. We have a protagonist (the learner) and a journey they are on. Teaching multiple techniques would be choosing one path for the story, go down that path, and then suddenly say, “Alright, now let’s go back to where we started and go down that other path.” It wouldn’t work.

  • I want to avoid server-side resizing of images.
    I know server resizing of images is probably a core part of a long term solution, but I need to teach the challenges of determining the size of the screen and picking the appropriate image. How do you tell the browser what image to download? After we’ve taught the challenges, then we can talk about server-side resizing. Otherwise, it seems like there is a magical black box taking care of things for us.

  • I can’t guarantee that the other techniques will work.
    Every other client-side technique relies on assumptions about the order in which browsers will load assets. We’ve already discarded dynamic base tags because the browser behavior changed and images were getting loaded twice. Yoav Weiss has done some tests on preloaders and cookies showing that images sometimes get downloaded before the cookie is set. This will result in multiple image downloads.

  • We don’t have a wide deployment of any of these techniques.
    The Boston Globe’s images haven’t been fixed yet. Our book deadline looms. Whatever we choose is going to be unproven.

  • I can explain why noscript works. Yes, the noscript solution is easier to implement because it doesn’t require Apache rewrite rules and cookies, but that alone wouldn’t be enough to cause me to shy away from it. We’re teaching WURFL in the book so we’re not shying away from teaching complex things.

    When I say I can explain how noscript works, I mean I can explain clearly why images don’t get downloaded. The browser knows before the page loads whether or not javascript is available. If it is available, the img inside the noscript tag won’t get loaded. This behavior is easy to understand and reliable. It has worked this way since the noscript tag was created.
    After all of this research, I still don’t have a clear explanation of the preloading behavior of browsers. Without doing extensive testing or reviewing the loading code for every browser, I don’t think we’re ever really going to understand how it works nor be confident it won’t change in the future.

  • Elegance of a wading hippo notwithstanding, noscript works.
    As far as I can tell, it works 100% of the time. I’ve been trying to think of conditions in which it wouldn’t work and haven’t come up with any.

  • Tyler Sticka would teach noscript.
    In addition to being a fabulous web designer, Tyler teaches a college course on web design and development. I had the opportunity to speak to his students last year. When I think about whom we’re writing this book for, I think about people like Tyler’s students. Because of that, Tyler’s endorsement means a lot to me.

To summarize, it feels like I have to choose between semantic purity and something that works reliably. Because the focus of the book is on the practical, not the theoritical, I think we have to choose the solution that works while pointing out the problems with it. We’re absolutely going to talk about how this is the bleeding edge.

Back in 1995 when David Siegel was writing Creating Killer Websites, it is unlikely that he could anticipate the impact his book had on web development. Similarly, I can’t know what impact our book will have.

While it may be illusions of grandeur to think it matters much which technique we pick in our book, I do feel a great responsibility to avoid doing harm. I don’t want to find myself in Siegel’s shoes five years from now writing a mea culpa about how The Web is Ruined and I Ruined it.

Hence this post. One last chance to hear arguments for why we shouldn’t teach the noscript tag and what we should teach instead.

And if you’re reading this five years from now and the web is in fact ruined: I’m sorry. I did my best.


Tyler Sticka said:

I’m flattered to be included in that list!

I completely understand where Scott, Ethan and Brad are coming from, and I don’t disagree. I do not believe that a designer’s bag of responsive IMG tricks should end with this technique. That said, I think it makes a fine beginning!

When I teach, I try to establish a foundation of understanding before diving into “best practice” techniques. For example, it’s not important for JavaScript students to understand frameworks, MVC and object-oriented programming until they know how variables, operators, conditions, loops and functions work.

The problem with the spacer GIF and table-based layouts (one of the problems, anyway) was that they reinforced a method of defining presentation that did not provide a foundation of understanding that CSS could subsequently build upon. I don’t believe the same is true for the noscript technique.

The industry’s responsive IMG discussion is murky, fast-paced and ongoing. It would be incredibly difficult to write a “best practices” tutorial today, and even if you did, it would likely be outdated within months of publication. If your goal is to write the “last word” in responsive IMGs, I applaud and envy your ambition and optimism. But if your goal is to introduce designers and developers to this new way of thinking with an easy-to-understand, practical and un-harmful first technique, I stand by my recommendation.

“That’s good. You have taken your first step into a larger world.” – Obi-Wan Kenobi

dylan said:

One aspect I don’t see discussed much is how responsive image techniques impact search indexing. Any ideas for developer who wants the full-size images to be accessible to crawlers? For example, this would be valuable to a site that gets a lot of traffic from Google image search.

Steve Souders said:

The major downside of the noscript technique is that the images start loading much later – this causes delayed rendering and likely will cause multiple reflows.

In the description of the noscript technique you say “Because of the need to execute as quickly as possible, it makes sense to remove the jQuery dependency from Antti’s javascript and put the code in the head of the document.” The problem is if the code is executed in the head it won’t find any of the NOSCRIPT tags (because the body has yet to be parsed).

Perhaps you meant to put that code in the head inside a handler for onload or domcontentloaded. This means that none of the image requests event *start* until that event fires, whereas in normal page parsing the image requests would generally start at the point the IMG tag was parsed.

Under this scenario the body’s DOM is all parsed and rendered while the browser waits for image responses. Note that the technique does *not* provide a way to specify the image width & height (for all image sizes). This means that when the image response is received the elements will shift.

Perhaps I’m missing something? Otherwise, the delayed rendering, slower page load time, reflows, and page flashes make this a very undesirable technique.

Jason Grigsby (Article Author ) said:

@Steve, I don’t think you’re missing anything. Thanks for pointing some of the rendering issues that I hadn’t considered.

We’re going to go with SRC for this chapter. I’ll write more a follow up post on why soon.

Kevin Hakanson said:

I know there has been a follow up post to this, and I’m am late to this discussion but the NOSCRIPT technique reminded me of the Lazy Load Plugin for jQuery (

In that case, it “delays loading of images in (long) web pages. Images outside of viewport (visible part of web page) won’t be loaded before user scrolls to them.” There the delay was a benefit because the browser never downloaded images it didn’t need to display. However, it required javascript and a img tag with a custom placeholder attribute, so included some of same downsides.

I think the perfect responsive image solution would incorporate lazy load as well. Thanks for posting the research.