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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Jihye Hong
Hi,
At the SF f2f, there was an resolution [1][2] to integrate polar positioning
to Motion Path [3].
Some properties from CSS Round Display are merged into Motion Path:
   * polar-angle + motion-path => offset-path
   * polar-distance + motion-offset => offset-distance
   * polar-origin => offset-origin
   * polar-anchor => offset-anchor
   
My extra proposal(Not included in the resolution):
   * 2d rotation transform extension + motion-rotation => offset-rotation

I just wrote the draft [4] about that to discharge the resolution.
Could you review the draft and check if there are any missing parts or
incorrect things about the resolution?

Also, while writing it I ran into some issues that we need to discuss.

1. Proper term of the 'path'
'motion-path' is changed to 'offset-path', so it is not just about motion.
Defining the path is describing the possible position for the element.
Is it okay to use the term 'path' instead of 'motion path'?

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.

There could be some solution about this:
  i. Keep 'offset-origin' and make it works only when <angle> type value is
given to 'offset-path'.
  ii. Define the initial position of the path as the center of the
containing block when the path is defined by <angle> value and drop
'offset-origin'.

Which would be better?

3. The direction where 0deg points
When 'offset-path' is given to 0deg, the path points the direction of the
positive y-axis.
But in the specification of 'motion-rotation', 0deg means the right side in
the direction of the positive x-axis. I know that this is the common way in
mathematical theory but in the CSS Value Spec [5], 0deg is defined as the
upside direction.
So I think it would be better to specify 0deg as the direction of the
positive y-axis.

Thanks,
Jihye

[1] https://lists.w3.org/Archives/Public/www-style/2016May/0233.html
[2]
https://lists.w3.org/Archives/Public/www-archive/2016May/att-0000/whiteboard
.jpg
[3] https://drafts.fxtf.org/motion-1/ 
[4] https://drafts.csswg.org/css-round-display/#positioning-content
[5] https://drafts.csswg.org/css-values-3/#angle-value 


Reply | Threaded
Open this post in threaded view
|

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

Brad Kemper



Brad Kemper

> On Jun 13, 2016, at 2:00 AM, Jihye Hong <[hidden email]> wrote:
>
> Hi,
> At the SF f2f, there was an resolution [1][2] to integrate polar positioning
> to Motion Path [3].
> Some properties from CSS Round Display are merged into Motion Path:
>   * polar-angle + motion-path => offset-path
>   * polar-distance + motion-offset => offset-distance
>   * polar-origin => offset-origin
>   * polar-anchor => offset-anchor
>
> My extra proposal(Not included in the resolution):
>   * 2d rotation transform extension + motion-rotation => offset-rotation

I think that was discussed. There is still some controversy over whether this needs to be a separate property, or still integrated into transforms.

If we have a 'offset-rotation' ins treat of using transforms, then we also need something like 'offset-rotation-anchor', the equivalent of 'motion-origin' that is mentioned in the motion path FPWG. We can't really use offset-anchor for both without getting unwanted side effects.

> I just wrote the draft [4] about that to discharge the resolution.
> Could you review the draft and check if there are any missing parts or
> incorrect things about the resolution?

I didn't see anything in there about 'offset-position', which was part of the same resolution. It is supposed to be a means of positioning that is similar to how background-position works.  

You have 'offset-anchor' described as "Defines an origin of the element in the path." But as discussed, it should work with offset-position to set the alignment point of the element ('auto' for 'offset-position:<percentage>' would copy percentages from offset-position) to set the alignment point in the element to align to the offset-position point in the containing block).

> Also, while writing it I ran into some issues that we need to discuss.
>
> 1. Proper term of the 'path'
> 'motion-path' is changed to 'offset-path', so it is not just about motion.
> Defining the path is describing the possible position for the element.
> Is it okay to use the term 'path' instead of 'motion path'?

