W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2013

Re: [web-animations] bounded CSS attributes and SVG properties

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 15 Oct 2013 05:53:15 -0700
Message-ID: <CAAWBYDCpnGv-7YLgRdnVJTHtxam8cX5swoVaHaqkiFSvuLBQ=Q@mail.gmail.com>
To: Shane Stephens <shans@google.com>
Cc: Dirk Schulze <dschulze@adobe.com>, Brian Birtles <bbirtles@mozilla.com>, "public-fx@w3.org" <public-fx@w3.org>
On Tue, Oct 15, 2013 at 4:39 AM, Shane Stephens <shans@google.com> wrote:
> I agree with you - bounding on output seems best.
> Interestingly, at least in CSS, the following:
> .foo {
>   animation: bar 2s;
>   width: 300px;
> }
> @keyframes bar {
>   to {
>     width: -300px;
>   }
> }
> Won't result in any animation :)

As Dirk said, this is because CSS eagerly applies its error fallback,
so you can do proper fallback with multiple values like in a normal
declaration block.  This means that the 'width' declaration in the
@keyframes is dropped, leaving it an empty animation which does
nothing.  (I forget whether we resolved a few months ago that empty
keyframes still cause an animation to start or not.)

> I don't fully understand SVG, but I *think* in SVG a to-animation of width
> from 300 to -300 will result in the element disappearing halfway through the
> animation (is this right, Brian?).
> So it seems like neither SVG nor CSS actually match this intuition under at
> least some circumstances right now. Is this a problem? Can Web Animations do
> the intuitively correct thing yet still support the legacy SVG and CSS
> behaviour?

Yes.  The SVG behavior is just "never clamp" - if you end up sending
an illegal value, it'll do what it normally does for illegal values.
The CSS behavior requires knowledge of the valid bounds, and you just
scrub the keyframes for illegal values before you set up the
animation.  Since your preferred behavior requires knowledge of the
valid bounds anyway, this doesn't need anything new.

Received on Tuesday, 15 October 2013 12:54:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:47 UTC