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

On Oct 15, 2013, at 3:30 AM, Brian Birtles <bbirtles@mozilla.com> wrote:

> (2013/10/15 10:17), Shane Stephens wrote:
>> Some animatable values have closed bounds (e.g. SVG and CSS width and
>> height values can't be less than 0). When animating these, we have a
>> choice to either:
>> * enforce the boundedness within our animations; or
>> * enforce the boundedness when applying the result back into CSS or SVG
>> 
>> I propose we choose the latter, so that things like:
>> new Animation(target, [{width: -50px, composite: add}, {width: 50px,
>> composite: add}], 1);
>> modify the element from 50px smaller than current size to 50px larger
>> than current size.
> 
> In terms of compatibility, for SVG the latter behaviour is "recommended" 
> in SMIL:
> 
> "Some attributes that support additive animation have a defined legal 
> range for values (e.g., an opacity attribute may allow values between 0 
> and 1). In some cases, an animation function may yield out of range 
> values. It is recommended that implementations clamp the results to the 
> legal range as late as possible, before applying them to the 
> presentation value. Ideally, the effect of all the animations active or 
> frozen at a given point should be combined, before any clamping is 
> performed. Although individual animation functions may yield out of 
> range values, the combination of additive animations may still be legal. 
> Clamping only the final result and not the effect of the individual 
> animation functions provides support for these cases. Intermediate 
> results may be clamped when necessary although this is not optimal. The 
> host language must define the clamping semantics for each attribute that 
> can be animated."[1]
> 
>> Some animatable values have open bounds (e.g. CSS column-width values
>> must be larger than 0).
>> What should we do when an animation results in a value outside these
>> open bounds? Currently we're thinking that we should set the value to
>> the smallest representable value larger than the boundary edge, but this
>> seems somewhat hacky.
> 
> Let me check I understand the issue. In light of these open bounds its 
> tempting to say that for both open and closed bounds, "don't do any 
> clamping, treat out of range values as invalid (and do whatever is 
> defined in that case)." But that's bad because in some cases it's 
> visually jarring and it puts the burden on authors to keep values in 
> range to avoid those effects.
> 
> Does that sound right?
> 
> (For rectangles it doesn't actually make a difference--SVG2 says that a 
> rect with width/height=0 is not rendered and the lacuna value for both 
> is 0 so whether we clamp to 0 or treat negative values as invalid and 
> fall back to the lacuna value of 0, you still get a discontinuity where 
> the rectangle disappears--something that is noticeable, for example, if 
> you have a stroke.)
> 
> Perhaps we should just define clamping behaviour per-property or 
> per-property type (similar to how SMIL says, "the clamping semantics for 
> each attribute that can be animated")?
> 
> For example, what is the most natural behaviour when shrinking a 
> column-width? Does clamping it to 0.00001 make sense? Or should it 
> disappear altogether? (And can be actually achieve that without tweaking 
> other properties?)


The shrinking should be after the animation step.

If the user defines and animation of 'width' from 300 to -300, the -300 should not be fixed to 0 during the animation and animate from 300 to 0. This seems unexpected.

So the property itself should handle the shrinking after the animation process. Means I am in favor for "enforce the boundedness when applying the result back into CSS or SVG".

Greetings,
Dirk 


> 
> Thanks,
> 
> Brian
> 
> 
> [1] http://www.w3.org/TR/smil-animation/#AnimationSandwichModel
>

Received on Tuesday, 15 October 2013 06:05:30 UTC