Yes. I think we all agreed on that. Motion only exists if there is animation. When 'offset-path' is an angle, the path is a straight line, a ray.

> 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).

> There could be some solution about this:
>  i. Keep 'offset-origin' and make it works only when <angle> type value is
> given to 'offset-path'.
>  ii. Define the initial position of the path as the center of the
> containing block when the path is defined by <angle> value and drop
> 'offset-origin'
>

> Which would be better?

iii. Drop offset-origin. It's useless. I think the minutes might be wrong or perhaps fantasai misspoke when she mentioned it, because everywhere it's mentioned it should be 'offset-position'. The similar 'background-position' doesn't have it need anything like offset-origin (background-origin is unrelated).

> 3. The direction where 0deg points
> When 'offset-path' is given to 0deg, the path points the direction of the
> positive y-axis.
> But in the specification of 'motion-rotation', 0deg means the right side in
> the direction of the positive x-axis. I know that this is the common way in
> mathematical theory but in the CSS Value Spec [5], 0deg is defined as the
> upside direction.
> So I think it would be better to specify 0deg as the direction of the
> positive y-axis.

Yes. All other specs that use angles, including linear-gradient, have 0deg = north.  

You should clarify the airplane example by showing what the unrotated plane looks like (with its nose at the top).

Reply | Threaded
Open this post in threaded view
|

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

Brad Kemper





Brad Kemper
> On Jun 13, 2016, at 9:11 AM, Brad Kemper <[hidden email]> wrote:
>
> If we have a 'offset-rotation' ins treat of using transforms,

s/ins treat of/instead of

> 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.

> the equivalent of 'motion-origin' that is mentioned in the motion path FPWG.

Or we could just use transform-origin, and ignore the third value of it.

> We can't really use offset-anchor for both without getting unwanted side effects.

...

> You have 'offset-anchor' described as "Defines an origin of the element in the path." But as discussed, it should work with offset-position to set the alignment point of the element ('auto' for 'offset-position:<percentage>' would copy percentages from offset-position) to set the alignment point in the element to align to the offset-position point in the containing block).
>
>> 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.
...

> Yes. All other specs that use angles, including linear-gradient, have 0deg = north.  
>
> You should clarify the airplane example by showing what the unrotated plane looks like (with its nose at the top).

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.

This would change how "initial direction" is described. It should be called "initial rotation", and it should only affect things with 'offset-rotation:auto'.


Reply | Threaded
Open this post in threaded view
|

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

Jihye Hong
In reply to this post by Brad Kemper
> On Jun 14, 2016, at 1:12 AM, Brad Kemper <[hidden email]> wrote:
> > On Jun 13, 2016, at 2:00 AM, Jihye Hong <[hidden email]> wrote:
> >
> > At the SF f2f, there was an resolution [1][2] to integrate polar positioning to Motion Path [3].
> > Some properties from CSS Round Display are merged into Motion Path:
> >   * polar-angle + motion-path => offset-path
> >   * polar-distance + motion-offset => offset-distance
> >   * polar-origin => offset-origin
> >   * polar-anchor => offset-anchor
> >
> > My extra proposal(Not included in the resolution):
> >   * 2d rotation transform extension + motion-rotation => offset-rotation
>
> I think that was discussed. There is still some controversy over whether this needs to be a separate property, or
still integrated into transforms.
>
> If we have a 'offset-rotation' ins treat of using transforms, then we also need something like
'offset-rotation-anchor', the equivalent of 'motion-origin' that is mentioned in the motion path FPWG.
> We can't really use offset-anchor for both without getting unwanted side effects.

'offset-anchor' in the CSS Round Display works as 'motion-origin'. It specifies the origin of the element.
In the plane image [5], the position of a red dot is decided by 'offset-anchor'.
This was the part of the resolution at the SF f2f [6].
 
