W3C home > Mailing lists > Public > www-svg@w3.org > April 2011

Re: Proposal: Fix frozen to-animation

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Fri, 8 Apr 2011 10:22:14 +0100
To: www-svg@w3.org
Message-Id: <201104081122.14698.Dr.O.Hoffmann@gmx.de>
Brian Birtles:

> > Well, I you have a look for example into the CSS transitions draft,
> > this might give an idea.
> > It is not perfect either, but indicates, that several people assume,
> > that something like this has use cases.
> Please provide specific reference. I can't see any case in CSS
> transitions where the transition is adding to a value in change, stops
> mid-interval, and then maintains that intermediate value masking
> underlying changes.

As far as I understand this, this is always implicated, the
transitions start always from the current state. Each time
a new transition starts, it starts with the current state.
CSS animations and transitions currently have no additive
behaviour - concerning this, a precise timing model or
interactivity, the drafts are still pretty rudimentary.
Obviously to-animations are slightly more elegant due
to the precisely defined formula - I think, transitions at least 
don't jump, to-animations are really smooth.

A common use case, of at least where I expect it should work this way,
what is currently not possible in SVG without to-animations, is
a combination with interactivity causing a smooth change when
events occur.

For example you have a button, with mouseover it changes to
one color, with mouseout to another, with mouseup and mousedown
to other colors again. If the user moves the mouse fast or the same
animation has to be restarted due to an event, with your idea
(or what is currently typically implemented) there is always a sudden 
change, a jump corrupting the intended effect. This can be avoided, when
the frozen state conserves the current value. It is not completely
trivial to create such buttons, but at least possible with correct
implemented to-animations. Unfortunately the current CSS transition
draft has no events like mouse*, therefore it is of limited use for
this purpose either, therefore it would be fine to have at least 
to-animations properly working for this purpose in SVG.

Parts of the bugs can be covered with restart="whenNotActive",
but this is a slightly different effect, because it covers the
problem effectively by ignoring too fast user interactivity, 
example here (mouseover and mouseout on the image):

The following is the originally intended document, something
like this could be pretty common, if to-animations would work
in current viewers:

Correctly implemented, the changes of the size of the image 
would be always smooth with mouseover and mouseout
without ignoring interactivity from the user.

Received on Friday, 8 April 2011 09:22:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:24 UTC