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

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 23 Apr 2014 00:25:40 -0700
Message-ID: <53576AF4.9080208@inkedblade.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Dirk Schulze <dschulze@adobe.com>
CC: "www-style@w3.org" <www-style@w3.org>
On 04/17/2014 11:15 AM, Tab Atkins Jr. wrote:
> On Thu, Apr 17, 2014 at 11:10 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>> In this case image() has no fallback behavior at all. It’s whole purpose changes completely. The reason why people would use it is just because of image(<color>) and it seems strange that we need a function to specify the color .. or have <url> and <string> at all. Unless people want to have EXIF support of course.
>
> image() still has several useful things it can do, and some more stuff
> we punted to Level 4, like giving an image directionality (so it gets
> reversed in bidi situations).
>
> 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.

~fantasai
Received on Wednesday, 23 April 2014 07:26:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:21 UTC