[css-round-display] polar-* properties vs. existing properties

> On Jan 13, 2016, at 4:36 PM, Dael Jackson <daelcss@gmail.com> wrote:
> 
> Using polar positioning as a part of absolute positioning
> ---------------------------------------------------------
> 
>  - Jihye and BradK reviewed their conversation about if it's
>      possible to merge the proposed center property and the
>      polar-origin property.
>  - fantasai suggested that it may be possible to do everything in
>      the center property using the already existing alignment
>      properties.
>      - BradK will send fantasai a list of emails to review to catch
>          up on the conversation so that she can reply with more
>          details on her proposed solution after reviewing the use
>          cases.

There has been much evolution of the proposals over time in the ML, so I’m not sure a list of e-mails would help as much as a summary. They might even confuse the issue, unless you read from the start to the end. So, here is my summary instead, starting with how it is in the current spec:

A. ‘position:polar’ and ‘position:absolute’ are almost identical, aside from which other positioning properties are considered (top, right, left, and bottom, vs. polar-distance and polar-angle).

B. ‘position:polar’ also centers an element in its containing block. But really it is ‘polar-origin’ which determines where the center of the positioned element will line up with the containing block. Percentages resolve to be percentages of the width/height of the containing block. Initial value of ’50% 50%’ centers it.

C. ‘polar-anchor’ is ostensibly to set which point of the positioned element it is that lines up with the point set by ‘polar-origin’. But the practical effect is to offset the positioned element by the amount of the two length values it takes (one horizontal, one vertical). Percentages resolve to be percentages of the width/height of the positioned element.

D. The property names ‘polar-origin’ and ‘polar-anchor’ are too easy to mix up. They both take two values, anchors and origins are similar concepts, and they both have the visual effect of offsetting the element by the horizontal and vertical values. The primary difference is how percentages are calculated.


So my main points, based on the above are:


1. Given “A”, above, we don’t really need a separate ‘polar’ value for ‘position’. We should just allow the ‘polar-distance’ and ‘polar-angle’ to work when ‘position’ is ‘absolute’. We’d just need to decide how those interact with existing ‘top’, ‘right’, ‘bottom’, and ‘left’. This would also allow us to also use ‘polar-distance’ and ‘polar-angle’ when we have ‘position:fixed’ and ‘position:relative’. This is a relatively non-controversial point (with discussions leaning toward ‘polar-distance’ and ‘polar-angle’ only having an effect when ‘top’, ‘right’, ‘bottom’, and ‘left’ are all ‘auto’).

2. The positioned centering capability (and being able to position of an items center at some point that is not the exact center), and the capability to position something via an angle and length are two separate concerns that are independently valuable:

2.1. Centering: Given “B”, above, a lot of the discussion was about my proposal for a ‘center’ property, but it essentially did the same thing as ‘polar-origin’: it was to position an element by its center point (or perhaps by some other anchor point as set by a property like ‘polar-anchor’), instead of by an edge like top, right, bottom, and left does. This is valuable, but it sounds like the alignment spec already contains the capability to do everything that ‘polar-origin’ achieves. If so, then I think we really don’t need a ‘polar-origin’ or ‘center’ property, as they are both redundant. Their inclusion would add no new practical effect. Authors would use ‘position:polar’ just to center something, and then it would be unclear how the alignment spec would interact with that. 

2.2. Positioning by angle and length: If you put aside the centering aspect of ‘position:polar’, positioning an item via an angle and length is a useful alternative to using, e.g., ’top’ and ‘left’ to put it in exactly the same position. You are basically just moving the element along the hypotenuse of a right triangle, instead of along the other two sides. Thus, we should be able to use ‘polar-distance’ and ‘polar-angle’ in all the same situations where ’top’ and ‘left’ can be used (but not for affecting the width or height, as top/bottom and right/left can). 

3. ‘polar-anchor’ doesn’t really do anything significantly different from ’transform: translate()’. The main difference is that ’transform: translate’ resolves percentages against the item’s border-box instead of the item’s content box. If that is not an important distinction, then we shouldn’t have a separate  ‘polar-anchor’ property. If it is important, then there probably isn’t any strong reason why it would be more important for polar positioning, than for other things. Thus, the name should probably change too. The ‘polar-‘ prefix here is asking authors to think about it in terms of polar coordinates, but that should not be a requirement to using it. At most, it is a slight variation of ‘translate()’.

Given all that…

If ‘polar-distance’ and ‘polar-angle’ can be used together, without a dependency on other ‘polar-*’ properties, then it really doesn’t require authors to care about whether they are moving the center or moving one edge. As such, these can really be thought of as transforms. 

Furthermore, if centering is not a requirement, and authors don’t need to think about moving from a center in order to move at an angle, then the ‘polar-‘ prefix is not that relevant anymore. I should not have to shift my mental model to think of polar coordinates, just in order to position something using an angle and length.

Thus, why not just ’transform: angle-translate(<angle>,<distance-or-percentage>)’ (modulo bikeshedding the function name)? This would make it obvious how it would combine with ‘top’, ‘right’, ‘bottom’, and ‘left’ (which is to say, the same as with any other transform). Combining any of those with center alignment in absolute positioning would allow anything that the polar-* properties would, would also allow the same sort of angular positioning in combination with position:fixed and position:relative (or even position:sticky), and would avoid forking ‘position:absolute’ into two almost identical properties. 

TL;DR:

• Get rid of ‘position:polar’ value.
• Use alignment properties to do centering while positioned.
• Get rid of ‘ polar-origin’.
• Use top, right, bottom, and left in combination with alignment properties, as described in alignment spec, as replacement for ‘polar-origin’ offsetting.
• Get rid of ‘polar-anchor’.
• Use ’transform: translate()’ (or something almost identical, with a similar name, or translate() with an added keyword) instead of ‘polar-anchor’.
• Replace ‘polar-distance’ and ‘polar-angle’ with ’transform: angle-translate(<angle>,<distance-or-percentage>)’. For example, ’transform: angle-translate(45deg,100%)’ 


P.S.:
Here are use cases I had for using ‘center’ property (which was mostly different from 'polar-origin' in that is didn’t require a non-auto value for polar-distance, and it didn’t require the author to think it was tied to thinking about polar coordinates):

http://lists.w3.org/Archives/Public/www-style/2015Oct/0210.html

I thought I had a more recent email with more use cases like that in it, but I can’t find it.