

Retina Images That Respond - uptown
http://drew.roon.io/retina-images-that-respond

======
ricardobeat
As long as you ignore the extra bandwidth from downloading _both_ the non-
retina and retina versions with this script, yes, it's pretty easy. Actually
serving retina images only for devices that need them, in an efficient and
backwards-compatible way is a much harder problem.

~~~
canterburry
You could give Pixtulate a try
([http://www.pixtulate.com](http://www.pixtulate.com)). Detecting the client's
properties (pixel density, screen size, etc) would still have to be done via
JavaScript on the client, but then just append those properties as query
parameters on the img's src attribute and the image will get converted on the
fly to whatever your visitor needs. Not only do you not have to pre crop or
scale your images, every image is specifically tailored to your visitor...not
just a simple 1x vs 2x.

~~~
ricardobeat
That's very useful, but cropping/resizing the images is not the hard part. If
you change the image src after the page is loaded, the first request is
already underway, so you end up downloading two images, just as happens with
the OP. You need to send device profiles to the server and somehow keep them
up-to-date, or create images on the client - and then serve a different
version to crawlers... there are plenty of proposals (image-set, srcset) to
handle this in HTML5/CSS but none has become standard yet.

~~~
mds101
Wouldn't this be resolved by setting a data-1x property (leaving the
src/background-image property blank)and then running javascript to substitute
the data-1x property for non-retina devices and data-2x property for retina
devices?

~~~
ricardobeat
Not that simple. That would be fine for a client-side app, but not for a
public-facing site:

1) no javascript = no images. crawlers/bots/archival services won't see them -
google might even penalize you for broken image sources. one error in your
main js file and all images are toast. needs other workarounds.

2) longer page load times unless you use inline scripts

4) extensions like readability, pinboard, weheartit, etc, might break

------
mds101
If you are going to use this, you should use querySelectorAll('[data-2x]') to
select the nodes, rather than getElementsByTagName('*') and then check if each
node has a data-2x as is done in the article, for performance reasons[1] and
to make your code simpler.

[1] [http://jsperf.com/queryselectorall-vs-
getelementsbytagname/6...](http://jsperf.com/queryselectorall-vs-
getelementsbytagname/65)

------
jlgreco
> _" If you’re reading this on any desktop monitor that exists in 2013, you’re
> on a legacy display (72 pixels per inch)"_

The 22.2" _IBM T221_
([http://en.wikipedia.org/wiki/IBM_T220/T221_LCD_monitors](http://en.wikipedia.org/wiki/IBM_T220/T221_LCD_monitors))
'becomes retina' when you are 17" away from it, compared to the _Apple Macbook
Pro Retina 15 "_, which 'becomes retina' when you are 16" away from it. The
former has a PPI of 203.98, the later 220.53. (all calculations done by
[http://isthisretina.com/](http://isthisretina.com/))

High DPI monitors prior to 2013 have also existed for years for use in
hospitals, though admittedly most consumers have probably never used one of
those.

------
jwklemm
The author has posted a follow up here -- [http://drew.roon.io/responsive-
retinas-strike-back](http://drew.roon.io/responsive-retinas-strike-back) \--
that offers some alternatives for getting around the extra download issue
(which a number of people brought up, including @ricardobeat in the comments).

------
mcmillion
Depending on the design constraints of your project, CSS media queries work
wonders. All modernish browsers are pretty intelligent about them.

