Re: [css-animations] Proposal for animation triggers, timebases and additive behavior

The basic idea seems very good.

On Wed, Sep 10, 2014 at 10:58 AM, Dean Jackson <dino@apple.com> wrote:

> animation-trigger
> -----------------
>
> Name: animation-trigger
> Value: auto | scroll(<snap point> [, <snap point>]+)
> Initial: auto
> Inherited: no
> Animatable: no
>

This inherits the CSS snap-points draft's weak handling of element-relative
positions. This bothers me because element-relative scroll positions should
be the norm, not the exception, both here and in CSS snap-points.

That aside, if we allow element-relative scroll positions here (and we
should!), then we have a circularity problem where an animation can affect
the position of an element and also be controlled by the position of that
element.

One solution would be to abandon animation-trigger as a declarative
property and instead require scripts to turn animations off and on in
response to scroll events, perhaps via Web Animations. I wonder what the
impact of that would be. Note that many uses of animation-trigger could be
rewritten as an always-on animation that's a complex function of the scroll
position.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.