[web-animations] Do we need to store original timing values when they are invalid?

Hi,
(CC'ing www-style since the may be some precedent from CSSOM we can 
apply here.)

Web Animations currently says that if I do the following:

   var anim = elem.animate({ opacity: 0 },
                           { duration: 1000, iterations: -1 });

I'll see the following:

   anim.effect.timing.iterations; // -1
   anim.effect.getComputedTiming().iterations; // 1

The idea is 'timing' is the *specified* values and *getComputedTiming()* 
gives you the actual ones used in calculations.

That's helpful for things like { fill: 'auto' } since you can see what 
'auto' expands to but still keep the original 'auto' value (so you can, 
for example, apply that same timing object to other animations where 
'auto' might expand differently).

But I wonder how important it is to preserve the original value when 
it's invalid?


ASIDE: WHY WE PRESERVE INVALID KEYFRAME PROPERTY VALUES

In Web Animations, for keyframes we need to preserve invalid property 
values since what is defined as invalid may vary from implementation to 
implementation based on their support for different CSS properties.

* If we drop invalid property values, then an implementation that
   supports the property value will produce a different set of keyframes
   to an implementation that does not and that will likely break scripts
   that assume a certain number or sequence of keyframes.

* If we throw an exception for invalid property values, then if the
   implementation(s) the author tested with happen(s) to support the
   property values, but the user views it with an implementation that
   does *not* support those values, an unhandled exception will be thrown
   and the whole page will break.

For those reasons, we simply preserve the invalid values and encourage 
implementations to report a warning in their debug console or what not.


I don't know if the logic that applies to keyframe values applies to, 
say, negative iteration counts, however.

A more interesting case is probably timing functions since they will 
likely be expanded in the near future.

If the author specifies { easing: 'spring(3)' } and an implementation 
doesn't support that, I think we should *not* throw an exception since 
an animation with incorrect easing is better than a completely broken 
page. In that case, anim.effect.getComputedTiming().easing should return 
"linear" but what about anim.effect.timing.easing? Maybe preserving the 
"spring(3)" is useful to show why we ended up with "linear"?

If that's the case, maybe the original example should preserve 
"iterations = -1" for consistency and authors just need to be careful to 
always query getComputedTiming() if they want sensible results?

What do you think?

Best regards,

Brian

Received on Wednesday, 25 November 2015 23:37:06 UTC