Last week I wrote about why I was considering teaching the noscript technique in our book and asked for someone to talk me out of it before I committed what I feared would be a long-lasting crime against web development.
The post worked. I got some great feedback, and I’ve decided against using noscript in the book.
Instead, I’m going to use Sencha.io SRC (aka TinySRC) in the book. Much to my surprise, it seems like the most future friendly option.
The problem with the noscript version
Sometimes I need something explained to me multiple times before I get it. Understanding why using noscript was a problem for semantic markup was one of those times.
Fortunately, Stephen Hay got through my thick skull with this paragraph from an email he sent:
Noscript means we get an empty arbitrary container element and a noscript element in our HTML, which is meaningful only within the context of this particular solution. Other methods, take Scott Jehl’s
data-attr method as an example, at least begin with an image element. This, in contrast to the noscript technique, is meaningful in *any context in which HTML can be understood*, whether by machines or by people.
Brad Frost and Bryan Rieger also provided helpful feedback that reinforced Stephen’s point and jarred me back to my senses. And Steve Souders pointed out a bunch of performance issues I hadn’t fully considered.
Device detection as the most future friendly option
In a follow up email, Stephen laid out a line of logic that made choosing to teach TinySRC a no brainer. I will attempt to paraphrase it here.
While there are many responsive imgs techniques, they primarily fall into three main approaches:
- Client side solutions that rely on cookies and browser parsing order. — These solutions can be done with semantic markup, but they rely on current browser behavior. Yoav Weiss has done some tests on preloaders and cookies showing that images sometimes get downloaded before the cookie is set. Because this is based on the current way browsers parse documents and not a standard, it could break at any time.
- Noscript techniques. — Works reliably, but is an obvious hack (and a brilliant one). Not sustainable because the markup of the page no longer contains the full meaning that it once had.
- Images being handled by device detection. — Device detection uses the user agent string to make decisions. I’ve been referring to device detection as the third-rail of web development. Like politics and religion, device detection is a topic you want to avoid if you want to have pleasant conversations. But a lot of people use TinySRC without incident.
For the book, we need to pick something that will stand the test of time. That’s what makes me nervous about option 1. Who knows when it will suddenly stop working (if it hasn’t already given Yoav’s tests).
Between options 2 and 3, we have a hack that requires us to change our markup in a solution-dependent way (noscript) and a solution that relies on the very thing most web developers have come to despise (user agent based detection). Here I must quote Stephen again because he says it so well:
When you asked about future-friendliness, I tried to think ahead to the future and imagine what the state of these documents might be. My stance is that when we no longer need device detection, we simply remove it. All of our files are intact, as they have been left alone. Our markup is still meaningful. The content is still properly structured. Not so with the noscript hack, which requires us to revert to the markup we could have had in the first place. The choice—for me at least—was clear: device detection is a pluggable solution, which can be “unplugged” once a better solution comes along.
The idea that something like TinySRC is a pluggable solution which can be unplugged is incredibly compelling. We don’t have a fantastic, client-side only solution. Or at least, we don’t have one that I feel confident enough in to include in a book and not fear that it will look foolish six months from now.
Plus, Stephen is not a fan of device detection. He isn’t simply falling back to what he is comfortable with. If anything, it is the opposite of what he would prefer to do.
I do have some concerns about teaching something that relies on a third-party like Sencha.io SRC, but I feel James Pearce will keep it running through sheer force of will if nothing else. And if it does go away, the book does teach device detection fundamentals which would give someone the basic tools they need to create their own image service.
How strange it is to think of device detection as the most future friendly of the three options? I find it hard to argue with the logic.
At least that’s how I see it for the book. For your project and use case, it depends.
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.
Why teach the noscript technique
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.
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.
Avoiding a spacer gif mistake
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.
Alright, I’ve written extensively on the challenges with the IMG tag for mobile first responsive web designs. What other challenges are people running into?
Here’s what I’ve seen:
- Video (especially embedding third-party video) — Looks like Fitvids.js is the solution a lot of people are using. See also Elastic Video. BTW, if you’re doing a lot of video, it is probably a good idea to look into how you can use HTTP Adaptive bitrate streaming to send different quality video based on data connection and CPU.
- Data tables — Chris Coyier’s excellent Responsive Data Tables article explains three different possibilities for solving this.
- Third-party ad networks and social widgets — This is biggest problem. It’s a problem whether you’re doing responsive design or not. Scott Jehl talks a little about how they handled ads on the Boston Globe in his presentation from the Breaking Development Conference (pg 97).
What am I missing? What other challenges do you see?
All this time you thought I was writing novels about responsive IMGs for altruistic purposes, but I had an ulterior motive. We need help with our book.
One chapter of the book is called Mobile First Responsive Web Design. We intend to teach people how to start with a mobile version of their site and progressively enhance it to a desktop view. Part of doing that is handling the IMG tag.
So here’s my question for you. If you had to select one of the responsive IMGs techniques, which one would you choose?
Some things to keep in mind:
- The Head First book series is designed for learners. It is used in many classrooms. Therefore, we can’t get into the detail I went into in my posts. We need something representative that teaches the core issues and provides a decent, if flawed, solution.
- Because book is for learners, we want to keep things simple if possible.
- We need to chose one technique to teach them in detail. We can talk about other techniques in passing, but when we give the learner exercises to do, they will be based on one approach.
For your reference:
Thanks for your help. I’m anxious to see what you think. Please show your work. :-)
The conversation in the comments on part 1 and 2 of this Responsive IMGs series have been exceptional. If you read the articles, but didn’t read the comments, I encourage you to go read them. There are people much smarter than me in those comment threads.
One of common conclusion from the commenters is that our current IMG tag isn’t going to cut it. That we need some sort of replacement that is future friendly. This isn’t the first time the idea of expanding or replacing the IMG tag has come up.
I promised to collect some of these proposals so we can discuss their relative merits.
Current proposals and discussions to replace or extend the IMG tag
As far as I know, there hasn’t been a formal proposal submitted to any standards bodies, but there have been several conversations worth highlighting. I was going to try to summarize the various proposals, but there hasn’t been a lot of consensus. I’m afraid that to get up to speed, you’re going to have to read the threads.
- Adaptive Images on W3C HTML mailing list
At the end of May, Dom Hazael-Massieux kicked off a lengthy thread talking about Adaptive Images with two ideas: a srclist attribute and new image file format that would be a text file containing a list of images.
The thread continues with many other ideas including new http headers, progressive image formats, and general media formats with queries.
BTW, Adaptive Images has been added as a placeholder on the HTML.next list.
- Discussing Alternatives For Various Sizes Of The Same Image & Introducing src Property In CSS As An Option by Robert Nyman
- Robert asks the question, “whether various sizes of the same image is really content or presentation?” If it is presentation, then it should be in CSS. Again, great discussion in the comments.
- Responsive images using CSS3 by Nicolas Gallagher
- “This method relies on the use of @media queries, CSS3 generated content, and the CSS3 extension to the attr() function.” This means it relies on already existing standards without creating anything new. Unfortunately, it doesn’t prevent multiple images from being downloaded and currently only Opera supports the CSS3 content property. That said, if we could get browser makers to change download behavior, this could work with existing standards.
- My take on adaptive images, Responsive images – hacks won’t cut it, and Simpler responsive images proposal by Yoav Weiss
No one has been blogging more about the need for a better solution than Yoav. His proposals have changed over time. The simpler responsive images proposal is his latest version, but they are all worth reading to see his thoughts and the feedback on each post.
- add html-attribute for “responsive images” on WhatWG mailing list
Anselm Hannemann started a recent thread on the WhatWG mailing list proposing using media- and inline media queries to provide different images. One of the things notable about this thread is that there are some on the list who don’t think the current situation is a problem or if it is a problem, that it is a niché use case. We have some education to do.
- Comments on Responsive IMGs Part 1 and Part 2
It seems weird to link to my own posts, but the comments on each post contain some good suggestion. Scott Jehl said, “It’s unfortunate the comment streams of these images posts are separated. Good stuff going on in both.” I agree. Best I can do is link them up with this post.
What are our goals for a replacement for the IMG tag?
As I read through the conversations about the potential replacements or extensions for the IMG tag, I’m struck by the fact that people seem to all see the same problem, but haven’t yet come up with common criteria that could be used to evaluate different potential solutions. Until that exists, we won’t have consensus.
For example, I would love to have the browser send more data via HTTP headers that would allow us to make determinations on the server about what size image to send. But I don’t think that will work as a replacement for the IMG tag because we need something that will work for HTML widgets where the server isn’t part of the picture.
(Psst… but seriously browser makers, more headers would be great!)
So what should be our criteria. Here is start from my perspective:
- It should be an HTML element and not solely CSS because IMGs are often part of the content. IMGs are semantic.
- The solution should work without server content negotiation so that it can be used for HTML widgets. This doesn’t preclude servers being part of the solution, but we need a solution that will work if servers aren’t in the mix.
- Current caching and proxy strategies cannot be ignored. Because of this, different image sizes likely need to be at unique URLs or the wrong size image for a given user will end up cached at the edge of the network.
- It should support arbitrary image sizes and pixel density.
- It should support art direction decisions to change the image at different sizes.
- It should be a framework that will allow for future expansion based on factors beyond screen size. For example, if the browser provides information about the speed of the network connection, the designer or developer should be able to decide on the most appropriate image. We don’t have to define this now, but we shouldn’t box ourselves in to only looking at screens size.
That’s my start on criteria. What did I get wrong? What would you add? And of the various IMG tag replacements that have been suggested, which do you think holds the most promise?