W3C home > Mailing lists > Public > www-style@w3.org > June 2016

Re: [css-round-display][motion-path] Integrate polar positioning to the motion path spec

From: Brad Kemper <brad.kemper@gmail.com>
Date: Tue, 14 Jun 2016 02:30:42 -0700
Cc: www-style list <www-style@w3.org>
Message-Id: <84825C64-1665-4AC2-92FF-E0978B32C75A@gmail.com>
To: Jihye Hong <jh.hong@lge.com>

Sent from my iPad

On Jun 13, 2016, at 10:42 PM, Jihye Hong <jh.hong@lge.com> wrote:

>> On Jun 14, 2016, at 2:07 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> then we also need something like 'offset-rotation-anchor',
>> Or maybe 'offset-path-anchor', since it should also determine where the initial position of the path
>> aligns to the element.
> Is 'offset-path-anchor' different from 'offset-anchor'?
> As I understand it, 'offset-path-anchor' sets the initial position of the path and 'offset-anchor' sets the origin of
> the element which aligns on the path.

'offset-path-anchor' sets the initial position and rotation point of the path and 'offset-anchor' sets the point of the element which aligns to the offset-position point. 'Offset-anchor:auto' would make that alignment work the way 'background-position' does. 

> Do we need 'offset-path-anchor' as a separate property?

I think we do, as answered in the other email, if we want both those jobs done. Otherwise use it for only one of those: either always have the background-position behavior for aligning the element with the containing block, or always have the path start point and rotation be centered in the element. I think both things are about equally useful, but I care a little more about being able to pick the alignment point for occasionally deviating from background-position-like alignment.  

>>>> 2. Need for 'offset-origin'
>>>> 'offset-origin' can set the initial position of the path.
>>>> But in the specification of 'offset-path', the value types except for
>>>> <angle> already define the initial position for each case.
>>>> Therefore, 'offset-origin' is useful only when 'offset-path' is
>>>> specified with <angle> value type.
>>> It isn't useful for angle values. The origin of the element is wherever other positioning properties
>>> (including 'top', etc. or 'offset-position') put it. If all those positioning properties are 'auto',
>>> then the origin is wherever the element would have been if it wasn't positioned. When you want the
>>> origin to be in the middle of the containing block, you would use 'offset-position: 50% 50%' (or
>>> 'offset-position: center', etc. that computes to the same).
>>> And actually, for non-angle paths, the "initial position" refers to the position on the path, not the
>>> position of where that aligns with the element (see 'offset-path-anchor'), nor anything about its
>>> position in the containing block (top, right, bottom, left, and/or offset-position handle that). So
>>> I'm not sure what 'offset-origin' and "initial position" have to do with each other. "initial
>>> position" is only about where 'offset: distance:0' is on the path.
> You're right. I was confused about that.
> The "initial position" of the path isn't the same with the position specified with 'offset-origin'.
> 'offset-origin' ('offset-position') specifies the position of a path.

'offset-origin' ('offset-position') specifies the position of the element, prior to moving it along a path. And it isn't even required. It's a separate movement, which is additive to the path movement. The element could be positioned with 'top' and 'left', and should still be moved along a path from there. Or it could have initial values for all other positioning properties other than 'offset-distance' and 'offset-path', and it would start from its non-positioned spot and then position itself  'offset-distance' from there, along the 'offset-path'. 

Similarly, 'offset-origin' ('offset-position') could be used by itself, without any path movement added to it.

> The initial position of the path is defined differently by the type of value given to 'offset-path'.

Not exactly. The initial position refers to the position within the path (the top of a circle path, for instance), which aligns to the 'offset-anchor' (or maybe offset-path-anchor) in the element. 

> Then I would like to keep 'offset-origin' for defining the position of the path.

Do you mean offset-anchor? Transform-origin could also be used for this, since it would presumably be the rotation center too.

> And the initial position of the path when the path is specified in <angle> would be the same with the position specified
> by 'offset-origin'.

That doesn't make sense. What if offset-origin/position isn't used, or if you have position:relative? And actually, the initial position of the path doesn't matter with <angle>.  You move the whole element a distance along an angle. The path relative to the element doesn't change anything. 

>> Oh, and also, the initial value of 'offset-rotation' should be zero. It is weird to have to opt out of
>> a transformation, just because you are moving something along an angle or other path.
> I agree with that.
> But the initial value of 'motion-rotation'[1] in Motion Path is 'auto' and I referred to it.
> I'm not sure which is better, '0deg' or 'auto'.

0deg is better. 

Received on Tuesday, 14 June 2016 09:31:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:03 UTC