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

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

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 20 Jan 2016 15:33:39 -0800
Cc: Jihye Hong <jh.hong@lge.com>, fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
Message-Id: <808B3F01-59E3-4844-A46D-9146162413C6@gmail.com>
To: Florian Rivoal <florian@rivoal.net>


> 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:
>> 
>> We have discussed about using polar positioning as a part of absolute
>> positioning on several emails[1][2] and telecons [3].
>> It would be needed to summarize about the discussion for resolving the issue
>> and helping the other WG members catch up with it.
>> 
>> = Agreed =
>> * Polar positioning is possible in all positioning schemes not only when
>> position is 'polar'.
> 
> You mean polar positioning is activated if:
> * the position property is something other than static
> and
> * polar-distance is something else than auto
> right?
> 
> I'm ok with that.
> 
>> * If one of the properties such as left/top/right/bottom is non auto,
>> polar-* properties are ignored
> 
> I'm ok with that.
> 
>> * 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. 

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

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. 

>> * polar-origin and polar-anchor need to get rid of a prefix, 'polar-'
> 
> Assuming we actually agree on the previous point, then I agree on this one.
> 
>> * 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. 

>> = Need to be discussed =
>> * Naming of the property which decides the origin point of polar coordinates
>>   - original: polar-origin
>>   - My suggestion: origin-position
>>   - Florian's suggestion: box-align
>>   - Brad's suggestion: center
>> 
>> * Changing the name of polar-anchor
>>   - My suggestion: anchor-position
>>   - Florian's suggestion: box-anchor
> 
> I am not a huge fan of any of these names, including the ones I suggested. But I am not sure I have a better alternative.
> 
>> 
>> * Whether or not margin-left/margin-top can be used instead of polar-anchor
>>   - Using margin-left and margin-top would be the same result of using
>> polar-anchor
>>     - If the containing block has height: 100px, width: 100px, item1 and
>> item2 have same results.
>>        item1 {
>>          position: absolute;
>>          width: 20px;
>>          height: 20px;
>>          polar-distance: 0%;
>>          polar-anchor: 25% 25%;
>>        }
>> 
>>        item2 {
>>          position: absolute;
>>          width: 20px;
>>          height: 20px;
>>          polar-distance: 0%;
>>          margin-top: 5px;
>>          margin-left: 5px;
>>        }
>> 
>>   - Difference between polar-anchor and margin-left/margin-top
>>     - In case of margin-left/margin-top, percentages resolve to the width
>> of the element itself
>>     - In case of polar-anchor, percentage resolves to the width and height
>> of the containing block
> 
> I don't think polar-anchor is as important as the rest of the polar positioning proposal, but I do think it serves these use cases better than margins.
> 
>> 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. 
Received on Wednesday, 20 January 2016 23:34:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:35 UTC