W3C home > Mailing lists > Public > www-style@w3.org > April 2016

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

From: Jihye Hong <jh.hong@lge.com>
Date: Fri, 29 Apr 2016 17:56:20 +0900
To: "'Brad Kemper'" <brad.kemper@gmail.com>, "'fantasai'" <fantasai.lists@inkedblade.net>
Cc: <www-style@w3.org>
Message-ID: <004e01d1a1f5$0041d970$00c58c50$@lge.com>

> 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'.
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 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).

I agree with that. 

>> 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

I like the 'offset' prefix for origin and anchor.
I prefer,
 - offset-origin
 - offset-anchor

But I'm not convinced about offset-angle and offset-distance.


Thanks,
Jihye
Received on Friday, 29 April 2016 08:56:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC