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

Sent from my iPad
> On Dec 21, 2015, at 6:53 PM, Florian Rivoal <florian@rivoal.net> wrote:
> 
> 
>> On Dec 19, 2015, at 10:46, Brad Kemper <brad.kemper@gmail.com> wrote:
>> 
>> 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).
> 
> [...]
> 
>> Plus ‘position:polar’ doesn’t allow the positioned items to be ‘position:fixed’.
> 
> I think this last point is the key. Being able to do fixed polar (or relative or sticky) polar instead of only absolute polar is interesting.

Yes, I think that could lead to some interesting and useful designs. 

> The rest seems to matter less to me.
> 
> As long as you leave top/bottom/left/right auto, polar positioning does something sensible. As long as polar distance is auto, traditional positioning does something sensible. I am far from convinced that trying to use both at the same time gives anything useful. 

The main thing it does is in combination is to allow offsets to the polar position, which is what polar-origin is trying to solve as a separate new property. Which feels redundant to me.

> So from that point of view, any solution that keeps things working fine in one mode when the other is in auto seems acceptable to me.
> 
> Among the other alternatives, I'm not in favor of introducing a center property, as it too would have complex interactions with both polar and traditional positioning (not to forget that left/right/top/bottom influence position AND size) , and because centering is now a solved problem[1].

That is only if you want to center the item, not if you just want to position an item by its center (instead of by an edge). 'justify-self' cannot, for instance, cause the center of an item to be aligned with the left edge of the container, as 'center-x:0' would. Or to have a gauge marker whose center is absolutely positioned exactly, say, 12.5% along its containing block's width (especially if you don't know the width of the marker ahead of time, for doing a negative margin hack). 

And if the alignment properties are all that are needed, then why aren't the polar properties using them to do their centering? The center positioning should be separate from the angular translation, IMO. Otherwise, 'position: polar', as spec'ed, with the other 'polar-*' properties at their initial values, becomes one more way to center something (but with a property name that doesn't reflect that most visible immediate effect). 

> The simplest answer could be:
> * If position is not relative/absolute/fixed/sticky, polar-* properties are ignored.
> * otherwise, if polar-distance is auto, left/right/top/bottom are applied as usual, and other polar-* properties are ignored.
> * otherwise, (polar-distance is not auto), left/right/top/bottom are ignored, and polar-* properties are applied.

That's another option, but it seems odd to me. You could have 'left' and 'top' moving it horizontally or vertically (as they normally do) when also moving it angularly, but instead you would ignore them and use 'polar-origin' to do the exact same thing?

> 
> 
> [1] https://drafts.csswg.org/css-align/#self-alignment

Received on Tuesday, 22 December 2015 07:19:27 UTC