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

On Oct 15, 2013, at 1:39 PM, Shane Stephens <shans@google.com> wrote:

> Hi Dirk,
> 
> 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 :)
> 
> 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?).

That is right, since negative width results in no rendering.

> 
> 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 behavior?

Actually SVG does exactly that. The animated 'with' gets negative. So you have a negative output out of the animation and pass that to the property. This property does not accept rendering on negative values but accepts the negative value itself.

The problem that you may see with the CSS property (and SVG needs to be consistent if we want width to be a presentation attribute), is the following spec text[1]:

""
Negative values for 'width' are illegal.
""

That seems to be the reason that it does not animate. Your passed value is not accepted by the CSS parser and therefore no animation happens at all.

Greetings,
Dirk

[1] http://www.w3.org/TR/CSS2/visudet.html#the-width-property

> 
> Cheers,
>     -Shane
> 
> 
> On Tue, Oct 15, 2013 at 5:05 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> 
> 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 11:49:59 UTC