546052 - Implement parsing for cross-fade() from CSS Image Values and Replaced Content Module Level 4

Reporter

Description

•

14 years ago

The CSS Transitions spec currently doesn't deal with images [transitions from url(img1.png) --> url(img2.png)]. It would be nice to be able to cross-fade when changing images, instead of having a sudden change.

For example, Firefox Personas simply set the background-image on a few chrome elements. When browsing available Personas, it would be very pleasant to have a soft cross-fade occur. In some cases one could do this manually, by stacking images and transitioning topmost's opacity, but that might be hard for Personas.

Other likely use-cases could be transitions between UI button states (eg, videocontrols play/pause), and things like slideshows. [The scope here could be widened to any CSS-control image (list-style-image, border-image, etc), but starting off with background-image would be most useful to me.]

One obvious tricky bit is when to start the transition, given that the image resource might need to be loaded. [Wait until onload? Or not? How to coordinate with other transitions?]

[:ocz]

Comment 1

•

13 years ago

I know, this isn't W3C conform, but this would partially solve the problem with fading transitions of background-images, that doesn't have a sourceimage, but have been build with gradients, too.

They could be prerendered and then faded in. I know this does more (transition of whole pictures) and than again less than the W3C asks for (and therefore isn't totally conform), but gradients should be "interpolated via the positions and colors of each stop. They must have the same type (radial or linear) and same number of stops in order to be animated. " Except the possibility to animatedly "move" those in-between stops, it would at least somehow give the ability to transit gradients.

It should be considered to be implemented as a placeholder feature into the next version of gecko, until the real thing arrives. (I'm not aware of the current development of gecko concerning this matter. Please feel free to post a link.)

The alternative would be to swallow the bitter pill, that every step (25 in 1s) of a background-image transition has to be rendered the hard way and to finally get over with it, as it seems to be time.

Ahh, I went a little bit offtopic.
Back to the interpolation of two pictures. Even in later steps, when the W3C rules have been applied, I see no reasons, why two pictures in a changing background-image property shouldn't be interpolated. It wouldn't be the first time the W3C adapted new features.

David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)

Comment 2

•

13 years ago

There are multiple options here, once gradients get involved.  See:
http://lists.w3.org/Archives/Public/public-fx/2010AprJun/0009.html
http://lists.w3.org/Archives/Public/public-fx/2010AprJun/0013.html

We might need to think about ways for an author to choose between different transform mechanisms.

[:ocz]

Comment 3

•

13 years ago

(In reply to comment #2)
> We might need to think about ways for an author to choose between different
> transform mechanisms.

Hmm. Let them decide, if the transition-effect between two images should be a simple crossfade, blur, mosaic or swapping wave-effect. The simplest way to do that, I can come up with,  would be to abuse the transition-timing-function and define "exotic" values, like blur-ease, mosaic-linear, wave-bezier(w,x,y,z) (with ease, linear, cubic-bezier(...) being the values for crossfading). Those should only work on the background-image property and fall back onto their equivalent standard values or throw an exception, if used on other properties.

Another problem is, that background-images may consist of more than one level.

Example:
.box {
  background-image: url("softkittyalpha.png"), /*level 0, rendered last*/
                    url("ocean.png"), /*level 1*/
                    -moz-linear-gradient(rgb(100,100,255),blue 50%);
  background-position: center, center, 0;
  background-repeat: none;
}

.box:hover {
  background-image: url("demonalpha.png"),
                    url("hell.png"),
                    -moz-linear-gradient(yellow,red 50%);
}

I propose abusing the transition-property-function by creating special values, that are no properties, but "link" to the levels of the background-image property. (background-image(0) background-image(1) background-image(2))

A transition-function property might look as the following:

-moz-transition: background(0) 1.25s blur-linear 1s,
                 background(1)  .25s wave-linear .87s;

This at least does look conform.

Other effects like changing effects midways in a transition like proposed in http://lists.w3.org/Archives/Public/public-fx/2010AprJun/0007.html, do sound awesome, but are so advanced, I have no hard feelings, if they are postponed until css4.

[:ocz]

Comment 4

•

13 years ago

Of course it's "background-repeat: no-repeat;" and "-moz-transition: background-image(0) 1.25s...,background-image(1)..."

All those fancy effects, discussed in those e-mails, are fine, but before thinking about, what else could be done, that even looks more awesome, shouldn't the simpler approaches be implemented?
I propose the following plan. (As I haven't deeply acquainted myself with this matter, I don't know, when I propose illogical or unrealistic steps.)

Step 1:
Implementing a simple cross-fade between two background-images, each as a whole, if they have the same size. If they don't have the same size, no transition effect will be applied.
This would do justice to this bug here and would help people a great deal, that have to use this image transition opacity workaround http://css-tricks.com/fade-image-within-sprite/
At this point W3C's goals still aren't achieved, but webdesigners do have something to work with.

Step 2:
Breaking up the rendering of the effects into the background-images levels. For each kind of transition (picture-picture, gradient-gradient) one animation effect will be defined as standard. (At first cross-fading for all of them.) Giving the ability to choose between effects will be postponed until step 3.
Then these effects will be changed/updated. I.e. picture-picture cross-fading will gain the ability to handle different sizes picures, while gradient-gradient transitions will become more and more W3C conform.
The used transition-timing value should still apply to all transitions of the background-image property.
The goal of this step should be to let background-image transitions gain the ability to work, even if the starting and ending images have different sizes, and to fulfill all of the W3C requirements.

Step 3:
Extending the css syntax or the pseudo-functions to give the ability to choose between different effects for the images on the different background-image levels, like proposed in comment 3 for example. This step also include to choose different transition-timing values for each level.
The goal: to go beyond.

David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)

Comment 5

•

13 years ago

(In reply to comment #4)
> Step 1:
> Implementing a simple cross-fade between two background-images, each as a
> whole, if they have the same size. If they don't have the same size, no
> transition effect will be applied.

I don't see any reason to have such a same-size restriction.  Just cross-fade.

> At this point W3C's goals still aren't achieved, but webdesigners do have
> something to work with.

What goals of W3C are involved here?

> Step 2:
> Breaking up the rendering of the effects into the background-images levels. For
> each kind of transition (picture-picture, gradient-gradient) one animation
> effect will be defined as standard. (At first cross-fading for all of them.)
> Giving the ability to choose between effects will be postponed until step 3.

I don't see why this is any more work than step 1.

[:ocz]

Comment 6

•

13 years ago

(In reply to comment #5)
> I don't see any reason to have such a same-size restriction.  Just cross-fade.

Step 1 is meant as a quickfix. I was under the impression, that different image sizes could cause trouble by creating a debate over, how to handle the transition. (Resizing, stretching, aso.) I wanted to avoid it. But I didn't think strait. Of course a simple cross-fade is sufficient. My bad. Step 2's improvement of picture-picture transition becomes obsolete, too.

> What goals of W3C are involved here?

Yet again my bad. Bad choice of words. I just wanted to say, that the specifications given by the W3C (concerning transitions of gradients)
still aren't met at that point. (I'm cutting my Women,World&Watermelons conquest joke, as it's lame.)
 
> I don't see why this is any more work than step 1.

Implementing step 1 should be easy, as it only involves rendering the before and after images of background-image and interpolate them.
Step 2 on the other hand includes the development of an animated transition effect for linear and radial gradients (smooth transitions of the stops, colors and resizing-handling; called (1) by you in http://lists.w3.org/Archives/Public/public-fx/2010AprJun/0009.html ), that is conform with the transition specs given by the W3C. It's more detailed work than step 1.
Maybe step 2 also involves optimizing the rendering too (if possible), as I only can think of the straight forward approach, that is: Compute all values for each layer of a background-image in transition, draw each layer on another, until an in-between image has been finished, draw that onto the screen and the whole procedure at least 25 times a second.
BTW: What really worries me, is the amount of computation steps needed in the  rendering process. Rendering 25 in-between pictures per second shouldn't be a big problem for 50px*30px buttons or two layer 800px*600px images. But what about five 600px*200px images with 4+ layers and tons of alphaeffect gradients, that might go of simultaneously? Well, I guess not creating monsters is the webdesigners responsibility.

Christian Sonne [:cers]

Comment 7

•

12 years ago

Chrome nightly recently added support for cross-fading backgrounds, as demonstrated here: http://dabblet.com/gist/1931619

David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)