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

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.


Ted

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.

Received on Wednesday, 22 February 2012 22:35:38 UTC