W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2015

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 22 Jun 2015 12:19:35 -0700
Message-ID: <CAAWBYDAEzfWPu4p_QWNf-6srXY=jEfxtcTi+12JO2PyOsP2nWw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:54 UTC