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

>> On Dec 23, 2015, at 5:17 PM, Florian Rivoal <florian@rivoal.net> wrote:
>> 
>> On Dec 24, 2015, at 02:06, Brad Kemper <brad.kemper@gmail.com> wrote:
>> 
>> 
>>> On Dec 22, 2015, at 1:16 AM, Florian Rivoal <florian@rivoal.net> wrote:
>>> 
>>> '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;
>> 
>> Check my proposal again. Only my last alternative used 'center'. 'center' would be ignored if top, right, bottom, or left were not 'auto'. 'Center-x' would be ignored if 'left' or 'right' were not auto. So in the example above, 'center-x' would be ignored.
> 
> 
> Sorry, I had missed that. In that case, the differences between center and polar-origin

You're on the right track...

> boil down to:
> 
> * center can be used without polar

And...

* center-x and center-y (or 2-value 'center') allows you to position the center of the object in many more places relative to the containing block. For instance, 'position:absolute; center: 25% auto' would put the center 25% from the left edge of the containing block, but not move it vertically from its static position. 

> * "center" is a more obvious name when you're using it without polar positioning, but is a confusing name if you're using it with polar positioning and in especially if you're also using polar-anchor

I find it more obvious in all cases. I don't find it confusing, because I would not automatically assume that something should be centered before being moved angularly (even though doing both is a common use case). It seems natural to me to center it with a center property, then move it at an angle with another property. Perhaps 'polar-' is more confusing than something like 'angular-'. 

The way I think of it, it is not really "polar positioning"; it is absolute/fixed/relative positioning, with a position determined by moving the center at an angle instead of by moving an edge perpendicularly. As such, perhaps "polar" is misleading. We are not dealing with longitude and latitude. Just X, Y, and angular (radial?) positions. 

And I think that if you can use 'center-[x|y]' with other lengths or percentages (or even left, right, too, or bottom, if you aren't trying to base position on the center of anything) to position it along the x and y axes, then polar-anchor becomes much, much less important to have at all, making it conceptually simpler. For the cases where using percentages-only does not suffice, there is still calc() or margin-left and margin-top.  

> * polar-origin's initial value is "center", which only does anything if polar positioning is used.

That's if polar-origin is needed at all. I don't think it is. But if it was, I'd have it's two values be positive and negative offsets (initially polar-origin: 0 0) instead of <position> values, since 'center:50%' would already start you off in the center. But left-margin and top-margin would give you the same thing, so what' the point of having a separate polar-origin property?

> What is center's initial value (sorry, I'm sure you said it in a previous mail)? Presumably auto, which has no effect if polar positioning is not used,

Yes, it would have no effect if it was 'auto'.  It wouldn't impact whether or not so-called polar positioning could be used. You could still use polar-distance and polar-angle to move it a distance at an angle.

> and could be made to compute to center if polar-positioning is used?

If 'center' is available as a property, then polar-positioning would no longer be responsible for centering. If you want it centered and then moved at an angle, you would use 'center:50%' and whatever polar-position and polar distance you wanted. If you didn't want it centered first, then you wouldn't use 'center' and it wouldn't be. You could move it at an angle from its auto location, or from wherever you put it with top, left, right, and/or bottom. 

This is part of what makes this proposal different from the other alternates. Polar-distance is no longer a centering switch, and its initial value would be 0 instead of auto. 

Really, at this point, the angular movement can be part of 'transform'. Something like 'transform: polar(<degree>, <distance>)' could work.

> I think one of the things this makes me wonder about is whether this will make it easier for people who would be using absolute positioning anyway to center things, or whether this will cause people who want to center things to do so using absolute positioning. The later is probably not desirable, for the usual reasons: absolute positioning deals poorly with overflow and collisions, which are bound to happen when displaying the content in various environments the author had not anticipated.
> 
> The same argument can be made about polar positioning in general,

Yep. It is mainly the name of the property that would discourage it, if the property that created a centered absolutely positioned element didn't use the word 'center' anywhere (or worse, didn't even use position: absolute, even though that's what it really amounts to). But then, if we are relying on obscurely named properties to discourage misuse, then I suggest a property called 'brad', with a value of 'florian' (or vice versa) to do the abspos centering. Nobody would ever guess what that did. ;-)

If we didn't care about all the extra power of positioning by the center point in places other than the center of the containing block (as I would like), then I guess we could just use 'justify-self' and 'align-self' to do the centering, instead of using 'center' (or instead of non-auto 'polar-distance', or instead of position: polar). 

> but we do not have, either in existing css or as an alternative proposal, a layout mechanism that accomplishes what polar positioning does AND deals with collisions and overflow. If we did, I would most likely support that instead of polar positioning (makes me think that maybe we should re-explore the idea of a "circular flex" model suggested a while back by LG).

That scares me. Also, when building something like a clock face, or an indicator on a horizontal gauge, a lot of things DO need to overlap.

Received on Thursday, 24 December 2015 08:00:09 UTC