Skip to main content

Device detection as the future friendly img option

By Jason Grigsby

Published on October 31st, 2011


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 SRC (aka TinySRC) in the book. Much to my surprise, it seems like the most future friendly option.

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.

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:

  1. 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.
  2. 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.
  3. 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 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.


James Pearce said:

Flattered, but I like the logic.

I also agree with the fact that one of the tinySrc benefits is that it’s easy to swap out. If future friendly means low infrastructural commitment, then that’s fine with me 😉

PS also this is my obligatory first!!1! to make sure I can subscribe to the comments.

Bryan Rieger said:

Completely agree with James and Ronan. Great to hear you’ve decided to proceed in this manner.

BTW am I the only one finding it more than a little ironic that we’re having to resort to a ‘least-offensive’ server-side technique for image adaptation, while the folks at the WHAT-WG argue whether or not to drop from HTML5… after all, it’s not like the poorly designed (which is WAY more important) could use a little attention in HTML5?! :/

Ethan said:

As someone who is, probably unsurprisingly, not a fan of device detection, I’d agree the primary benefit to something like is its high degree of “unpluggability.” (I should probably put coffee in my face before trying to type words.)

For what it’s worth, some of the race conditions[1] Yoav so ably covered are, a relatively new issue. I’d personally love to see more standardization on browsers’ preload behavior.


Kevin Powell said:

Regarding future-friendly, how much of this becomes a non-issue as bandwidth increases worldwide? At what point does downloading a 500k image become trivial, regardless of device?

I’m definitely loving the the pragmatic approach of server side responsive design for its performance gains, though I do lament the loss of the magical morphing website as I resize my browser window.

Martin Sutherland said:

“I do have some concerns about teaching something that relies on a third-party like 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.”

I’d be much happier if there were multiple providers out there using a compatible API. I’m sure that James’ and Sencha’s intentions are pure, but accidents happen, companies get bought, and minds get changed all the time — Mark Pilgrim killing (et al.) is still fresh in my memory. Advocating a single-vendor third-party solution as best (or even just “good”) practice for something like this is troubling.

On the other hand, getting one’s JavaScript and CSS from a CDN is highly recommended and widely used performance optimization. :-/

The tools for an image proxy could be replicated by an open-source project, but the real commercial value of SRC lies in the device database, which is much harder to reconstruct, verify, and keep up-to-date. In the long term, *that* is the hardest part of the problem, I think.

James Abley said:

It sometimes seems to me that there’s a big disconnect between the people that have been doing this stuff for years (my tribe) and (high profile) people that are writing / blogging / speaking about it now. Where I used to work; we had lively debate, inventive solutions, etc. All siloed off from the internet. That’s bad.

That could probably do with fixing, and in the process hopefully help others. I’d like to offer to email / review your book as a way to try to address that, if you think that might be useful.

It also pains me that I accepted this option as the least bad (in the New Jersey sense) some (6?) years ago, and state of the art still hasn’t moved on.

Yoav Weiss said:

I completely agree with your reasoning as server side device detection being the least bad of all current solutions, but we must remember that it comes with a performance price. Using a single URL for different image dimensions means that the images are practically non cacheable by intermediary caches (or risk returning the wrong image to some devices). IMO it needs to be pointed out…

Brett Jankord said:

I like SRC, it’s truly a brilliant service.
I think AI is just as equally appealing for its simplicity and would be a shame not to mention it in the book.

Looking at the responsive images spreadsheet you created I noticed for adaptive images you have listed that the desktop image will display if cookies are disabled and likewise for js. I believe Matt has a setting where you can choose to send the mobile or the desktop image if cookies are disabled. Also, it looks like Matt has worked on the proxy caching issue, “Adaptive Images 1.3.3 was just released and solves the issue of proxy caches in the only way that will work: proxies are now told not to cache the images, but browsers do.”

Bottom line, I would still give a nod to Adaptive Images in the book –

Looking forward to reading it.

Jason Grigsby (Article Author ) said:

Haven’t had a chance to reply in a while. Sorry about that. Thanks for all of the comments.

@Kevin Powell: I don’t see performance not being an issue any time soon. I think it was an issue on desktop that most web developers chose to turn a blind eye to because they personally had high speed connections. But regardless, addressing these issues doesn’t mean giving up scaling on the desktop size. Desktop would still get the largest image and rely on fluid images.

@Martin Sutherland: You are absolutely correct that the biggest issue is the device database. That is something I want to blog about separately sometime soon.

@James Abley: I share your frustration that the lessons of mobile web development have been forgotten. It is something I talked about at the Breaking Development conference. Would love to see more blogging and writing from the group you used to work with. A lot of the mobile web discussion happened in obscure places (WML programming list, Forum Oxford–come on, who’s going to know to look in those places).

Regarding the book, I appreciate the offer, but we’re at the crunch time right now and adding an additional reviewer at this point would add too much to the insanity. 🙂

@Daniel Sellers, early versions of Scott Jehl’s responsive images technique relied on a transparent gif download like you propose before moving away from them. It is also very similar to Harry Roberts proposal here:

I think solutions that rely on CSS changes for every image work on small sites, but breakdown on large sites. I have trouble imagining what NPR or CNN might look like if every image was in CSS and how often the CSS file would need to be revved.

@Brett Jankord, I don’t disagree that Adapative Images is a good solution. Matt also commented earlier that you can default to small images.

For the book, we have to explain how something works. Explaining why the JS gets executed, when it might not, and banking on it working in the future when the browsers haven’t committed to loading assets the same way in the future is the part that becomes problematic.

We’ve gone with SRC in the book and are linking to part 2 of this series with the review of all the different techniques for those who want more. If something comes down the pipe that is a better solutions, we’ll address it in the errata or the second edition (should we be so lucky).

karl said:

User agent sniffing will always fail in the future. It is just a question of time. This is not future friendly. My entire day is spent on such issues 😉 of sites breaking because the device list is not updated, abandoned or simply the device was not included.

The device detection also doesn’t cope with the network bandwidth capabilities, and that is another important parameter. Being on a high bandwidth wifi with a mobile device is very different than being on on 3G network.

Device and Network capabilities are the future friendly answers.

The Device API Working Group [1] is working on a lot of these specifications. For example, there is a network Information API.