W3C home > Mailing lists > Public > www-style@w3.org > April 2014

Re: [css-images] Changes to image()

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 24 Apr 2014 08:21:23 -0700
Message-ID: <CAAWBYDCz_02NCX2BWgMPphkrNBRn=k0CvVdQjT3Gt-DyqaW2Gg@mail.gmail.com>
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.

Received on Thursday, 24 April 2014 15:22:10 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:39 UTC