> I didn't see anything in there about 'offset-position', which was part of the same resolution. It is supposed to be a
means of positioning that is similar to how background-position works.
> You have 'offset-anchor' described as "Defines an origin of the element in the path."
> But as discussed, it should work with offset-position to set the alignment point of the element ('auto' for
'offset-position:<percentage>' would copy percentages from offset-position)
> to set the alignment point in the element to align to the offset-position point in the containing block).

The name of the property which specifies the initial position of the path was suggested 'offset-origin' or
'offset-position' [2].
As you mentioned, when the property is specified with 'offset-anchor' to an element, it works similar to how
'background-position' works.
I wrote the property as 'offset-origin' instead of 'offset-position'.

For example,

<style>
#one {
  offset-origin: top left;
  offset-anchor: auto;
  offset-path: 90deg;
  offset-distance: 0px;
}
#two {
  offset-origin: top right;
  offset-anchor: auto;
  offset-path: 90deg;
  offset-distance: 0px;
}
#three {
  offset-origin: top left;
  offset-anchor: top right;
  offset-path: 90deg;
  offset-distance: 0px;
}
</style>

<div style="width: 100px; height: 100px;">
  <div id="one" style="width: 50px; height: 50px;"></div>
  <div id="two" style="width: 50px; height: 50px;"></div>
  <div id="three" style="width: 50px; height: 50px;"></div>
</div>

For #one, its upper left corner is positioned to the upper left corner of the containing block.
The upper right corner of #two is positioned to the upper right corner of the containing block.
But upper right corner of #three is positioned to the upper left corner of the containing block.

> > 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.

I guess maybe you are confusing between 'offset-origin' and 'offset-anchor'.
'offset-anchor' sets the origin of the element.

'offset-origin'('offset-position') doesn't matter with the origin of the element. It decides the initial position of the
path.
When 'offset-origin' and 'offset-path' with <angle> is specified in an element, the position given by 'offset-origin'
works as the origin point of the coordinate system.


> 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).

Yes, 'offset-position' above is the same with 'offset-origin' that I mentioned and in the latest CSS Round Display spec
draft.

> > There could be some solution about this:
> >  i. Keep 'offset-origin' and make it works only when <angle> type value is given to 'offset-path'.
> >  ii. Define the initial position of the path as the center of the containing block when the path is defined by
<angle> value and drop 'offset-origin'
> >
> > Which would be better?
>
> iii. Drop offset-origin. It's useless. I think the minutes might be wrong or perhaps fantasai misspoke when she
mentioned it, because everywhere it's mentioned it should be 'offset-position'.
> The similar 'background-position' doesn't have it need anything like offset-origin (background-origin is unrelated).

I thought the property was mentioned as 'offset-origin' more than 'offset-position', so I wrote the spec draft with
'offset-origin'.
But I'm open to change the name if 'offset-position' is more appropriate for it.

> > 3. The direction where 0deg points
> > When 'offset-path' is given to 0deg, the path points the direction of the positive y-axis.
> > But in the specification of 'motion-rotation', 0deg means the right side in the direction of the positive x-axis. I
know that this is the
> > common way in mathematical theory but in the CSS Value Spec [5], 0deg is defined as the upside direction.
> > So I think it would be better to specify 0deg as the direction of the positive y-axis.
>
> Yes. All other specs that use angles, including linear-gradient, have 0deg = north.
>
> You should clarify the airplane example by showing what the unrotated plane looks like (with its nose at the top).

Thank you for the opinion. I added an example about the plane positioned on the path without rotation.

= Jihye

[1] https://lists.w3.org/Archives/Public/www-style/2016May/0233.html 
[2] https://lists.w3.org/Archives/Public/www-archive/2016May/att-0000/whiteboard.jpg 
[3] https://drafts.fxtf.org/motion-1/ 
[4] https://drafts.csswg.org/css-round-display/#positioning-content 
[5] https://drafts.csswg.org/css-round-display/images/plane.svg 
[6] https://log.csswg.org/irc.w3.org/css/2016-05-10/#e683750 


