Responsive image issues

Hey there,

I’m new to this list, trying to figure out responsive images as I add support to a website builder I co-authored (http://sparkle.cx). I’m mostly a Mac/iOS dev, have done a bunch of webdev as well, ~25 years of software dev experience.

Findings so far:

* srcset with display density

While this works great, there’s nothing responsive about it. You can swap out 1x/2x images but not in a breakpoint-aware way. And this isn’t even about art direction, you can’t provide the same crop at different scale factors to save on bandwidth. A non starter.

* srcset with width descriptors

Aside from the bizarre syntax and browser bugs, this does have a responsive behavior. The conceptual problem that isn’t addressed by the spec is the assumption that a 1000px image and a 500px@2x image are the same image. The srcset attributes specifies a list of images sizes, regardless of density, and the browser does the math of image size and screen DPI to pick the right size from the list, with no ability to pick different images based on density.

While 1000px and 500px@2x can be the same, this wastes a ton of bandwidth. Strangely enough I haven’t found any mention this. There’s ample evidence that higher density screens hide JPEG compression artifacts enough to allow @2x images to be compressed to a size that’s close to the @1x equivalent (see for example http://alidark.com/responsive-retina-image-mobile/).

Compressing images at all sizes with the same compression factor, which is based on viewing quality at @1x density, causes a browser on a @2x screen to download an image that’s roughly 3-4x the size of an image compressed specifically for the @2x viewing quality (rough unscientific test).

This makes srcset-w better than earlier JS/CSS solutions, mostly in latency terms due to the pre-parser head start, but not nearly as effective as it could be.

This is in my view a flaw in the spec design that makes srcset-w nearly useless. The only redeeming quality is that it actually is supported by a good number of browsers.

About the browser bugs:

- Chrome hangs on to the largest image it switches to, forever
- Safari doesn’t load a higher (or lower) resolution image when crossing a breakpoint (https://bugs.webkit.org/show_bug.cgi?id=149899) and presumably when switching screen resolution as well (untested), the workaround here seems to be to force-set the srcset attribute when crossing a breakpoint threshold.

* picture

The picture element is superior to srcset-w in that even in the non-art direction case an individual image can be picked for each breakpoint and each screen density. While the syntax is verbose, it is nowhere as convoluted as srcset-w.

The problem with the picture element is that it’s not available on iOS http://caniuse.com/#feat=picture — while Safari on Mac isn’t insignificant, it’s mobile that has the most need for the bandwidth savings. (IE also doesn’t support picture, but they don’t support srcset either so it’s down to a JS solution and they're mostly equivalent).

The canonical solution would be to use picturefill, and while it’s only ~11kb, in Mobile Safari it would essentially fall back to srcset-w behavior in terms of initial latency and bandwidth use, so I might as well not sure it.


I’m just trying to find the most effective pragmatic solution that has some future proofness to it, any thoughts appreciated.

Thanks,
Duncan

Received on Saturday, 12 December 2015 21:01:08 UTC