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

Re: [css3-transitions] "seamless" additive animations

From: Kevin Doughty <css@kxdx.org>
Date: Mon, 20 May 2013 18:58:19 -0400
Cc: Kevin Doughty <css@kxdx.org>, www-style list <www-style@w3.org>
Message-Id: <E5332DE2-35B2-40D9-95D7-205992BDB6B9@kxdx.org>
To: Sylvain Galineau <galineau@adobe.com>
I am experimenting with the following:
-webkit-transition-timing-function: perfect;
-webkit-transition-additive: additive;
-webkit-transition-compositing: delta;

Eventually I might be experimenting with:
-webkit-animation-timing-function: perfect;
-webkit-animation-additive: additive;
-webkit-animation-compositing: delta;

I have a working demo that will be pushed to my Github account soon. It is only proof of concept. Eventually I would like there to be additive animations as well. Perhaps transitions would only have a single one-key-enables-all property called "blend" or "seamless" that would produce this shorthand: "both cubic-bezier(.5,0,.5,1) additive delta".  This is the first demo page: http://jsfiddle.net/65aEJ/

The "compositing" mode means that the fromValue is the old underlying model value minus the new underlying model value, and the toValue is zero. I think it might also be nice to be able to replicate transition behavior using CSS animations and javascript with an additional compositing property. Perhaps it could determine what values are used when keyframes are left unspecified. It could be used to select whether or not animations use, in Core Animation terms, values from the model layer tree or the presentation layer tree, or this third "delta" mode. It is meant to be conceptually similar to image compositing and blending modes.

On Apr 26, 2013, at 6:01 PM, Sylvain Galineau <galineau@adobe.com> wrote:

> On 4/25/13 10:49 PM, "Kevin Doughty" <css@kxdx.org> wrote:
>>> the properties are *far* too well-established in the wild to permit
>>> changes that break backwards compatibility.
>> Isn't that what the vendor prefixes are for? Oh well...
> These properties are not prefixed anymore. It was agreed to unprefix them
> a year ago and some browsers have done
> so already.

Received on Monday, 20 May 2013 22:58:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:30 UTC