- From: Edward O'Connor <eoconnor@apple.com>
- Date: Wed, 22 Feb 2012 14:35:02 -0800
- To: www-style@w3.org
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