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

Sent from my iPad

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

>>> On Jun 14, 2016, at 1:12 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> On Jun 13, 2016, at 2:00 AM, Jihye Hong <jh.hong@lge.com> 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.

Received on Tuesday, 14 June 2016 08:49:42 UTC