Re: [css-round-display] Add 'auto' to 'polar-anchor' and make it as initial value

> On Apr 27, 2016, at 6:49 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
> On 04/21/2016 11:56 AM, Jihye Hong wrote:
>>>> On Apr 20, 2016, at 3:19 AM, Brad Kemper < brad.kemper@gmail.com > wrote:
>>>> On Apr 19, 2016, at 12:46 AM, Jihye Hong <jh.hong@lge.com> wrote:
>> And yes, I also think that 'auto' is better for the initial value of
>> 'polar-anchor'.

It turns out I was actually talking about 'polar-origin' at that point. From now on, maybe I'll just say 'polar-anchrogin', and let people guess what I mean, since I choose the wrong term half the time anyway.

>>>> 'auto' works as:
>>>>   - 'auto' becomes 'top left' if an element is positioned in Cartesian
>>> coordinates (specifying Top/Right/Bottom/Left).
>>> 
>>> I don't know what you mean. top/right/bottom/left properties position
>>> items by their top/right/bottom/left edges, while  'polar-anchor'
>>> positions items by their centers (which is why I would change the name
>>> from 'polar-anchor' to 'center').
>> 
>> My suggestion was,
>> - If any positioning property isn't specified, 'polar-anchor: auto' is the
>> same result of 'polar-anchor: left top'.
>> - When 'polar-anchor: auto' is specified on an element with 'left', when it
>> works as 'polar-anchor: left'.
>> - When 'polar-anchor: auto' is specified on an element with 'top', when it
>> works as 'polar-anchor: top'.
>> - When 'polar-anchor: auto' is specified on an element with 'right', when it
>> works as 'polar-anchor: right'.
>> - When 'polar-anchor: auto' is specified on an element with 'bottom', when
>> it works as 'polar-anchor: bottom'.
>> And 'polar-anchor: auto' is specified with 'left' and 'top', when it works
>> as 'polar-anchor: left top'.

This doesn't work. What if 'top' and 'bottom' are both non-auto? Or 'left' and 'right' are both non-auto? I don't think we need polar-anchor:auto.

>> 'auto' works like this to get the same result as the normal positioning
>> method.
> 
> I don't think this makes much sense. Any value should give the same result
> as normal positioning if 'polar-origin' is 'auto'. Only if it is not 'auto'
> should 'polar-anchor' or 'polar-distance' have any effect.

True. Though if 'polar-anchor' was renamed as 'nudge' or 'move' (since that is its actual visual effect), one could more easily imagine it working regardless of other polar-* properties, whenever 'position' was not 'static'. 

>> It was resolved that using 'polar-distance' or 'polar-angle' makes a switch
>> of the coordinate system from Cartesian coordinates to polar coordinates at
>> CSSWG F2F in Sydney [1].
> 
> No, only 'polar-origin' is the switch.

Yes, thanks. I was worried there for a sec.

>>> I still feel that using 'polar-' prefix and asking people to think about
>>> coordinate systems is adding an unnecessary complication. It brings to
>>> mind polar map projections and cartography, and geometry, instead of just
>>> saying "this property moves an object so that its center aligns with the
>>> specified value, as a point within the containing block." Just as the
>>> 'left' property means "move (and/or resize) an object so that its left
>>> edge aligns with the specified value, as a distance from the left edge of
>>> the containing block."
>> I also think that 'polar-' prefix for 'polar-origin' and 'polar-anchor'
>> isn't appropriate.
>> Because they could be used to position elements not just in polar
>> coordinates.
>> 
>> I think the namings could be changed like:
>>   polar-origin -> origin-position
>>   polar-anchor -> anchor-position
> 
> I think maybe it makes more sense to turn it the other way around, e.g.
>  position-origin
>  position-anchor

Yes, that is the norm for naming related properties (common part comes first).

> But for top/left/right/bottom we were thinking of using 'offset' as the
> prefix for the logical properties (and hence 'offset' as the shorthand
> that sets all of them),

I like the idea, but 'offset' seems less than ideal. What if 'position' was the shorthand and the prefix? Like 'position: absolute 0 auto 0 0'?

> so maybe
>  offset-origin
>  offset-anchor
>  offset-angle
>  offset-distance
> ?

I agree in principle. Would this be part of the shorthand too, or longhand only? We'd need to use slashes to disabiguate values for origin and anchor, and one before angle and distance too, I guess.

Though I would prefer, for reasons stated elsewhere (assuming an 'offset-' prefix):

offset-center
offset-nudge
offset-angle
offset-distance