Hacker News new | ask | show | jobs
by ned 5178 days ago
The idea of compound images is really interesting, although it would require an extra HTTP request to fetch the hight-DPI portion of the image. But maybe less of a problem over SPDY?

The idea truncatable bitstreams is fascinating too. I'm not well versed in networking, but wouldn't the latency of a mobile network kill the benefit of this technique? e.g, by the time the server receives the "connection closed" signal, a large part of the extra data would have been sent, no?
2 comments
archgrove 5178 days ago
It would need an extra HTTP request, yes. In practice for the PNG solution, one would be better off with sending the DPI in the request headers, so that the "correct" image is the only one sent.

For JPEG 2000, the network characteristics are important, but I don't think it would be too bad on a mobile network. Low DPI devices might get a bit "too much", but it wouldn't be a problem - they can just throw it out (or incorporate more detail).

link
jentulman 5178 days ago
Headers do seem the best place for a non vendor specific standard to be set. I'd love to see something like

viewport-dpi - the dpi viewport-max - the maximum possible pixel dimension and possibly viewport-current - the pixel dimensions at the time of the request

Decent responsive design should deal with the differing viewport sizes, but it might be nice to get a hint before delivering your page what direction to weight that response in.

link
Groxx 5178 days ago
What do you do when using a projector, and your DPI is something like 3? (serious question, I don't know how this is traditionally handled)
link
kijin 5178 days ago
Something like device-pixel-ratio would be more useful than DPI. Raw DPI is meaningless unless you take distance into account, as is very clear in the case of the projector.
link
nextparadigms 5178 days ago
Would this work better over WebP?
link
dwnoiz 5178 days ago
Check this way of doing it to avoid extra http requests. http://www.archer-group.com/2012/development/javascript-jque...
link
caseyohara 5178 days ago
That is certainly the ideal way to reduce the HTTP requests. The problem with this implementation is clear: without a 'src' attribute on your images, if your script fails then your site suddenly has no images at all. Not to mention the overhead of manually modifying all of your existing markup.

Our goal with retina.js was to make it zero-config: no markup changes, no extra element attributes or flags.

link
oops 5178 days ago
The Stripe gallery posted here the other day[1] used src-less img tags for lazy loading. It looks like they handle the script issue by having the normal img tag (with src attribute) nearby in a noscript block.

Doesn't really do much to help with the overhead of modifying existing markup. Perhaps if you're already using something like image_tag in Rails, a retina_image_tag helper might not be too much of a stretch.

1: https://stripe.com/gallery

link