Re: [css4-images] The image-set() function (for responsive images)

On Wed, Feb 22, 2012 at 2:35 PM, Edward O'Connor <eoconnor@apple.com> wrote:
> Hi Tab,
>
> You wrote:
>
>> The image() function previously had the ability to specify the
>> resolution of an image layer. I've punted it to level 4 for now. Can
>> we just piggyback on that, and allow browsers to prioritize images of
>> "appropriate" resolutions?
>
> I think we should be reluctant to have image() become a catch-all; we
> should keep it focused on fallback. In my initial email, I said:
>
>>> * Why not enhance the image() function instead of inventing a new
>>>   function?
>>>
>>>   Unlike image(), these image specifiers are unordered. This isn't
>>>   about fallback. There is no preferred variant. UAs are free to use
>>>   whichever image it believes would be best. For instance, consider
>>>   the page zoom example I mentioned earlier. Authors could even use
>>>   image() and image-set() together to handle more exotic cases[…]
>
> Expanding on that last sentence, I think we should prefer focused and
> composable features for image choice. Let's keep image() for fallback[1]
> (a task for which it's well-suited; as its argument order matters) and
> let's add image-set() for resolution (a situation in which argument
> order shouldn't matter). We can add additional functions for other needs
> as they arise.
>
> Using image() for everything—turning it into an image-dwim()—produces a
> situation in which it would be very hard for authors to have a
> straightforward expectation about what image asset would actually get
> used in different scenarios. For instance, consider
>
> image(url(foo.png), url(foo.jpg) 1x, url(foo@2x.jpg) 2x, url(foo.bmp))
>
> I don't think it's easy to say what is going on here, nor is it easy to
> guess what asset a UA will choose. Whereas
>
> image(url(foo.png),
>      image-set(url(foo.jpg) 1x, url(foo@2x.jpg) 2x),
>      url(foo.bmp))
>
> keeps the relationship between each alternative far more clear: there's
> an ordered fallback relationship between three images. The second of
> these images has two equivalent variants at different scale factors.

Why not make the ordering matter?  If you just write the sources in
decreasing dpi order, you can still just pick the first one you can
successfully render.  This is what impls will do anyway, I guess.  I
presume, for example, that a screen with a dppx of 3 would still
choose one of the two images in your set (I don't know whether it's
better to choose the 2x and do blending or choose the 1x and just
stretch, but whatever).  So you'd just write it as:

image( "foo.png",
       "foo@2x.jpg" 2x,
       "foo.jpg",
       "foo.bmp");

(I presume as well that an image with the 2x specifier would default
to a resolution of 2dppx.)


> 1. Actually, I wish it was actually *called* fallback(), and lived in
>   another module. Fallback isn't just about images. For instance, I can
>   imagine wanting to use it for the src property in an @font-face rule.
>   The last argument (currently the color fallback) could act like
>   attr() does with regard to its type. But obviously it's a bit late to
>   make such a change, and I'm not suggesting that we do so.

That's not impossible, since nobody implements image() yet and it's
at-risk - we could just cut the feature.  However, images are the
majority case for fallback (@font-face handles fallback by itself),
and making it more general would remove our ability to also use it to
tag images with processing information, like their directionality and
their resolution.  We'd have reintroduce an image() function that only
took a single url string and then some specifiers, and nest that
inside of fallback().

~TJ

Received on Thursday, 23 February 2012 23:23:10 UTC