Re: [css-round-display] Summary of a discussion about polar positioning in every positioning schemes

> On Jan 20, 2016, at 9:39 PM, Florian Rivoal <florian@rivoal.net> wrote:
> 
> 
>>> On Jan 21, 2016, at 08:33, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> 
>>>> On Jan 20, 2016, at 8:48 AM, Florian Rivoal <florian@rivoal.net> wrote:
>>>> 
>>>> On Jan 20, 2016, at 16:39, Jihye Hong <jh.hong@lge.com> wrote:
>>>> 
>>>> * polar-origin and polar-anchor can be used independently from the polar
>>>> positioning.
>>> 
>>> I am not necessarily opposed, but I am not fully convinced. Did the rest of the WG agree to that,
>>> or were you describing consensus between Brad, you (and maybe me)?
>> 
>> So far, we three are the only ones to discuss it much.
> 
> Well, Fantasai (at least) had commented on that,

I might have missed that, if it was on the list. 

> and then I missed a call, so I was wondering if there'd be additional agreement when I wasn't around.

Nothing formal, anyway. In the call, I mentioned that polar-origin and my center property were almost the same, in that they set where the center of the element is positioned, while polar-angle and polar-distance determined where it went at an angle from there. Fantasai did not disagree, but pointed out that we already had properties to do the first part (centering with abs pos, and moving that center to off-center).

>> Once you start pulling it apart, polar-origin is little more than a way to center an item prior to moving it at an angle with polar-distance and polar-angle. So you can call it 'center' instead of 'polar-origin', and it would be almost the same as what I proposed. That is what at least two of us agreed on. 
>> 
>> But fantasai pointed out that the alignment spec already gives a way to center positioned items, and probably handles my other use cases for 'center' (and already uses top, right, bottom, and left for adjusting where the center of the positioning area will be). If that's the case, then I don't think we actually need polar-origin. polar-distance and polar-angle can simply handle the moving-it-at-an-angle part, while other position and alignment properties handle the centering (or off-centering).
> 
> That's justify-self: center and align-self: center, right?

Right. 

> I'm not sure it's the right way to go. It seems the mental models are completely disjoined. If you want a polar coordinate system,

As an author, I don't want a whole new mental model for something that can be easily explained in the existing model in a way that is totally consistent with the way existing CSS works. I don't know why anyone would advocate for a new mental model. It just makes things more confusing to have to rethink the whole coordinate system every time I want to move something at an angle. 

You started from the point of view of it being a polar coordinate system, saw the 'polar-' prefix in the names, and that has colored your thoughts of how it should work. 

But as an author, I look at what polar-origin actually does, which is duplicate existing centering functionality. It does nothing else significant other than make another x/y movement (polar-anchor) to be also more different than existing x/y movement mechanisms, by forcing me to think about a center point that should be irrelevant. 

Even polar-angle and polar-distance are really just shortcuts for x/y movements. You just travel along the hypotenuse instead of the other two sides of a right triangle. I don't need a new mental model or coordinate system for that. A new coordinate system just muddies the waters of what is really going on. 

So, I don't actually want "a polar coordinate system" overlaying the Cartesian coordinate system used by all other properties. A new system or new mental model isn't necessary.  I want something that is already very easy to understand, easier to understand really, with the existing system. 

> justification, alignment, margins and offsets from the alignment container isn't what you have in mind. Modulo the fact that percentages on polar-anchor and percentages on margin are calculate of something different, it looks like you should be able to translate anything you might want to do with polar-origin and polar-anchor into that system, but I don't find it intuitive at all (Examples might convince me otherwise).

And I don't think it is intuitive at all to have to translate everything I already know about positioning, margins, alignment, etc. into a new system, when the old familiar system is at least as good. 

> How much should we value avoiding redundant mechanisms to achive similar things vs having a system that authors actually understand?

I'm an author. I find it easier to understand when you extend the old system, rather than replace it with a new one. Why embrace redundancy, just to have something different to learn?

> #foo {
>  position: absolute;
>  polar-origin: center center;
>  polar-anchor: top center;
>  polar-distance: 100px;
>  polar-angle: 45deg;
> }

That's 4 new properties, and I have to read a spec to know the non-obvious differences between 'origin' and 'anchor'. They are similar meaning concepts, and both have the effect of moving something horizontally and vertically. 

> The only thing you need a spec for to understand what this does is to know where angles start form.

"Only"! How many authors do you think read our specs? It can be more clear than that. 

> Contrast with:
> 
> #foo {
>  position: absolute;
>  align-self:center;
>  justify-self: center;
>  /*??? how do you replace polar anchor ???*/
>  polar-distance: 100px;
>  polar-angle: 45deg;
> }

