[whatwg] responsive images srcalt proposal

pghj pghjvanblokland at gmail.com
Mon Jan 27 07:04:48 PST 2014


There are still some pre-loader issues.  Google is promoting that the CDN
> dynamically optimize the content, that the user agent share enough info to
> allow the CDN to do so - effectively moving a UA function to the cloud and
> making a service out of it!  From a user privacy perspective this is not
> good.  To counter this, any proposal needs to be competitive, and needs to
> support the pre-loader being able to make the same decisions that the CDN
> with some UA info could - it does not need to be any better.

This is the Client Hints by Ilya correct? I'm not a big fan of that because
a) most people expect a URI to uniquely identify a piece of data and b)
control is taken away from the user: the client does not know which
candidates are available and how to influence selection.

Instead, if the server should take an active role, I'd much rather have
this:

<img src="image.jpg" srclist="image.jpg?list" />

Where an HTTP request on image.jpg?list gets a "300 Multiple Choices"
response with an extensible format describing all image candidates and
their properties (dimensions, file size, quality, format). Ideally the img
src attribute request itself should get this response, but that would break
compatibility. However browsers could start accepting such a response, and
srclist could then later be deprecated.

This puts the user-agent back in control to make bandwidth/quality
decisions. The cost is one additional request per image, but that shouldn't
be a problem in a SPDY future.

Maybe Ilya could weigh in on this?


 As to srcalt being competitive with Client Hints: I don't think there is a
difference, because for bandwidth optimized resource selection, a CH-RW
header is needed, and that only becomes available after initial layout,
just like srcalt requires.


Thank you for reading.

Josh.



More information about the whatwg mailing list