Reply | Threaded
Open this post in threaded view
|

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

Jihye Hong
In reply to this post by Brad Kemper
> On Jun 14, 2016, at 2:07 AM, Brad Kemper <[hidden email]> 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.

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

> >> 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.
The initial position of the path is defined differently by the type of value given to 'offset-path'.

Then I would like to keep 'offset-origin' for defining the position of the path.
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'.

> 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'.

= Jihye

[1] https://www.w3.org/TR/motion-1/#propdef-motion-rotation 


Reply | Threaded
Open this post in threaded view
|

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

Brad Kemper
In reply to this post by Jihye Hong



Sent from my iPad

On Jun 13, 2016, at 7:57 PM, Jihye Hong <[hidden email]> wrote:

>>> On Jun 14, 2016, at 1:12 AM, Brad Kemper <[hidden email]> wrote:
>>> On Jun 13, 2016, at 2:00 AM, Jihye Hong <[hidden email]> wrote:
>>>
>>> At the SF f2f, there was an resolution [1][2] to integrate polar positioning to Motion Path [3].
>>> Some properties from CSS Round Display are merged into Motion Path:
>>>  * polar-angle + motion-path => offset-path
>>>  * polar-distance + motion-offset => offset-distance
>>>  * polar-origin => offset-origin
>>>  * polar-anchor => offset-anchor
>>>
>>> My extra proposal(Not included in the resolution):
>>>  * 2d rotation transform extension + motion-rotation => offset-rotation
>>
>> I think that was discussed. There is still some controversy over whether this needs to be a separate property, or
>> still integrated into transforms.
>>
>> If we have a 'offset-rotation' ins treat of using transforms, then we also need something like
>> 'offset-rotation-anchor', the equivalent of 'motion-origin' that is mentioned in the motion path FPWG.
>> We can't really use offset-anchor for both without getting unwanted side effects.
>
> 'offset-anchor' in the CSS Round Display works as 'motion-origin'. It specifies the origin of the element.
> In the plane image [5], the position of a red dot is decided by 'offset-anchor'.
> This was the part of the resolution at the SF f2f [6].

It was a detail that needs to be rethought somewhat, since that resolution also affected the property formerly known as polar-anchor, which was the one that set the point of the element that aligned with the polar-origin point (now morphed into offset-position) of the containing block.

Setting the alignment point for offset-position (which is most like background-position when that alignment point has an initial value of 'auto'), is ***a whole different concern*** than setting the point that the path starts on and rotates around, and the two concerns would interfere with each other if they were the same property. Consider the following:

offset-position: 0 50%;
offset-anchor: 100% 50%;

Here I am using 'offset-anchor' to make the vertical middle of the right side of the element align with the vertical middle of the left edge of the containing block. I could have used other positioning properties, but let's assume doing it this way was the easiest way to animate the position the way I wanted from this starting point.

Now I also want to have it moved halfway around a 100px circle (assume this will be animated in other rules), so I add this:

offset-path:  circle(100px);
offset-distance:50%;
offset-rotation:auto;

But uh oh! Because I already set offset-anchor, which means that the top middle of the circle path is going to start at a point at the vertical middle of the right side of the element. I really wanted it to start at the horizontal-middle of the bottom of the element. But I can't change offset-anchor to do that without messing up how I was using it to interact with offset-position. As a result, instead of the element following along the path while completely outside of it, it is now going to have its right side centered on the path, making a much tighter turn and ending up in a different position.

I'd rather have 'transform-origin' do the thing that is exactly like 'transform-origin'. If I can't have that, then offset-rotation-anchor.

