CSS animations and transitions now use Web Animations when experimental-web-platform-features are enabled

Steve Block

unread,

Nov 21, 2013, 9:03:52 PM11/21/13

to blink-dev

TL;DR

The underlying implementation of CSS animations and transitions is in
the process of being switched to use the new Web Animations engine.
We're now enabling this new engine behind the
experimental-web-platform-features flag. Changes in behavior should be
extremely limited, and always a progression. Please file bugs against
dstoc...@chromium.org if you see anything suspicious.

Details

https://codereview.chromium.org/70903004 sets Web Animations [1] as
the default implementation of CSS animations and transitions when
running with the experimental-web-platform-features flag enabled.

The web-facing behavior of the new engine is almost identical to that
of the legacy implementation. Where differences exist, they are a
strict progression in terms of compliance with the relevant specs, or
compatibility with Firefox. These behavioral differences are
documented with LayoutTests, and the changes can be seen in the deltas
to LayoutTests/[animations|transitions]/*-expected.txt in the above
patch.

The legacy implementation continues to be exercised under a new
virtual LayoutTests suite named 'legacy-animations-engine', which runs
with the --disable-web-animations-css flag. This suite will remain in
place until Web Animations CSS animations and transitions reach
stable.

If you have any problems, or see anything suspicious, please file bugs
against dstoc...@chromium.org, using the Cr-Blink-Animation tag.

The Web Animations team

[1] http://www.w3.org/TR/web-animations

Glenn Adams

unread,

Nov 21, 2013, 9:23:55 PM11/21/13

to Steve Block, blink-dev

On Fri, Nov 22, 2013 at 10:03 AM, Steve Block <steve...@chromium.org> wrote:

TL;DR

The underlying implementation of CSS animations and transitions is in
the process of being switched to use the new Web Animations engine.
We're now enabling this new engine behind the
experimental-web-platform-features flag. Changes in behavior should be
extremely limited, and always a progression. Please file bugs against
dstoc...@chromium.org if you see anything suspicious.

Details

https://codereview.chromium.org/70903004 sets Web Animations [1] as
the default implementation of CSS animations and transitions when
running with the experimental-web-platform-features flag enabled.

The web-facing behavior of the new engine is almost identical to that
of the legacy implementation. Where differences exist, they are a
strict progression in terms of compliance with the relevant specs, or
compatibility with Firefox. These behavioral differences are
documented with LayoutTests, and the changes can be seen in the deltas
to LayoutTests/[animations|transitions]/*-expected.txt in the above
patch.

It would be nice to have better documentation on the behavioral or web-facing differences (both syntactic and semantic) than having to read LayoutTests.

For example, did you implement the new @select attribute on animation elements?

The legacy implementation continues to be exercised under a new
virtual LayoutTests suite named 'legacy-animations-engine', which runs
with the --disable-web-animations-css flag. This suite will remain in
place until Web Animations CSS animations and transitions reach
stable.

If you have any problems, or see anything suspicious, please file bugs
against dstoc...@chromium.org, using the Cr-Blink-Animation tag.

The Web Animations team

[1] http://www.w3.org/TR/web-animations

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Steve Block

unread,

Nov 21, 2013, 9:37:08 PM11/21/13

to Glenn Adams, blink-dev

Hi Glenn,

> It would be nice to have better documentation on the behavioral or
> web-facing differences (both syntactic and semantic) than having to read
> LayoutTests.

We haven't added any new web-facing functionality, so there are no
syntactic changes. As for semantic changes, as I mentioned, the only
changes to behavior are slight, and are all progressions. These are
mostly edge-cases related to interpolating particular CSS values. Let
me know if you have any specific queries.

> For example, did you implement the new @select attribute on animation
> elements?

I'm not familiar with this, but it sounds like an SVG feature? This
change impacts CSS animations and transitions only.

Steve

Glenn Adams

unread,

Nov 21, 2013, 9:59:38 PM11/21/13

to Steve Block, blink-dev

On Fri, Nov 22, 2013 at 10:37 AM, Steve Block <steve...@chromium.org> wrote:

Hi Glenn,

> It would be nice to have better documentation on the behavioral or
> web-facing differences (both syntactic and semantic) than having to read
> LayoutTests.

We haven't added any new web-facing functionality, so there are no
syntactic changes. As for semantic changes, as I mentioned, the only
changes to behavior are slight, and are all progressions. These are
mostly edge-cases related to interpolating particular CSS values. Let
me know if you have any specific queries.

> For example, did you implement the new @select attribute on animation

> elements??

I'm not familiar with this, but it sounds like an SVG feature? This
change impacts CSS animations and transitions only.

See [1][2].

[1] http://dev.w3.org/fxtf/web-animations/animation-elements.html#attributes-to-identify-the-target-elements-for-a-timed-element

[2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_re-use_animations

Steve

Elliott Sprehn

unread,

Nov 21, 2013, 11:21:42 PM11/21/13

to Glenn Adams, Steve Block, blink-dev

I don't believe we've implemented any of that (largely incomplete) spec, nor have we decided to implement it yet.

Also it's very strange to add this complex markup scheme to define animations when <picture> + <source> is deemed too hard to deal with. <animate> is crazy complex by comparison. If vendors are going to commit to this spec we need to reconsider <picture> since implementing it should be a walk in the park. :/

Hajime Morrita

unread,

Nov 22, 2013, 1:30:59 AM11/22/13

to Elliott Sprehn, Glenn Adams, Steve Block, blink-dev

I believe that what Grenn pointed is very early version of the
standard. As it got certain push back, the team has been considering
the simplified version of it.

Brian Birtles

unread,

Nov 24, 2013, 7:18:23 PM11/24/13

to blin...@chromium.org

On Friday, 22 November 2013 15:30:59 UTC+9, Hajime Morrita wrote:

I believe that what Grenn pointed is very early version of the
standard. As it got certain push back, the team has been considering
the simplified version of it.

No, it was a proposal to express currently implemented SVG animation features in terms of the Web Animations model and expose a few missing features. It was approved as an SVG WG item at TPAC two weeks ago and has nothing to do with CSS and this discussion.

Douglas Stockwell

unread,

Dec 1, 2013, 7:24:37 PM12/1/13

to blink-dev

As of r162935 [1], CSS Animations and Transitions now use the Web Animations engine by default. If you see any issues, please files bugs against me or use the Cr-Blink-Animation label.

- Doug

[1] https://src.chromium.org/viewvc/blink?revision=162935&view=revision

Dirk Schulze

unread,

Dec 2, 2013, 6:06:24 AM12/2/13

to Elliott Sprehn, Glenn Adams, Steve Block, blink-dev

On Nov 22, 2013, at 5:21 AM, Elliott Sprehn <esp...@chromium.org> wrote:

> I don't believe we've implemented any of that (largely incomplete) spec, nor have we decided to implement it yet.
>
> Also it's very strange to add this complex markup scheme to define animations when <picture> + <source> is deemed too hard to deal with. <animate> is crazy complex by comparison. If vendors are going to commit to this spec we need to reconsider <picture> since implementing it should be a walk in the park. :/

Elliott, can you elaborate what you mean? For me it looks like you try to combine the responsive image discussion with SVG animations flame wars :)

Greetings,
Dirk

birtl...@gmail.com

unread,

Dec 2, 2013, 6:24:58 PM12/2/13

to blin...@chromium.org

On Monday, 2 December 2013 20:06:24 UTC+9, Dirk Schulze wrote:

On Nov 22, 2013, at 5:21 AM, Elliott Sprehn <esp...@chromium.org> wrote:

> I don't believe we've implemented any of that (largely incomplete) spec, nor have we decided to implement it yet.
>
> Also it's very strange to add this complex markup scheme to define animations when <picture> + <source> is deemed too hard to deal with. <animate> is crazy complex by comparison. If vendors are going to commit to this spec we need to reconsider <picture> since implementing it should be a walk in the park. :/

Elliott, can you elaborate what you mean? For me it looks like you try to combine the responsive image discussion with SVG animations flame wars :)

I suggest this is not the right time or the place for this discussion because:

* the spec doesn't even exist yet (only a skeleton in 'unofficial draft' status and we don't even know if it belongs under SVG or FXTF).
* any issues about the spec itself should go to the spec mailing list first (which will either be www-svg or public-fx once we work out where this belongs).

Please wait until we at least have an editor's draft and then send comments along to the appropriate mailing list. Thank you!

Best regards,

Brian

Reply all

Reply to author

Forward