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

Brad Kemper
> On Apr 29, 2016, at 1:56 AM, Jihye Hong <jh.hong@lge.com> wrote:
> 
> 
>>> On Apr 28, 2016, at 3:33 PM, Brad Kemper < brad.kemper@gmail.com > wrote: 
>>> 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:
>>>> 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.
> 
> I didn't mention all of the cases. I omitted some of them.
> My idea was, if 'top' and 'bottom' are both non-auto then 'polar-anchor: auto' works as 'polar-anchor: bottom top'.

I think you meant 'polar-anchor: top'?

> And when 'left' and 'right', 'polar-anchor: auto' may be as the same with 'polar-anchor: left'.

>>>> '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 realize that we don't have the same polar model here.
> 
> In my polar model, 'polar-distance' or 'polar-angle' makes the switch between Cartesian coordinates and polar coordinates.
> And when 'polar-distance' or 'polar-angle' is 'non-auto' then 'polar-origin: auto' works as 'polar-origin: center'.
> But when both 'polar-distance' and 'polar-angle' aren¡¯t specified, then 'polar-origin: auto' works as 'polar-origin: top left'.
> 
> Am I misunderstanding about the resolution from CSSWG F2F in Sydney?

I think you are misunderstanding, yes. 

Your polar model is more complicated. 'polar-origin' is the more obvious candidate for making the switch. It's value is what says where to position the element in the containing block, so it's non-auto value is what causes the centering anyway. 

If 'polar-origin' is auto, then it wouldn't position the element in the containing block at all, so that's what we want for its initial value. If it is '50% 50%', then it centers it (or if you prefer to think of it in more complicated terms, it changes the coordinates of the containing block to polar for 'polar-*' properties only, where the "0 0" origin is in the center, and also changes the representative  alignment point of the element to be in the center of the element. The end result is the same, however). 

But 'polar-angle' and 'polar-distance' can be (and should be) completely independent of this centering effect, just as they would be with 'position: relative'. 

Received on Friday, 29 April 2016 23:57:44 UTC