>> I didn't see anything in there about 'offset-position', which was part of the same resolution. It is supposed to be a
>> means of positioning that is similar to how background-position works.
>> You have 'offset-anchor' described as "Defines an origin of the element in the path."
>> But as discussed, it should work with offset-position to set the alignment point of the element ('auto' for
>> 'offset-position:<percentage>' would copy percentages from offset-position)
>> to set the alignment point in the element to align to the offset-position point in the containing block).
>
> The name of the property which specifies the initial position of the path was suggested 'offset-origin' or
> 'offset-position' [2].
> As you mentioned, when the property is specified with 'offset-anchor' to an element, it works similar to how
> 'background-position' works.
> I wrote the property as 'offset-origin' instead of 'offset-position'.

I see. Origin and anchor are such similar ideas, that it is very confusing having them mean such different things in the same spec, and trying to keep straight which is which. Especially since 'transform-origin' uses the word "origin" to describe what you are calling an anchor.

Whereas "offset-position" shares a word with "background-position" that it is very similar to. It makes it really easy to remember that it is the one that is similar to background-position for moving stuff around, and not the thing that sets an alignment point. I don't have to go through the slow exercise of trying to remember which is which whenever I see "origin" or "anchor".  

> For example,
>
> <style>
> #one {
>  offset-origin: top left;
>  offset-anchor: auto;
>  offset-path: 90deg;
>  offset-distance: 0px;
> }
> #two {
>  offset-origin: top right;
>  offset-anchor: auto;
>  offset-path: 90deg;
>  offset-distance: 0px;
> }
> #three {
>  offset-origin: top left;
>  offset-anchor: top right;
>  offset-path: 90deg;
>  offset-distance: 0px;
> }
> </style>
>
> <div style="width: 100px; height: 100px;">
>  <div id="one" style="width: 50px; height: 50px;"></div>
>  <div id="two" style="width: 50px; height: 50px;"></div>
>  <div id="three" style="width: 50px; height: 50px;"></div>
> </div>
>
> For #one, its upper left corner is positioned to the upper left corner of the containing block.
> The upper right corner of #two is positioned to the upper right corner of the containing block.
> But upper right corner of #three is positioned to the upper left corner of the containing block.

Yea, I get that. I just didn't realize previously that offset-origin was meant as an alternative name for offset-position. I think that has more to do with the previous name (polar-origin) than it does with choosing an easy-to-understand property name.

>>> 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.
>
> I guess maybe you are confusing between 'offset-origin' and 'offset-anchor'.

No, I just thought you were including an additional way of setting the pre-path position. I meant we wouldn't need offset-position AND offset-origin.

> 'offset-anchor' sets the origin of the element.

Please don't make my head explode. That isn't how you used the word "origin" before. I have a hard enough time with those two words, without being told that "anchor sets the origin" or "origin sets the anchor."

> 'offset-origin'('offset-position') doesn't matter with the origin of the element. It decides the initial position of the
> path.

initial position of the element, you mean? The initial start of the path (relative to the element) is set by 'offset-anchor', based on everything you've said so far.

> When 'offset-origin' and 'offset-path' with <angle> is specified in an element, the position given by 'offset-origin'
> works as the origin point of the coordinate system.

We don't need to talk about coordinate systems. 'Offset-origin/position' determines the position of the element prior to moving  it along a path or angle. It is simpler to describe it this way, than to speak of new coordinate systems.

>> 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).
>
> Yes, 'offset-position' above is the same with 'offset-origin' that I mentioned and in the latest CSS Round Display spec draft.

Got it.

>>> There could be some solution about this:
>>> i. Keep 'offset-origin' and make it works only when <angle> type value is given to 'offset-path'.
>>> ii. Define the initial position of the path as the center of the containing block when the path is defined by
>>> <angle> value and drop 'offset-origin'
>>>
>>> Which would be better?
>>
>> iii. Drop offset-origin. It's useless. I think the minutes might be wrong or perhaps fantasai misspoke when she
>> mentioned it, because everywhere it's mentioned it should be 'offset-position'.
>> The similar 'background-position' doesn't have it need anything like offset-origin (background-origin is unrelated).
>
> I thought the property was mentioned as 'offset-origin' more than 'offset-position', so I wrote the spec draft with
> 'offset-origin'.
> But I'm open to change the name if 'offset-position' is more appropriate for it.

