> 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
>> 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
(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
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.
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.