W3C home > Mailing lists > Public > www-style@w3.org > May 2011

Re: [css3-images] Composing generated images

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 24 May 2011 16:01:35 -0700
Message-ID: <BANLkTikzEx9EsbrDiFT=fqsHu5vjT+SD0Q@mail.gmail.com>
To: Brian Manthos <brianman@microsoft.com>
Cc: www-style list <www-style@w3.org>
On Tue, May 24, 2011 at 3:38 PM, Brian Manthos <brianman@microsoft.com> wrote:
> Brian:
>>> With and without your proposal, what's the expected behavior for
>>> transitions of background-image when the to and from both contain cross-
>>> fade?
> Tab:
>> Sigh, I had something like this tickling my brain, but I ignored it.
>> Yeah, transitioning a cross-fade() image produces a nested cross-fade(), so
>> there's no way to disallow it.  Never mind, then!
> Still curious on the answer to the "without your proposal" half of my question.

Ah, sorry about that.

> (1) Is it supported?


> (2) If yes to (1), what should the user experience be?

As currently specced, the fact that an image is generated by
cross-fade() is irrelevant, and it's transitioned like any other image
- by wrapping another cross-fade() around it.

Now that you bring this up, though, it probably makes sense to define
a special interpolation mode for <image-combination>s, such that if
both the start and end use the same images, just different
<percentage>s, they transition intelligently by just adjusting the
percentage.  If they use different images, it would transition just
like a normal image.  This is similar to how gradients have a special
transition mode when they match sufficiently, and otherwise transition
like images.

> (2b) Should the intermediate frames be rendered "as if" the cross-fade from the to and from endpoints was rasterized and then cross-fade between the two?

They may be, though it's not required.  If one or both of the
component images are vector formats, an impl is allowed to be smart
with the scaling.  They may instead just rasterize the endpoints and
do a dumb scale if they wish, though.

> (3) If yes to 2b, does this rasterization approach apply for SVG images as well?

Yes, as explained above.

> (4) If yes to (3), does this indirectly end up defining what an SVG to/from PNG transition should look like?

Not quite sure where you're going here.  An image is an image.  You
just apply the operations in the spec - scale each image, dissolve
each image, combine them with the 'plus' operator.  This works between
any image format.

> (5) If yes to (3), this should be very interesting for (a) multiple-resolutions-in-a-single-file and

That is a somewhat interesting case.  I guess it's possible to
interpret the spec as allowing an impl to switch with resolution to
use in an ICO file as the scale happens.  I doubt that's a good idea,
but unless someone requests it, I'm loathe to special-case that in the

> (b) for no-intrinsic-dimensions-in-the-specific-format.

This should be handled as explained in (2b) - if the image format is
scaleable, impls are allowed to be smart, but they're also allowed to
just rasterize the endpoints and be dumb.

> (6) If yes to (3) and (5b) is covered richly in the spec, then I think { CSS Gradient -> SVG -> PNG -> ICO } interpolations all the sudden become well defined.

Yes, they should be, subject to the impl wiggle room above.

Received on Tuesday, 24 May 2011 23:02:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:46 UTC