God, yes, please. It would alleviate much of the Alice in Wonderland aspect of our conversations, and would be 1000 times more clear.

>>> 3. The direction where 0deg points
>>> When 'offset-path' is given to 0deg, the path points the direction of the positive y-axis.
>>> But in the specification of 'motion-rotation', 0deg means the right side in the direction of the positive x-axis. I
>>> know that this is the
>>> common way in mathematical theory but in the CSS Value Spec [5], 0deg is defined as the upside direction.
>>> So I think it would be better to specify 0deg as the direction of the positive y-axis.
>>
>> Yes. All other specs that use angles, including linear-gradient, have 0deg = north.
>>
>> You should clarify the airplane example by showing what the unrotated plane looks like (with its nose at the top).
>
> Thank you for the opinion. I added an example about the plane positioned on the path without rotation.

No problem.

PS. An unrelated problem: 'offset-path: <inset()>' seems weird here. Assuming that the reference box is the containing block (the spec should say, and doesn't, but it would make sense for percentages I think), you'd have a path that was inset from that, but then aligned to the positioned element itself. That doesn't seem super useful. I think have a basic shape of <rect(width,height)>, and maybe <square(width)> too, would be better.
Reply | Threaded
Open this post in threaded view
|

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

Brad Kemper
In reply to this post by Jihye Hong



Sent from my iPad

On Jun 13, 2016, at 10:42 PM, Jihye Hong <[hidden email]> wrote:

On Jun 14, 2016, at 2:07 AM, Brad Kemper <[hidden email]> 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. 

Reply | Threaded
Open this post in threaded view
|

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

Jihye Hong
> On Jun 14, 2016, at 6:31 PM, Brad Kemper <[hidden email]> wrote:
>
>> On Jun 13, 2016, at 10:42 PM, Jihye Hong <[hidden email]> wrote:
>>
>>
>> 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.

You mean you want to rotate the whole path with 'offset-path-anchor'?
If you want to rotate the element, 'offset-anchor' is enough for that.
The point of the element specified by 'offset-anchor' is used to align the element on the path and also could be the rotation point for rotating the element.

But I think 'offset-path-anchor' for setting the initial position of the path is meaningful, because the initial position of the path is static value defined in 'offset-path' specification.

>> 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.

I think it would be better to discuss about this on telecon this week.
I would like to know the opinion of editors of Motion Path when they wrote about 'motion-rotation' and its initial value.

= Jihye


Reply | Threaded
Open this post in threaded view
|

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

Jihye Hong
In reply to this post by Brad Kemper
> On Jun 14, 2016, at 5:49 PM, Brad Kemper < [hidden email] > wrote:
>
> On Jun 13, 2016, at 7:57 PM, Jihye Hong <[hidden email]> wrote:
>
> >>> On Jun 14, 2016, at 1:12 AM, Brad Kemper <[hidden email]> wrote:
> >>> On Jun 13, 2016, at 2:00 AM, Jihye Hong <[hidden email]> wrote:
> >>>

> >> I didn't see anything in there about 'offset-position', which was
> >> part of the same resolution. It is supposed to be a means of positioning that is similar to how
> background-position works.
> >> You have 'offset-anchor' described as "Defines an origin of the element in the path."
> >> But as discussed, it should work with offset-position to set the
> >> alignment point of the element ('auto' for
> >> 'offset-position:<percentage>' would copy percentages from offset-position) to set the alignment
> point in the element to align to the offset-position point in the containing block).
> >
> > The name of the property which specifies the initial position of the
> > path was suggested 'offset-origin' or 'offset-position' [2].
> > As you mentioned, when the property is specified with 'offset-anchor'
> > to an element, it works similar to how 'background-position' works.
> > I wrote the property as 'offset-origin' instead of 'offset-position'.
>
> I see. Origin and anchor are such similar ideas, that it is very confusing having them mean such
> different things in the same spec, and trying to keep straight which is which. Especially since
> 'transform-origin' uses the word "origin" to describe what you are calling an anchor.
>
> Whereas "offset-position" shares a word with "background-position" that it is very similar to. It
> makes it really easy to remember that it is the one that is similar to background-position for moving
> stuff around, and not the thing that sets an alignment point. I don't have to go through the slow
> exercise of trying to remember which is which whenever I see "origin" or "anchor".

