Re: Proposal: background-image-opacity or background-opacity

On Tue, Jun 2, 2009 at 11:18 PM, Simon Fraser <smfr@me.com> wrote:
> On Jun 2, 2009, at 10:25 AM, Tab Atkins Jr. wrote:
>
>> In your case, you have an abrupt transition like:
>>
>>   div {
>>     background: url( foo.jpg );
>>   }
>>   div:hover {
>>     background: url( bar.jpg );
>>   }
>>
>> And you want to make it into a smooth transition by crossfading from
>> one image to the other.  This is exactly what the Transitions module
>> is designed for, and crossfading between images does seem to be the
>> best idea in general for this sort of thing.  So we just need to
>> extend the Transitions module so that it specifies how to transition
>> the background-image property.
>
> Transitions applied to backgrounds like this are a little different from the
> transitions that the draft talks about:
>
> <http://www.w3.org/TR/2009/WD-css3-transitions-20090320/>
>
> In the draft, and the current WebKit implementation, transitions are
> implemented by changing the value of an existing CSS property on
> a timer, and re-rendering the content for each frame. While the
> transition is running, getComputedStyle() will return the currently
> displayed value of the property.
>
> If we decide to do cross-fading of background images without any
> additional new properties, we'll need to extend the spec to say what
> getComputedStyle() returns for background-image while the transition
> is running. The answer is not obvious to me.
>
> In this sense, the earlier suggestion of adding a background-opacity
> property makes sense; we then get back to the state where the engine
> can animate this new property, and getComputedStyle returns something
> sensible.
>
> To get a crossfade effect, the author would then have to do something
> like this:
>
> #foo {
>  transition: background-image 2s;
>  background-image: url(apple.jpg), url(orange.jpg);
>  background-opacity: 1, 0;
> }
>
> #foo.after {
>  background-opacity: 0, 1;
> }
>
> This is no longer automatic cross-fading, but it seems to fit better with
> the
> current notion of transitions. There's less magic here.

The issue, though, is that this type of property is (a) specific to
backgrounds, when there are a lot of places where we probably want
crossfade transitions, and (b) really *only* necessary for
transitions, as any place where you are layering static backgrounds or
other images you can adjust the opacity yourself in any common image
editor.

(a) is addressed partially by a new functional primitive like the ones
suggested by Giovanni and Hyatt, but then you return to having
something unanimateable, unless we substantially change how
Transitions works.  (b) is simply true - it may be somewhat *useful*
outside of transitions (making it a bit more convenient to alter the
opacity on images), but it won't ever be necessary in the way some
other abilities are.

I just don't think that the theoretical purity gained from casting
this into a form that Transitions can explicitly animate is worth
giving up the convenience/functionality of having transitions work
with a bit of magic here.  When you want to animate between images,
crossfading *is* the correct default choice most of the time imo, and
Hyatt notes in a previous email that the ability to specify different
image transitions is something that has been suggested before.

As for what to present to getComputedStyle, the simple answer would be
foo.jpg while you're in thee first half of the animation, and bar.jpg
while you're in the second half.

~TJ

Received on Wednesday, 3 June 2009 14:05:02 UTC