Re: [motion-path] Origin for motion paths?

On Sun, Jun 21, 2015 at 8:34 PM, Shane Stephens <> wrote:
> Issue 5 of the motion-path specification deals with whether there needs to
> be an origin specified for element impacted by motion paths. Specifically:
> "Do we need to specify an origin of the element in motion so that it can be
> positioned accordingly before the motion? Something like motion-origin?
> Should we reuse transform-origin? (Probably not since the z coordinate
> doesn’t make any sense.)"
> The specification is not clear on the appropriate center, but our (Chrome’s)
> implementation currently centers the x and y coordinate parts of the
> transform-origin of the element on the path, and applies motion-rotation
> about this element. This gives reasonable default behavior for HTML.
> In contrast, centering on (0, 0) doesn’t generally provide good behavior
> (elements appear to leave the path and rotate oddly), but does match what is
> specified in SVG for animateMotion animations.
> I can see a few reasonable options here:
> (A) specify that (the 2D component of) transform-origin applies to motion,
> and leverage the fact that this property has different defaults in SVG and
> CSS. This would enable motion-path to work nicely in HTML and match
> animateMotion in SVG.
> (B) specify that motion-paths have a separate origin, motion-origin, which
> has defaults that match that of transform-origin.
> (C) take option (A), and reserve the right to add a motion-origin later
> which applies on top of transform-origin
> (D) take option (A), and reserve the right to add a motion-origin later
> which defaults to the computed value of transform-origin if not specified
> Any other ideas?
> Mainly what I’m after here is to get a sense for whether we think applying
> transform-origin is correct, and also for whether it seems worthwhile to
> specify a motion-origin now (as opposed to in a future level of the
> specification).

transform-origin desugars to a translate before/after the entire
transform list.  'motion' also desugars to a transform function in the
list (a motion() function), which appears somewhere in the final
transform list as well.  I think it's fine to have the motion() appear
within the transform-origin pair.


Received on Monday, 22 June 2015 19:20:23 UTC