I know that you have had hard time in between 'origin' and 'anchor', and I think other people also may confuse of them.
SO, let's change 'offset-origin' to 'offset-position'! :)

> > 'offset-origin'('offset-position') doesn't matter with the origin of
> > the element. It decides the initial position of the path.
>
> initial position of the element, you mean? The initial start of the path (relative to the element) is
> set by 'offset-anchor', based on everything you've said so far.

What I meant is, 'offset-position' decides the initial position of the path.

In the specification of "offset-path"[1] (which refers 'motion-path'), "initial position" for the path which is the same
when 'offset-distance' is 0 is already defined.
So 'offset-position: auto' follows the definition in [1], the initial position sets to the specified position
differently according to the type of value for 'offset-path'.


> > When 'offset-origin' and 'offset-path' with <angle> is specified in an element, the position given
> by 'offset-origin'
> > works as the origin point of the coordinate system.
>
> We don't need to talk about coordinate systems. 'Offset-origin/position' determines the position of
> the element prior to moving  it along a path or angle. It is simpler to describe it this way, than to
> speak of new coordinate systems.

I agree with that.


= Jihye

[1] https://drafts.csswg.org/css-round-display/#initial-position 


Reply | Threaded
Open this post in threaded view
|

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

Brad Kemper
In reply to this post by Jihye Hong


On Jun 19, 2016, at 11:36 PM, Jihye Hong <[hidden email]> wrote:

>> On Jun 14, 2016, at 6:31 PM, Brad Kemper <[hidden email]> wrote:
>>
>>> On Jun 13, 2016, at 10:42 PM, Jihye Hong <[hidden email]> wrote:
>>>
>>>
>>> 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.
>
> You mean you want to rotate the whole path with 'offset-path-anchor'?

No, not at all.

> If you want to rotate the element, 'offset-anchor' is enough for that.

Not if it is doing double duty as an alignment point for offset-position/origin already.

> The point of the element specified by 'offset-anchor' is used to align the element on the path and also could be the rotation point for rotating the element.

The path has no position. The element has a starting position, which the path should align to somehow, and then the element should be moved some distance along that path.

If you are suggesting that the starting position (as set by offset-position/origin, or 'top' et al, or by its initial static position) should be ignored, and the element should just jump to the beginning of a path that is somehow aligned to the containing block, then I definitely do not agree with that. The path should be aligned to the element, not the other way around. Otherwise the other positioning properties (even static) all become meaningless.

> But I think 'offset-path-anchor' for setting the initial position of the path is meaningful, because the initial position of the path is static value defined in 'offset-path' specification.
>
>>> 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.
>
> I think it would be better to discuss about this on telecon this week.
> I would like to know the opinion of editors of Motion Path when they wrote about 'motion-rotation' and its initial value.
>
> = Jihye
>

Reply | Threaded
Open this post in threaded view
|

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

Brad Kemper
In reply to this post by Jihye Hong


On Jun 20, 2016, at 12:04 AM, Jihye Hong <[hidden email]> wrote:

