- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 22 Jun 2015 12:19:35 -0700
- To: Shane Stephens <shans@google.com>
- Cc: "public-fx@w3.org" <public-fx@w3.org>
On Sun, Jun 21, 2015 at 8:34 PM, Shane Stephens <shans@google.com> 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
Received on Monday, 22 June 2015 19:20:23 UTC