Re: [css-round-display] Positioning elements with polar positioning and absolute positioning

> On Nov 8, 2015, at 10:15 PM, Jihye Hong <jh.hong@lge.com> wrote:
> 
>> On Oct 24, 2015, at 1:43 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> However, there are many times when I have wanted to center in vertical
>> dimension only or horizontal dimension only. Especially vertical only. This
>> goes further beyond circular display applications, but we should consider it
>> so that we don't end up with multiple properties that do the same thing.
>> 
>> For instance, I recently had an image that was used to trigger a
>> date-picker for the text field (input) immediately to its left, while both
>> were surrounded by a span with 'position:relative'. I wanted the image to
>> appear over the field, equal distance from the top and bottom of the field
>> (and in from the right a short distance). I absolutely positioned it, but to
>> get it vertically centered, I had to know the height of the image and use
>> 'top'. It would have been much easier to use 'center-y:50%'.
>> 
>> Or consider a horizontal slider. If I want the indicator to line up with
>> the tick marks, I could just set 'center-x' to a percentage. 'center-x:0'
>> would put the center of the indicator all the way to the left, and
>> 'center-x:100%' would put it all the way to the right. And 'center-x:40%'
>> would put its center exactly lined up with the 40% tick mark.
> 
> We recently added the new property, 'polar-origin' to the CSS Round Display
> Draft [1]. The property defines the origin point of polar coordinates within
> the containing block area. 
> 
> It's possible to use 'polar-origin' property instead of 'position: polar'
> for indicating polar coordinates like ‘center' as you suggested. 

Actually, I misspoke during the telecon. I meant to say ‘polar-distance’ having a non-auto value to cause it to center (instead of ‘position:polar’, when the position property is ’absolute’ or ‘fixed’), when left, right, top, and bottom were all ‘auto’ (note, this is separate from my alternative ‘center’ property idea).

> But is it appropriate to use a property to switch entire coordinate system
> for positioning elements? I think there would be a situation with
> ‘polar-origin' being omitted.

Depends how you look at it. See below for how it would work.

> Also, 'polar-origin' makes possible to position elements with polar
> positioning and absolute positioning.
>  i) If you want to move an element horizontally or vertically and
> then adopt polar positioning,
>   give polar-origin non-auto value. 
>   
>   #item1 {
>     polar-origin: 0% 0%;
>     polar-distance: 10;
>     polar-angle: 90deg;
>   }/* item1 moves 10px rightward from the upper left corner of
> the containing block. */

This is using polar-* properties to simulate existing absolute positioning. Which is something I don’t like about it. We shouldn’t have multiple properties that do the same thing in slightly different ways. Also, you would need ‘polar-anchor:left top’ too, wouldn’t you?

P.S. You also left out ‘position:polar’, which I assume was unintentional.

> or
>  ii) If you want to position elements using polar positioning and
> then move it horizontally or vertically, specify position:polar or polar-origin: auto. Then use
> 'polar-angle' and 'polar-distance' to position elements in polar
> coordinates. And use 'left', 'top', 'right', and 'bottom' to specify
> horizontal and vertical offset.
>   But, even if 'left', 'top', 'right', and 'bottom' are
> supported by CSS Round Display Spec and the calculation of these value come
> after the calculation of 'polar-distance' and 'polar-angle', polar-*
> properties can't work together with 'left', 'top', 'right', and 'bottom'. 
>   That's because 'left', 'top', 'right', and 'bottom' specify
> how far an element's edges are from the padding edges of the containing
> block so that they make elements moves from edges of a containing block,
> whereas 'polar-distance' and 'polar-angle' make elements move from an origin
> of polar coordinates.

Just do the ‘left’, ‘top’, ‘right’, and 'bottom' calculations first. Then:

—To find the origin of the polar movement: If ‘polar-distance’ is not ‘auto’, then add ‘left’ (or negative ‘right’ if ‘left’ is ‘auto’, or 0 if they are both ‘auto’) and ‘top’ (or negative ‘bottom’ if ’top’ is ‘auto’, or 0 if they are both ‘auto’) to the horizontal center coordinate and vertical center coordinate (respectively) of the containing block. Essentially, ‘left’ and ’top’ take the place of the two numbers of polar-origin. They are offsets from the center of the containing block.

or, an alternative:

—To find the origin of the polar movement: If ‘polar-distance’ is not ‘auto’, then add ‘left’ to the horizontal center coordinate and subtract ‘right’ from it. Add ’top’ to the vertical center coordinate and subtract ‘bottom’ from it (treat ‘auto’ as 0 for these origin-finding calculations). This is very similar to above, but ‘left’ and ‘right’ can combine, and so can ’top’ and ‘bottom’.

or, a different alternative:

—To find the origin of the polar movement: If ‘polar-distance’ is not ‘auto’, position with ‘left’, ‘top’, ‘right’, and ‘bottom’. If they are all ‘auto’, but ‘polar-distance’ is not, then center the element in its containing block. Then move the center of the positioned element by the specified polar distance and angle. This makes polar movement more like a transform, but automatically defaults the origin to the center if ‘left’, ‘top’, ‘right', and 'bottom' are all 'auto'.

or, a different alternative, my favorite, using new ‘center’ properties (‘center-x’ and ‘center-y’, and shorthand ‘center’):

—To find the origin of the polar movement: position with ‘left’, ‘top’, ‘right’, and ‘bottom’. If ‘left’ and ‘right’ are both ‘auto’, then position with ‘center-x’ property’s value (‘center-x:50%’ would put the center of the element at the horizontal center of the containing block). If ‘top’ and ‘bottom’ are both ‘auto’, then position with ‘center-y’ property’s value (‘center-y:50%’ would put the center of the element at the vertical center of the containing block). Then move the center of the positioned element by the specified polar distance and angle. All horizontal and vertical positioning, including centering, is done with explicit dedicated properties, and polar movement is done from wherever it ends up as a result (not from any built-in centering).

> for example, 
> 
>   #item2 {
>     polar-origin: auto;
>     polar-distance: 10;
>     polar-angle: 90deg;
>     left: 10; /* moves 10px from where? an origin of polar
> coordinates or a left edge of containing block? */
>   }

left is still 10px from the left of the containing block, but the origin of the polar movement would be derived from that, using one of the 4 alternatives above.

>   
>   Therefore, in this case, we need to redefine meaning of
> ‘left' when using with polar coordinates

Other way around. Define the polar origin using the existing positioning properties, and possibly some new ones for centering.

> or define new properties move
> elements horizontally or vertically after polar positioning.

That seems redundant to me. Aside from new properties to move at an angle, and disabling of the existing positioning properties, polar positioning is just like absolute positioning, except for where you move from. We already have ways to move elements horizontally or vertically with absolute positioning. So ‘position:polar’ means that you are removing those way, and then adding them back in with ‘polar-origin’. 

Plus ‘position:polar’ doesn’t allow the positioned items to be ‘position:fixed’.

My last 2 alternatives would make polar positioning more like a transform. I guess in theory, it could even be something like this:

transform: polar(20deg, 75%)

That doesn’t include a way to do ‘polar-anchor’ or the ‘contain’ keyword, but I have already proposed something (in a different thread) that mostly eliminates the need for that. And I don’t think they work well as currently spec’ed anyway. But that’s a separate conversation.

Received on Saturday, 19 December 2015 01:46:52 UTC