[css-round-display][motion-path] Integrate polar positioning of CSS Round Display to Motion Path

[jihyerish]

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 (add < angle > as value)
• polar-distance + motion-offset => offset-distance
• polar-origin => offset-position
• polar-anchor => offset-anchor

My extra proposal(Not included in the resolution):

• 2d rotation transform extension + motion-rotation => offset-rotation

I wrote the draft [4] about that to discharge the resolution.
Are there any missing parts or incorrect things?

Properties have the following meanings:

• offset-path: define the path that an element can move along
• offset-position: define the initial position of the path
  • initial position: the position when "offset-distance: 0"
• offset-distance: set the position along the path
• offset-anchor: specify the origin of the element

There are some issues that I would like to discuss:

• Need for 'offset-position'
• Initial value of 'offset-rotation'

[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

[shans]

Looks like a clean merge.

I was wondering, based on figure 13, if it would be useful to allow offset-anchor to vary depending on offset-path (i.e. allow figure 13 to be generated without having to specify a different offset-anchor for each shape). This sounds hard, though.

For 'offset-rotation', I think that it's better to align with CSS3 values than maths (i.e. 0deg points north) but I don't feel strongly.

What's the issue that you'd like to discuss with regards to 'offset-position'?

[jihyerish]

What's the issue that you'd like to discuss with regards to 'offset-position'?

The path which the element is positioned along is specified by 'offset-path' property.
When < angle > is given to 'offset-path' , the path is defined as a straight line that has the degree of the specified angle.
The path has start point as the center of the containing block and its end point is on the edge of the containing block.

• start point and end point decide the position of the path in the containing block.

And initial position of the element along the path is the start point of the path.

After defining the path, we can use 'offset-position'.
offset-position is refering 'polar-origin' in polar positioning, so I defined 'offset-position' as specifying the initial position.

For example,

offset-path: 90deg;

the path starts at the center and ends at the middle of the right-side edge of the containing block.

then when I add

offset-position: 0% 50% ;

The path starts at the middle of the left-side edge and ends at the middle of the right-side edge of the containing block.
With this kind of uses, do you think 'offset-position' is useful?
Is offset-position defined properly?

[tabatkins]

For 'offset-rotation', I think that it's better to align with CSS3 values than maths (i.e. 0deg points north) but I don't feel strongly.

The question is a non-sequitur, as offset-rotation does not specify a direction, just a rotation. The only relevant question is whether the rotation is CW or CCW, and the correct answer is CW to match the entire rest of CSS. And I feel extremely strongly about this; we used to have linear-gradient() do the "mathy polar angles" thing and specifically switched it to bearing angles.

The path has start point as the center of the containing block

We resolved during the call that this was incorrect - the "auto" value for offset-position is just the current position of the element. In other words, this is a transform, and by default there's no initial repositioning; offset-position can specify one explicitly, tho. So to get the old sort of "polar positioning" you just need to specify offset-position: center; offset-path: 45deg;.

[jihyerish]

We resolved during the call that this was incorrect - the "auto" value for offset-position is just the current position of the element. In other words, this is a transform, and by default there's no initial repositioning;

I was a bit off base about offset-position. I'm glad that I know that : )

When offset-path with < angle > is specified for the element, the path starts at the element's current position and ends at the edge of the containing block.
Description for the starting point of the path in the spec is fixed like above.
Also, I fixed the meaning of "auto" value for offset-position.

[jihyerish]

On the telecon last week [1], we discussed this issue.
There were resolution about offset-position, offset-path and offset-rotation, so I updated the spec [2].

On top of that, it was resolved to move offset-* properties to Motion Path Spec and I'm assigned to ACTION-781 [3].
How could I start to move the integration from CSS Round Display to Motion Path?

So far, the changes from the Motion Path are as follows:

• Rename motion-path to offset-path
• Add < angle > and contain keyword to offset-path property to merge with polar-angle
• Add offset-position property for setting the initial position of the path
• Rename motion-offset to offset-distance for combining with polar-distance
• Add < size > to offset-distance
• Add offset-anchor property for specifying the origin point of the element
• Rename motion-rotation to offset-rotation

For offset-rotation, the definition would be [ auto | reverse ] || < angle >.
motion-rotation is defined as [ auto | reverse ] && <angle>, but I think offset-rotation: auto or offset-rotation: 180deg should be possible.
For example, figure 17 in [2], offset-rotation is specified with 45deg without auto or reverse.

Still, there are other issues that need to be discussed.
Would it be okay if I discuss the issues after moving offset- properties to Motion Path Spec?

[1] https://lists.w3.org/Archives/Public/www-style/2016Jun/0158.html
[2] https://drafts.csswg.org/css-round-display/#positioning-content
[3] https://www.w3.org/Style/CSS/Tracker/actions/781

[bradkemper]

Yes.

I agree that [ auto | reverse] && <angle> is better than only ever picking a keyword OR an angle. I think that should be mostly no controversial. offset-rotation: auto would be the same as offset-rotation: auto 0deg. I'm not sure we actually need reverse anymore, since offset-rotation: auto 180deg is simple enough, but I don't feel strongly about removing it.