Only two new properties, not including what the alignment spec has already! And it is pretty clear what they do (although it would probably be even better without the 'polar-' prefix). And it is clear where angles start from. If you already know about how alignment works, you don't need to read a spec to understand this example. 

And we shouldn't design this spec based on an assumption of authors having difficulty with a different spec. 

> Actually, I'm not even sure how to do it without either some *-anchor property that lets me say top center (which doesn't feel like a great fit with align-self and justify-self),

Every. Single. Time. I have to stop and think which thing you are talking about, between "anchor" and "origin".  I just mistook it again, and now I'm retyping. 

I'm not against having a property that does what polar-anchor does. What it actually does is adds a couple perpendicular movements, which can be percentages of the element itself. It should have a name that reflects that, without requiring a new mental model, and which can be used everywhere (or at least with all positioned elements). 'Polar-anchor' only makes some sense if you force authors to change mental models, and even then not clearly. 

> or some property that would let me express a translation as a percentage of the positioned element's size.

Sure. Call it 'move-self' or something, since that's what it does. Or just use 'transform: translate()', if a percentage of the border-box is good enough. 

As for your example above, 'move-self: 0 50%' (or 'transform: translate(0, 50%);') would, after the alignment properties were applied, move it down so that the top of the box lined up with the center of the containing block, which is what you were doing with 'polar-anchor'. 

>> This would also affect polar-anchor. With centering handled by alignment, you no longer need to care where the center of the element is. You don't need an anchor point. You just move the whole thing. The real effect of polar-anchor was to add an additional horizontal or vertical adjustment, where percentages are of the element's width and height. There is no reason for that utility to depend upon polar-distance.
> 
> Especially if you consider percentages, margins seem to be a poor substitute for polar-anchor.

If you say so. I'm used to using them with absolutely positioned elements. But I get your point about percentages. 

> Maybe the machinery should be attached to justify-self/align-self rather than polar positioning, but I don't think we have it today.

I don't think it should be attached to just one of those. If it has utility for either, it has general utility. 

Translate() gives you almost everything you are asking for, except it uses the dimensions of the border box instead of the content box. Is that important?

I'm not in favor of forcing a completely new mental model, which duplicates a lot of existing functionality, just to be able to move something at an angle. Moving a distance at an angle instead along the other two sides of a right triangle is a useful thing. The other duplications: I'm far from convinced they are useful enough to have as separate properties. 

>>>> * auto values for polar-origin and polar-anchor to resolve differently when
>>>> polar-distance is auto or non-auto
>>>> - when polar-distance is auto, 
>>>>   - polar-origin: auto becomes polar-anchor: 0 0
>>>>   - polar-anchor: auto becomes polar-anchor: 0 0
>>>> - when polar-distance is non auto, 
>>>>   - polar-origin: auto becomes polar-anchor: center center
>>>>   - polar-anchor: auto becomes polar-anchor: 0 0
>>> 
>>> Assuming we agree polar-origin does anything when polar-distance is auto, then I agree with what you said about polar-origin, but I don't see why polar-anchor needs an auto value. Shouldn't its initial value just be center center (not 0 0)?
>> 
>> The other way around makes more sense to me. I no longer think about this property as having anything to do with a center point. If we use alignment properties to do the centering, then the center point is irrelevant. No, at the end of the day, polar-anchor is just something to adjust the position. So 0 0 would in all cases mean that you are not adjusting the position.
> 
> If we ditch polar-anchor altogether, then it doesn't matter. If we keep it, for the initial value to be 0 0, then it would need to be described as a translation vector applied before you do the polar positioning, not as an anchor.

Right-ish. Anchor is not the right word to describe the effect of what it does. It can be applied before or after the angular translation. 

> But if polar-origin and polar-anchor (even if remained) are about which point you align with which point, then they both need to be center center for the thing to work at all.

Not necessarily. Even with those, polar-anchor is still, in effect, just a translation vector. And why limit this effect to only working when polar positioning is used?

>>>> Please tell me if there is something that I miss.
>>> 
>>> * If we allow polar positioning to apply to relative positioning, we need to define what percentages in "polar-distance: ???%" refer to, and how contain works in "polar-distance: ???% contain" in relative positioning.
>> 
>> I'd make them refer to the same thing as top, right, bottom, and left in relative positioning (percentage of containing block). I don't think percentages are super useful on any of these with relative positioning, but it should be consistent, unless there is strong reason otherwise.
> 
> Right. Do people use percentages in top, right, bottom, and left with relative positioning?

Not me. I've never found much use for that. 

> I agree it probably doesn't matter much, and we can define anything we'd like, in which case consistency is good.

Cool.

Received on Thursday, 21 January 2016 18:02:10 UTC