Responsive IMGs: Choosing between semantic markup and working code

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.