[whatwg] img srcset / css image-set issues

[John Mellor]

On Tue, Aug 21, 2012 at 8:31 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Tue, Aug 21, 2012 at 12:20 PM, John Mellor <johnme at google.com> wrote:
> > 1. Neither is of any use for flexibly-sized images.
>
> This is what Media Queries and the similar 'w' and 'h' tokens in
> @srcset are for.  You can create one pair of 1x/2x images for one size
> of screen, and another pair for another size of screen.
>
>
While it is indeed possible to abuse the w/h tokens in this way, it's so
impractical as to not be worth using. Take the simple example above where
you have the same image saved in 4 sizes -- 320.jpg, 640.jpg, 1280.jpg and
2560.jpg, named after their widths -- and you need it to scale across
mobile and desktop. With my proposed syntax you just declare each available
size once, and the browser does the rest:

<img srcset="320x120, 320.jpg 1x, 640.jpg 2x, 1280.jpg 4x, 2560.jpg 8x">

Whereas using only the w/h and x tokens, to properly support devices of
various dppx's you have to use the following 16 entry monstrosity (that I
had to generate by script <http://jsbin.com/aganaz/8/edit?javascript,live>):

<img srcset="
    320.jpg 400w 1x,
    320.jpg 320w 1.25x,
    320.jpg 267w 1.5x,
    320.jpg 200w 2x,
    320.jpg 160w 2.5x,
    640.jpg 800w 1x,
    640.jpg 640w 1.25x,
    640.jpg 533w 1.5x,
    640.jpg 400w 2x,
    640.jpg 320w 2.5x,
    1280.jpg 1600w 1x,
    1280.jpg 1280w 1.25x,
    1280.jpg 1067w 1.5x,
    1280.jpg 800w 2x,
    1280.jpg 640w 2.5x,
    2560.jpg 10x
">

(and in the image-set case, doing this with media queries would be even
more horrific)

I'll explain why this happens:

a) The primary problem with using w/h tokens for this, and the reason the
above srcset is so redundant, is that in the current srcset spec the x
tokens are totally independent from the w/h tokens. So if you have an image
that's 640 image pixels wide, it is suitable for display 640 CSS px wide on
a low dpi device, but only 480 CSS px wide on a medium dpi device, and only
320 CSS px wide on a high dpi device, etc. These all need to be encoded
separately, since you can't write rules in terms of the product of the 'x'
and the 'w'. Clearly it would be better for the browser to do this trivial
but repetitive and error-prone maths for you.

b) A second difficulty, is that the w/h tokens must be specified in terms
of the viewport size, but there may be no trivial relationship between the
image size and the viewport size. Even if there is, having to figure it out
increases the developer burden, and significantly increases the risk of
errors (which can very easily slip through, since it's hard to test on all
device types, and most developers will only notice mistakes if the image
looks bad, not if it merely consumes an unnecessary amount of bandwidth).

c) Finally you'll notice that I put "320.jpg 320w 1.25x" instead of
"320.jpg 320w 1x". That's because (as pointed out in 2.) srcset is
currently specified such that these are strict maximums, yet in practice
it's better to upscale an image a little bit (e.g. 1.25x) than to download
an image that's twice as big (potentially 4x the file size). Cobbling
together w/h and x tokens like this requires the author to manually make
value judgements like this and incorporate them into their calculations,
when it would be better to let the browser decide.


>
> > 2. srcset not as smart/intuitive as image-set.
>
> The algorithms are meant to be the same.  If you read the HTML
> algorithm carefully, you'll notice that, after you've eliminated the
> images that violate the 'w' or 'h' constraints, the browser can choose
> *any* of the remaining images, based on whatever criteria it wants.
> This happens in two places: step 17 is very explicit in saying "UAs
> can do what they want"; step 21 is more implicit, as the "nominal
> pixel density" is a UA-defined value and can be literally anything.
> (There was previously a note in the spec saying this directly, but it
> appears to have been removed.)
>
> Ideally, I'd be able to just refer to the HTML algorithm, but it's far
> too specialized for @srcset for me to actually use.  Instead, I plan
> to include a note pointing to @srcset and indicating that it should be
> identical.
>
>
I'm glad you intend them to be the same. But currently they are very
different semantically. With image-set you just provide the intended dppx
of each image, and let "the UA decide which is most appropriate in a given
situation"[source <http://dev.w3.org/csswg/css4-images/#image-set-notation>],
i.e. it can be expected to pick the closest match. Whereas with srcset, "2x
means maximum pixel density of 2 device pixels per CSS
pixel"[source<http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset>]
(emphasis on the "maximum"), and step 21 of the
algorithm<http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates>
reinforces
this by discarding anything whose maximum is too small.

The fact that the UA is granted some freedom to fiddle with things doesn't
change the semantics. And rather than changing image-set to be more like
srcset, it would be better to change srcset's handling of dppx to be more
like image-set (since it's more intuitive to provide the intended dppx's
rather than having to calculate thresholds to use as maximum dppx's).


> > 3. image-set is less flexible than srcset.
>
> It's not.  The extra things that @srcset can do are precisely
> identical to just using Media Queries.
>

Since srcset and image-set are so syntactically and semantically similar,
authors are going to expect them to behave the same. The whole
point<http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html>of
image-set was to avoid having to use media queries to differentiate
between different dppx screens (because of redundancy, non-locality, etc,
as eoconnor explained<http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html>).
Being able to use image-set instead of media queries for half of srcset's
functionality, but not the other half, doesn't make much sense.


>
> ~TJ
>