- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 24 Apr 2014 08:21:23 -0700
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: Dirk Schulze <dschulze@adobe.com>, "www-style@w3.org" <www-style@w3.org>
On Wed, Apr 23, 2014 at 12:25 AM, fantasai <fantasai.lists@inkedblade.net> wrote: > On 04/17/2014 11:15 AM, Tab Atkins Jr. wrote: >> That said, I think the "fallback to solid color" thing is valuable to >> keep, separately from the "choose from multiple urls" case. I think >> the latter will get farmed out to improvements in image-set() to make >> it match the abilities of <picture> more closely, but the former is >> useful in a different way than resolution enhancements or type >> negotiation is. > > My concern with keeping it is largely that we don't know what the > syntax of fallbacks will look like once it's merged with image-set(). > > Otherwise I agree, the functionality is straightforward and useful. I'm not concerned because: * I think the image-fallback stuff will mirror <picture>, which doesn't have allowances for "image fails to load" in the first place - it's just about selecting an appropriate source and then running with it - so likely you'll still need to wrap an image() around it to get the "broken image" fallback. * Even if we do go beyond what <picture> does and allow broken-image fallback behavior, and thus end up adding color fallback to image-set(), the duplication doesn't bother me. * If we end up merging fallback behavior back into image(), I'm confident we can chart a syntax course that is compatible with the current syntax. A color would just be recognized as a final fallback after the images fail to load, is all. ~TJ
Received on Thursday, 24 April 2014 15:22:10 UTC