Source quality selection

[marcoscaceres]

In the interview with Odin, he raised a good use case for allowing users to say which source they prefer from a set of sources (e.g., "always send me the lowest quality one, I'm roaming!"). This is akin to what Opera Mini supports already - users can select what quality to receive images at. This use case needs to be captured in the UC&Reqs document, a long with a suitable requirement a "truly declarative" model be used... or something similar.

[Wilto]

This has definitely been a part of the plan, and something I’ve wanted to retain as part of srcset:
http://www.w3.org/community/respimg/2012/06/18/florians-compromise, under “Bandwidth.”

I was told a handful of times that something like the above wouldn’t be appropriate for the spec, but that was well before the use case doc existed. I’d like to see this represented too.

[MattWilcox]

Agreed, this was always one of the nice things about the approach of taking responsive images client-side. The ability to do user preferences. I'd like to see it in if possible, I'm not sure why it wouldn't be a good candidate for part of the spec (my ignorance of spec writing being the issue there).

[Wilto]

Interestingly, this has been called out in the image-set specification[1]. I think we should follow suit.

1: http://dev.w3.org/csswg/css4-images/#image-set-notation

(@marcoscaceres added the text we need to adapt)

Delivering the most appropriate image resolution for a user's device can be a difficult task. Ideally, images should be in the same resolution as the device they're being viewed in, which can vary between users. However, other factors can factor into the decision of which image to send; for example, if the user is on a slow mobile connection, they may prefer to receive lower-res images rather than waiting for a large proper-res image to load. The ‘image-set()’ function allows an author to ignore most of these issues, simply providing multiple resolutions of an image and letting the UA decide which is most appropriate in a given situation.

[marcoscaceres]

@Wilto, by the way.... did you see in the latest Chrome site preferences you can turn off images for a site? So, basically, this could be an extension of those options.

[marcoscaceres]

So, this is what I've got so far:

In situations where the user knows their bandwidth is limited or expensive (e.g., while roaming), the browser could assist users by:

1. giving users an option to only download images in the quality they desire - in addition to disabling images all together, as Google Chrome currently does through site preferences.
2. automatically select the most suitalbe image for the browsing environment.

There are browsers already catering for these kinds of situations: for example Opera Mini provides users with a choice of image quality (but those images are compressed on the server). Amazon's Silk browser also compresses images "in the cloud" (i.e., through their own proxy servers) before serving those images to a user's device.

[marcoscaceres]

Also added corresponding requirement:

1. The solution MUST afford user agents with the ability to provide a user-settable preference for controlling which source of an image they prefer. For example,  preference options could include: "always lowest resolution", "always high resolution", "download high resolution as bandwidth permits", and so on. To be clear, user agents are not required to provide such use-settable preferences, but the solution needs to be designed in such a way that it could be done.

[marcoscaceres]

emailed text to Odin for review.

[igrigorik]

I don't think "MUST" makes sense. Images, while a big part of the page, are not the only resources which can be modified to reduce the bytes on the wire. If there is setting in a browser to allow adaption based on bandwidth, then it should be a general preference, not just an image one - we don't want dozens of toggles. Having said that, if the browser wants to, they could give that option.. In other words "should", or "could", not "must".

[marcoscaceres]

I'm ok with SHOULD... yeah, looking at Chrome's site preferences, I can see it's starting to get a little long. the intent here is really about having a declarative solution (i.e., eluding to img@srcset).

[Wilto]

Yeah; I’m okay with “SHOULD” as well.

[marcoscaceres]

Updated to SHOULD and got ok from @velmont (Odin) on IRC.