On Sun, Jun 21, 2015 at 8:34 PM, Shane Stephens <[email protected]> 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. ~TJ
