Re: [round-display] [motion-path] Orientation of elements due to merging polar positioning and motion path

> On Wed, May 18, 2016 05:47:53 +0000 Shane Stephens <shans@google.com> wrote:
>> On Wed, May 18, 2016 at 3:09 PM Brad Kemper <brad.kemper@gmail.com> wrote:
>>> On May 17, 2016, at 5:05 PM, Florian Rivoal <florian@rivoal.net> wrote:
>>>> On May 17, 2016, at 12:08, Brad Kemper <brad.kemper@gmail.com> wrote:
>>>>
>>>> Round Display has 'transform: rotate(<angle> | polar-angle | polar-angle-reverse)',
>>>> which allows the standard rotate transformation to be derived from the angle of the "path" (the path was a ray,
whose angle was called polar-angle).
>>>> I think we should extend this to work with motion path too, to consider the angle at whatever point of the path the
element is on. The syntax would
>>>> be 'transform: rotate(<angle> | polar-angle | polar-angle-reverse)', With the path keyword in there, the path angle
at that point is just added to
>>>> whatever angle is specified, to determine its final rotation.
>>>>
>>>> This also gives you 'transform-origin' for free. You don't need 'motion-origin' to replicate that functionality.

We need 'motion-origin'(which will be changed to 'offset-anchor') separately from 'transform-origin'.
'motion-origin' is required not only for rotating the element. It's also for setting the origin point in the element's
content area which is placed at different positions along the motion path.
In an example of the 'motion-rotation', the red dot is the origin point in the element's content area.
I thought we agreed with this at f2f.

>>> I thought we would be dropping transform: rotate(polar-angle) and transform: rotate(polar-angle-reverse)
>> We didn't resolve one way or another about those.
>
> We resolved to accept Fantasai's proposal, which (if I recall correctly) was to drop transform: rotate(polar-angle).

Actually, we don't clearly decide yet whether dropping motion-rotation or dropping transform: rotate(<angle> |
polar-angle | polar-angle-reverse).[1]
But I think 'motion-rotation' could be (without concerning the change of the naming):

  motion-rotation: [[ auto | reverse | center ]? <angle>?]!

'motion-rotation' rotates the element by the angle specified in the parameter about the origin of the element while
positioning along the motion path.
The origin of the element is set by 'offset-anchor' ('motion-origin').

Initial value is 0deg which matches the default for SVG motion along a path.
And when the element is a text, it's natural not to rotate it for the readability.[2]

Values have the following meanings:

  - auto :
    The element is rotated by the angle of the directional tangent vector of the motion path.

  - reverse:
    The element is rotated by (auto + 180) degrees.

  - center:
    The element is rotated perpendicular to the directional tangent vector of the motion path.
    'center' is necessary in polar positioning because there are many use cases which show the elements rotated toward
the origin of polar coordinates. [3]
    When I suggested the extension of 2d rotate transform in CSS Round Display, its purpose was rotating the element
toward to the origin of the coordinates (different from the origin of the element)
    with the keyword value.
    I think the need of this was agreed and there were no objections.


thanks,
Jihye


[1] https://logs.csswg.org/irc.w3.org/css/2016-05-10/#e683765
[2] http://anawhj.github.io/jRound/demo/calendar/index.html
[3] http://anawhj.github.io/jRound/demo/facebook/circle.html

Received on Wednesday, 18 May 2016 09:49:48 UTC