[css3-transforms] Review of SVG animation section

Hi Dirk,

I've just done a quick review of sections 13.7 to 14 (inclusive) of the
CSS 3 Transforms spec. Thanks for all your work here. It's looking good.

> ‘animVal’ represents the computed style of the ‘transform’ property.
> Therefore it includes all applied CSS3 Transitions, CSS3 Animations
> or SVG Animations if any of those are underway.

I think this needs more detail but I'm not sure how easy this is to do.

For example, presently, in the following case:

   <rect transform="translate(30 40) rotate(45)">
     <animateTransform type="scale" additive="sum" ... />
     <animateTransform type="skewX" additive="sum" ... />
   </rect>

different UAs will give the animVal as:

   "translate(30 40) rotate(45) scale(...) skewX(...)", or
   "translate(30 40) rotate(45) matrix(...)", or
   "matrix(...)"

I think we should define this for <animate>. Could we say:

a) For non-additive animation, the resulting animVal from an animation
is covered by section 17.

b) For additive animation, however, is it possible to say, "Work out the
result, as per section 17" then append it to the transform list? Does
that work?

c) For to-animation the value would be covered by section 17 assuming a
from-transform that matches the underlying value based on (a) and (b)
above. (See next comment)

> To animations on ‘animate’ provide specific functionality to get a
> smooth change from the underlying value to the ‘to’ attribute value,
> which conflicts mathematically with the requirement for additive
> transform animations to be post-multiplied. As a consequence, the
> behavior of to animations for ‘animate’ is undefined.

I'd like to make this behaviour defined. If we leave it undefined the
Web will define it for us.

As for what that definition should be, can we just act like a
non-additive from-to animation where the 'from' value is the (live)
underlying value? As such there is no post-multiplication for to-animation.

> The value ‘paced’ is undefined for the attribute ‘calcMode’ on
> ‘animate’ for animations of the data type <transform-list>. If
> specified, UAs may choose the value ‘linear’ instead. Future versions
> of this specification may define how paced animations can be
> performed on <transform-list>.

Again, I'd like to avoid undefined behaviour. It's already half-defined
in SVG.[1] Can we just extend that definition to describe what happens
with the extra transform types and with lists (e.g. if the number and
type of functions don't match or are of type matrix/unknown, use a
distance of 1.0; when there are multiple functions do an average?).

If that proves impossible, then at a minimum, we could at least say:

A) It's not supported and UAs that have such a feature should report a
warning. UAs must use linear interpolation, OR
B) It's an error. UAs must not animate at all.

B is somewhat preferable to me since linear interpolation is quite
different to paced, it's not really a suitable fallback behaviour if
paced animation gets defined in future. It's also more helpful to
developers attempting to use paced animation since it's a clearer
indication that something is wrong.

> The following paragraphs extend Elements, attributes and properties
> that can be animated [SVG11].

The link here points to:

   http://www.w3.org/TR/SVG/animate.html#complexDistances

But I think it should point to:

   http://www.w3.org/TR/SVG/animate.html#AnimationAttributesAndProperties

> The introduce presentation attributes ‘transform’,
> ‘transform-origin’, ‘perspective’, ‘perspective-origin’,
> ‘transform-style’ and ‘backface-visibility’ are animatable.

I think CSS and SVG normally indicate whether a property is animatable
or not along with its definition? Maybe that's the best place to write this?

Nit: s/The introduce/The introduced/

> For transform functions this is a scalar or a list of scalars of 0.
> Examples of neutral elements for transform functions are
> ‘translate(0)’, ‘translate3d(0, 0, 0)’, ‘translateX(0)’,
> ‘translateY(0)’, ‘translateZ(0)’, ‘scale(0)’, ‘scaleX(0)’,
> ‘scaleY(0)’, ‘scaleZ(0)’, ‘rotate(0)’, ‘rotate3d(vx, vy, vz, 0)’
> (where v is a context dependent vector), ‘rotateX(0)’, ‘rotateY(0)’,
> ‘rotateZ(0)’, ‘skewX(0)’, ‘skewY(0)’, ‘matrix(0, 0, 0, 0, 0, 0)’,
> ‘matrix3d(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)’ and
> ‘perspective(0)’.

I haven't had a chance to go through the discussion between Cyril and
Olaf in detail but if I understand correctly, Cyril was arguing for the
neutral element for scale being scale(1). If that's the case, then I
also prefer that definition.

> Animations to or from the neutral element of additions ‘matrix’,
> ‘matrix3d’ and ‘perspective’ fall back to discrete animations (See
> Interpolation of Matrices).

I don't understand this sentence.

> SVG 1.1 Animation defines the ‘attributeName’ attribute to specify
> the name of the target attribute. For the presentation attributes
> ‘gradientTransform’ and ‘patternTransform’ it will also be possible
> to use the value ‘transform’. The same ‘transform’ property will get
> animated.

Why is this? This seems bad for forwards-compatibility.

Nit: I don't think gradientTransform and patternTransform are
presentation attributes since they don't refer to properties. Unless
they've been promoted in SVG 2, they're just regular attributes as far
as I can tell.

That's all for now. Thanks so much Dirk for all your hard work on this.

Best regards,

Brian Birtles

[1] http://www.w3.org/TR/SVG/animate.html#complexDistances

Received on Monday, 4 June 2012 02:06:05 UTC