Toward a More Responsive Future

Let’s face it, ultimately the ideal solution for responsive images does not exists yet. Honestly, I am not sure that browser makers really have a dog in this fight so it will likely be a while before it gets done on their end. Hopefully the W3C will see all the discussion and decide to include something in the spec that would prompt browser makers to tackle this in a semantic way. Until then we are left with a variety of options that are not necessarily awesome.

Except this one, it's awesome. Ok, that might be a bit of hubris, the reality is this is just a more elegant hack. But before we dive into the details let’s discuss device detection, and why it is a short sighted solution, since it seems to be winning over hearts and allies.

Ultimately device detection has two major shortcomings: 1) security, and 2) it’s inability to determine display size. If you are writing your own server side device detection then there is really only one issue, #2, if you are using some one's third party service then you need to think long and hard about #1.

So security, whenever you rely on an outside service to manage any aspect of your site you are opening yourself up to the possibility that something will go wrong on their end and effect your site negatively. They could get hacked, they could go out of business, they could be purchased by someone with less than desirable intentions, or they could get knocked of the web by a DOS attack. I can hear you thinking: “But hey, they are only images. What’s the big deal?” Well there are a couple of big deals. First, javascript returned as the SRC of an image is executed in the browser meaning someone could execute arbitrary JS on your site. Setting that nightmare aside, if all the images on the third party system got replaced by ads to your biggest competitor, that would be a very bad thing for your website. As would all the images disappearing from your site because of an outage.

Of course these problems are purely theoretical, I have no idea what the security, plans or intentions of any of the sites providing this service are. But, they are possibilities that need to be considered.

Now for a more general issue with device detection and responsive images. Take a moment and read through all the comments on sencha.io src’s documentation. It becomes clear pretty fast that their are some drastic limitations to server side detection that are not shared by client side methods. The two big ones are: the inability to detect device rotation on mobile devices, and dealing with very large screens. Server side device detection requires you to setof default sizes for given devices. This means, in sencha.io’s case, that the maximum size of an image returned from automatic resizing is 980px. So if you need an image to display at 1300px on those beautiful new thunderbolt displays, and then automatically scale down to 120px on an iPhone, you are out of luck.

Sure you can specify the width of the image explicitly, but now you are back to doing browser size detection in javascript and rewriting the src of the image. Which you could have been doing all along without the outside dependency.

One of the realities of the responsive web is that it needs to scale up as well as down. Responsive design is about tailoring the experience to the particular users context, whether it is larger or smaller than your default. This means we shouldn’t be sending the same experience to someone on a 2000+px screen as we do to a 1200px screen. For me this is the last nail in the coffin for device detection as the ideal solution. It could be useful for setting smart defaults, but ultimately fails to provide a truly responsive experience.

Now on to the fun stuff, that probably brought you here in the first place: future friendly javascript-less client side responsive images. Be aware that these, much like using noscript, are still a little hack-ish. But, this seems to be a better solution than noscript to me.

The image tag, like pretty much every other element in html, can receive a background style. This means that we can create an image whose background changes, based on media queries. At this point I should insert the caveat that you need to use something like respond.js to make media queries work in Internet Explorer, but there are ways around that, depending on how you structure your media queries. Another drawback is that each image will need a unique identifier, probably an ID, so we can set its “source”. So now some example code:

<style>      #myImage{
          background:url(respond/img/myImage.jpg) no-repeat;

          width:96px; height:95px;
     } 
</style>


<img id="myImage" src="respond/img.png" alt="This is a test" /<

That’s really all there is to it. The respond/img.png is a 1px by 1px transparent png that weighs a whopping 96 bytes. It is the hack-ish part, but we need it to hide the alt text, and the missing image styles added in by the browser. Hopefully that need will go away in the future, and removing it would be very simple in that case.

This method opens up the door to some crazy stuff too. Like having different aspect ratios for images at different screen resolutions. Or like having all the images for a page stored in a single sprite per screen resolution. Imagine all your images coming in as essentially 2 http requests, one for the img.png and the other for all of them as a single image. Is that a good idea? I have no idea... but it is possible.

Hopefully someday soon we will have an img tag that is responsive from the get go, but for now we need to find the option that is going to work best for our particular environment and needs. This is my current favorite, though there are probably cleaner methods for doing this. I hope... if you know of one write it up so we can all discuss it more. Until then go forth and be responsive!

If you enjoyed this article please share it! Also, I have a newsletter that you might enjoy as well. Thanks! -Daniel