W3C home > Mailing lists > Public > www-style@w3.org > July 2012

Re: [css3-transforms] interpolation of transform lists

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 19 Jul 2012 16:03:49 -0700
Message-ID: <CAAWBYDAgqACvvHhK0xO-=v2zV0N3K8Yj_rrXK7MBJE9W2ZU14w@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: www-style@w3.org
On Thu, Jul 19, 2012 at 2:38 PM, L. David Baron <dbaron@dbaron.org> wrote:
> http://dev.w3.org/csswg/css3-transforms/Overview.html#animation
> says something that's not compatible with earlier drafts of the
> transforms spec.  In particular, I'm concerned about the "is a
> derivative of a primitive" in:
>   # If from- and to-transform have the same number of transform
>   # functions, each transform function is a derivative of a
>   # primitive and each function pair is a derivative of the same
>   # primitive.
> and the later text:
>   # Transform functions not listed above are neither primitives nor
>   # derivatives and can neither be interpolated with transform
>   # functions of primitives listed above nor with itself. UAs have
>   # to follow the last rule on Interpolation of Transforms then.
>
> Earlier drafts said that any matched list of transform functions is
> interpolated function-by-function rather than via matrix
> interpolation.  The new draft adds this concept of primitives to say
> that some pairs of syntactically-different but semantically-similar
> functions (e.g., translate() and translateX()) can be considered
> equivalent for the purpose of this matching.  I think this is fine.
>
> But it also says that some transform functions:  in particular,
> perspective(), rotate3d(), matrix(), and matrix3d().  I could
> understand the desire to interpolate these (or maybe all of these
> except perspective()) as matrices, but it seems inappropriate for
> the presence of one of these in a transform list to force other
> items in that transform list into the matrix decomposition path,
> particularly if it's the other items that are changing in the
> animation.
>
> We're planning not to implement this as described in Gecko, but
> instead to consider all transform functions to be primitives (which
> is more compatible with the behavior prior to the introduction of
> the concept of primitives).

I agree with these changes.

In particular, I agree that if the only changed functions are things
that animate directly, that they should animate directly, regardless
of whatever else is in the list that didn't change.

If you have a large list of transform functions that are matched up in
function type, and, say, a translate() and a matrix3d() changed, would
you animate the two pieces accordingly, or mush them together into the
matrix path?

~TJ
Received on Thursday, 19 July 2012 23:04:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:57 GMT