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

 > On Tuesday, December 22, 2015 6:16 PM, Florian Rivoal
<florian@rivoal.net> wrote: 
 > > On Dec 22, 2015, at 16:18, Brad Kemper <brad.kemper@gmail.com> wrote:
 > >
 > >> 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.
 > 
 > 
 > 'Polar-origin' and 'center' sort of do the same thing. But 'center' is
 > also meant to be used with T/R/B/L. I'm not sure if that's useful,
 > complicating things, or both.
 > 
 > left: 50px; right: 50px; width: 100px; center-x: 0;
 > 
 > We already have (complex) rules to resolve the over-constraining that
 > happens with the first 3 properties, but the 4th makes it worse.
 > 
 > The same problem doesn't happen with polar-origin if we isolate the
 > polar mode from the traditional mode.
 > 
 > >> 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?

Yes, 'polar-origin' can give the same result by moving elements horizontally
or vertically and then polar positioning can be applied with
'polar-distance' and 'polar-angle'.
Also, you can move elements horizontally or vertically after the polar
positioning by using 'polar-anchor'.

 > left/top don't just move things, they also size them, and I'd like to
 > avoid creating more ways to create over constrained situations.
 > 
 > If left is 0px and center is 50px, is an auto width resolved to 100px?
 > 

According to [1], 'center' can set the origin only when 'left', 'right',
'top', and 'bottom' are 'auto'.
Therefore an auto width could be resolved to 100px when 
  left: auto; right: auto; top: auto; bottom: auto; center: 50px;

 > Maybe we could skip polar-origin and center, and do something like this:
 > 
 > width: auto;
 > height: auto;
 > left: calc(50% - 10px);
 > right: (50% - 10px);
 > top: calc(50% - 10px);
 > bottom: (50% - 10px);
 > polar-angle: 30deg;
 > polar-distance: 100% contain;
 > 
 > but this has terrible ergonomics compared to:
 > 
 > width: 20px;
 > height: 20px;
 > polar-origin: center;
 > polar-angle: 30deg;
 > polar-distance: 100% contain;

Considering the opinions so far, the solution about this issue could like
below:

* Not giving 'auto' value to 'polar-distance' makes possible to use polar-*
properties and ignore left/right/top/bottom when 'position' is
relative/absolute/fixed/sticky.
* Giving 'auto' value to 'polar-distance' means to ignore other polar-*
properties and use left/right/top/bottom for positioning.
* 'polar-origin' is used for setting the origin of the polar movement.

I agree with the idea of using polar positioning in another positioning
(when 'position' is relative|absolute|fixed|sticky). So, instead of
'position: polar', 'polar-distance' with not auto value is more appropriate
for initiating the polar positioning. 

On the other hand, 'center' seems to be no different from the 'polar-origin'
to me. 
Using 'polar-origin' is enough for finding the origin of the polar movement.

Thanks,
Jihye Hong

[1] https://lists.w3.org/Archives/Public/www-style/2015Dec/0263.html

Received on Wednesday, 23 December 2015 06:03:35 UTC