>> On Jun 14, 2016, at 5:49 PM, Brad Kemper < [hidden email] > wrote:
>>
>> On Jun 13, 2016, at 7:57 PM, Jihye Hong <[hidden email]> wrote:
>>
>>>>> On Jun 14, 2016, at 1:12 AM, Brad Kemper <[hidden email]> wrote:
>>>>> On Jun 13, 2016, at 2:00 AM, Jihye Hong <[hidden email]> wrote:
>
>>>> I didn't see anything in there about 'offset-position', which was
>>>> part of the same resolution. It is supposed to be a means of positioning that is similar to how
>> background-position works.
>>>> You have 'offset-anchor' described as "Defines an origin of the element in the path."
>>>> But as discussed, it should work with offset-position to set the
>>>> alignment point of the element ('auto' for
>>>> 'offset-position:<percentage>' would copy percentages from offset-position) to set the alignment
>> point in the element to align to the offset-position point in the containing block).
>>>
>>> The name of the property which specifies the initial position of the
>>> path was suggested 'offset-origin' or 'offset-position' [2].
>>> As you mentioned, when the property is specified with 'offset-anchor'
>>> to an element, it works similar to how 'background-position' works.
>>> I wrote the property as 'offset-origin' instead of 'offset-position'.
>>
>> I see. Origin and anchor are such similar ideas, that it is very confusing having them mean such
>> different things in the same spec, and trying to keep straight which is which. Especially since
>> 'transform-origin' uses the word "origin" to describe what you are calling an anchor.
>>
>> Whereas "offset-position" shares a word with "background-position" that it is very similar to. It
>> makes it really easy to remember that it is the one that is similar to background-position for moving
>> stuff around, and not the thing that sets an alignment point. I don't have to go through the slow
>> exercise of trying to remember which is which whenever I see "origin" or "anchor".
>
> I know that you have had hard time in between 'origin' and 'anchor', and I think other people also may confuse of them.
> SO, let's change 'offset-origin' to 'offset-position'! :)

Thank you! 😀

>>> 'offset-origin'('offset-position') doesn't matter with the origin of
>>> the element. It decides the initial position of the path.
>>
>> initial position of the element, you mean? The initial start of the path (relative to the element) is
>> set by 'offset-anchor', based on everything you've said so far.
>
> What I meant is, 'offset-position' decides the initial position of the path.

How? Offset position is only a length, not a point. It is a distance along the path, not the location of the path (nor a path point) relative to the element.

> In the specification of "offset-path"[1] (which refers 'motion-path'), "initial position" for the path

No, the "initial position" is a point on the path, not on the element. For instance, for circle(), is is a point at the very top center of the circle (obtusely described as "by the point where a virtual tangent to the circle/ellipse would reach the top vertical position."*). It doesn't say which point in the element aligns to that path point.

> which is the same
> when 'offset-distance' is 0 is already defined.

For non-straight paths of more than 0 distance and non-zero rotation, you also need to know where that initial position on the path aligns to the element, because different points yield different results. Are you assuming it is the center of the element?

> So 'offset-position: auto' follows the definition in [1], the initial position sets to the specified position
> differently according to the type of value for 'offset-path'.
>
>
>>> When 'offset-origin' and 'offset-path' with <angle> is specified in an element, the position given
>> by 'offset-origin'
>>> works as the origin point of the coordinate system.
>>
>> We don't need to talk about coordinate systems. 'Offset-origin/position' determines the position of
>> the element prior to moving  it along a path or angle. It is simpler to describe it this way, than to
>> speak of new coordinate systems.
>
> I agree with that.

Cool.

> = Jihye
>
> [1] https://drafts.csswg.org/css-round-display/#initial-position 
>
* I'm not sure what tangents have to do with it. A tangent is a line with an infinite number of points, each of which has a position.  I'm assuming we are talking about the point at which the tangent touches the circle. But that could just be described as "the point on the circle/ellipse perimeter that reaches the top vertical position." And "top vertical" is redundant. "Top" already implies vertical, since z-axis has nothing to do with a 2-dimensional path.

And how can you be following the path, if the direction is 90deg from the top of the circle?