W3C home > Mailing lists > Public > www-style@w3.org > October 2015

Re: [css-round-display] Suggest 'polar-anchor' property for positioning elements without overflowing

From: Jihye Hong <jh.hong@lge.com>
Date: Tue, 13 Oct 2015 20:42:54 +0900
To: "'Alan Stearns'" <stearns@adobe.com>
Cc: <www-style@w3.org>
Message-ID: <000001d105ac$4d8e9a00$e8abce00$@hong@lge.com>
If 'polar-anchor: auto' would work like method2, 'auto' value has the
following meanings:
	i) the objects are positioned as even around the edge of the circle
shape of the containing block
	ii) the objects are positioned without overflowing within the circle
shape of the containing block

Is this definition of 'auto' value appropriate?

It seems like the meaning of 'auto' value is complicated, while definitions
of 'auto' in 'background-position' or 'motion-direction' look intrinsic and

Also I'm not sure that 'auto' value is needed for 'polar-anchor'.
Do you think 'auto' is necessary for 'polar-anchor'?

- Jihye

On 08 Oct 2015, 14:29:36 +0000, Alan Stearns <stearns@adobe.com> wrote:
>On 10/8/15, 3:10 AM, "Jihye Hong" <jh.hong@lge.com> wrote:
>>I took some feedback from CC last week [1] and added 'polar-anchor'
property to the CSS Round Display ED [2].
>>I'd like to discuss about this spec whether its definition is reasonable.
>>When the 'polar-anchor' property was suggested, there was a consideration
of 'auto' value for the property. 
>>But I'm not sure that 'auto' value is necessary for 'polar-anchor'.
fantasai had mentioned auto keyword for 'polar-anchor' during the F2F
meeting at Paris[3]. Could you tell me your thought about the way 'auto'
works for 'polar-anchor'?
>>I thought 2 approaches to specify 'auto'.
>>When we have elements with 'polar-distance' and 'polar-angle' values, the
anchor points are specified by one of methods as below : 
>>	method 1) 
>>		- If polar-angle value of an element is 0deg, 90deg, 180deg,
and 270deg,
>>			- polar-anchor value is '50% 0%', '100% 50%', '50%
100%', and '0% 50%'.
>>			- if the polar-distance value is 100%, 
>>				polar-anchor value is adjusted to avoid
>>		- If polar-angle value of an element isn't 0deg, 90deg,
180deg, and 270deg,
>>			- and if 0deg < polar-angle < 90deg, 
>>				polar-anchor value is '100% 0%'
>>			- or if 90deg < polar-angle < 180deg, 
>>				polar-anchor value is '100% 100%'
>>			- or if 180deg < polar-angle < 270deg, 
>>				polar-anchor value is '0% 100%'
>>			- or if 270deg < polar-angle < 360deg, 
>>				polar-anchor value is '0% 0%'
>>		- The result is look like [4]. 
>>		- This guarantees not overflow.
>>	method 2) 
>>		- An anchor point is on the edge of a circumscribed circle
of an element.
>>		- An anchor point is also on a straight line made from the
center point of a containing block and the center point of a element's
content box.
>>		- The result will be [5].
>>		- This guarantees not overflow.
>>But both methods have side-effects. In method 1, distances between
neighboring elements are not even.
>>And in method 2, there is a gap between the edge of a containing block and
the edge of an element's content box when the polar-distance value is 100%.
>>As you can see, it's tricky to specify the expecting effect from auto
>>Which definition of auto is more appropriate?
>>Do you have any thought?
>As described, method 1 works for rectangles, but I think would give odd
results for circles (where anything other than 0, 90, 180, 270 would not
touch the edge). And the first point >would need to account for
polar-distance values near but not quite 100% which could also cause
overflow. A more shape-generalized solution following the intent of method 1
might be:
>- If the content area of a polar-distance positioned element would overflow
its parent, the used polar-distance value is reduced until it does not
>I expect this could get computationally-intensive to determine just how
much adjustment is needed to avoid overflow. So I'm more in favor of method
2. I think that even placement around the circle is probably more important
than making sure everything touches the edge.
Received on Tuesday, 13 October 2015 11:43:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:57 UTC