Skip to main content

Clarification on device detection for images

By Jason Grigsby

Published on November 9th, 2011

Topics

Jeremy Keith has taken issue with my post about using device detection as a future friendly solution for responsive images. I think he missed the point.

The entire post was about what technique to teach in the book we’re writing. A book that has a deadline at the end of the month.

Jeremy writes:

The solution seems clear: we need to standardise on browser download behaviour …which is exactly what the HTML standard is doing (along with standardising error handling).

That would be awesome. Doesn’t help with the book. He continues:

That’s why I was surprised by Jason’s conclusion that device detection is the future-friendly img option.

Two bits of clarification:

  1. The thing that makes it future friendly isn’t the device detection. It is the fact that the markup is unchanged. It buys people time until either browsers standardize download behavior, we have a replacement for the image tag or someone finds a yet undiscovered way to solve this problem. Every other technique requires changes to the markup that are specific to a particular solution and rely on browser behavior that hasn’t been standardized.
  2. Again, my post was in regards to the questions I asked about which technique to teach in the book. I outlined the constraints of the book series and talked about how I entertained the idea of teaching the noscript technique before being talked out of it. Basically, I provided a lot of context for how I was evaluating the techniques for the book.

In addition to standardizing download behavior, Jeremy describes ways that he would like to see device detection improve. All of these are advances we’d welome. They are things that we might even have time to work on once the book is complete. But they aren’t the constraints I outlined in my posts and thus the rebuttal misses the mark.

So yes, device detection, as Jeremy says, is present-friendly way of keeping you from butchering your markup in a way that kinda, sorta works with today’s browsers, but may not work for tomorrow’s browsers.

However, having clean, semantic markup that so you can quickly replace device detection with a better solution in the future is the part that is attractive and arguably more future friendly than picking one of other unproven solutions and littering your markup in the hopes these solutions prove to work in the long run.

With that, I’ll conclude the same way I did my last post:

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.

Comments

karl said:

A book has a lifetime which is long AND it can’t be modified. If you really want to tackle the issue in the book. I would explain one or few techniques in the book. Indicate the one you prefer AND give a pointer to a specific URL on your web site for example or the book Web site where you commit to have updated information about the current techniques.

That would make your book future friendly by creating an indirection. Cool URIs don’t change 😉 even in physical space.

Any kind of hacks on the Web is being solidified by the practice of Web developers.
In return, browser vendors have hard time to evolve the Web platform because of this solidification.

Jason Grigsby (Article Author ) said:

@karl Regarding teaching multiple techniques, this was the most common feedback suggested. I addressed why this won’t work for us in the first bullet point here:
http://www.cloudfour.com/responsive-imgs-choosing-between-semantic-markup-and-working-code/

As for which I prefer, every technique has a deficiencies. If I were to pick one, I would use a combination of server-side detection for first load with client-side detection to inform subsequent loads and to make corrections if the device detection got it wrong. Basically, the way Bryan and Stephanie Rieger address the issue.

But teaching that solution isn’t practical either because it is a complex solution with a lot of pieces that have to be built from scratch.

We do have a link to the second part of the series on responsive images that contain a list of all of the different techniques for those who want to find a different solution.

Brett Jankord said:

@Jason I’ve arrived at the same conclusion as Jeremy about device detection. If you go about it detecting mobile phone user agents, you’ll always be one step behind. New phones come out all the time, and it’s hard to keep a device database up to date with the newest mobile phones.

Yet if you assume the user is on a mobile phone from the get go, and detect PC user agents instead, which are already pretty well established, you have a lot less to detect. I’ve been mulling this idea over the last couple of days and have done some research on varying user agent strings. I’ve also been researching tablet user agent strings and things look promising so far for that, but could end up in the same area as detecting mobile phone UAs if some type of updated standard isn’t put forth for user agent strings.

I need to do some testing on this a bit more, but to me, this idea seems to have some potential. I’m glad I’m not the only one who thinks so.

Jason Grigsby (Article Author ) said:

@brett Flipping device detection around isn’t a bad idea. Again, not possible on the book deadline. 🙂

BTW, one thing to keep in mind as you look at only detecting the desktop agents is that there is a wide diversity of screen sizes in mobile alone.

When we talk about delivering a mobile image as the default, what size are we talking about? Will it work equally well for the large Android screens and the 176 pixel feature phones?