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: Mon, 13 Jun 2016 09:11:54 -0700
Message-Id: <2617F3E4-3B7F-44F5-9834-837FCA2F558A@gmail.com>
To: www-style list <www-style@w3.org>, jh.hong@lge.com

Brad Kemper

> On Jun 13, 2016, at 2:00 AM, Jihye Hong <jh.hong@lge.com> 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).

> 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 
Received on Monday, 13 June 2016 16:12:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:47 UTC