Device detection as the future friendly img option
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.
Jason Grigsby is one of the co-founders of Cloud Four, Mobile Portland and Responsive Field Day. He is the author of Progressive Web Apps from A Book Apart. Follow him at @grigs.
