[motion-path] Origin for motion paths?

Hi list,

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).

Cheers,

   -Shane

Received on Monday, 22 June 2015 03:35:30 UTC