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

Brad Kemper
>> On Oct 8, 2015, at 3:10 AM, Jihye Hong <jh.hong@lge.com> wrote:
>> 
>> On 23/09/2015 05:40 PM, Jihye Hong wrote:
>> Hello all,
>> I¡¯m Jihye Hong from LG Electronics. I attended the last F2F meeting at Paris and presented CSS 
>> Round Display demos. I hope you could remember me. : )
>> 
>> In the middle of discussing about css-round-display [1] at the F2F Paris meeting, there was an
>> issue about positioning items to the edge of the containing block without overflowing [2]. When 
>> authors would align elements in the circular display using ¡®polar-angle¡¯ and ¡®polar-distance¡¯, 
>> they should find out the accurate value of ¡®polar-distance¡¯ for avoiding elements to get out of 
>> the edge of the containing block. We described the issue in the spec and deliberate how to 
>> resolve it.
>> We potentially came up with a ¡®polar-anchor¡¯ property to set a anchor point of the element as a 
>> suggested solution in the meeting. The anchor point specifies a position which is a 
>> representative point of the element aligned with a containing block. Setting the anchor point 
>> makes easier to position the elements inside the containing block. To design the ¡®polar-anchor¡¯, 
>> I refer to the ¡®background-position¡¯ property [3].
>> You can see the Polyfill with ¡®polar-anchor¡¯ [4][5].
>> 
>> The ¡®polar-anchor¡¯ has the value <position> | auto. The value indicates which horizontal and 
>> vertical offset of the element is aligned to the containing block¡¯s alignment position.
>> The <position> value is defined like below: 
>> <position> = [
>> [ left | center | right | top | bottom | <percentage> | <length> ]
>> |
>> [ left | center | right | <percentage> | <length> ]
>> [ top | center | bottom | <percentage> | <length> ]
>> |
>> [ center | [ left | right ] [ <percentage> | <length> ]? ] &&
>> [ center | [ top | bottom ] [ <percentage> | <length> ]? ]
>> ]
>> 
>> I have several questions about the ¡®polar-anchor¡¯ property:
>> - Is the ¡®polar-anchor¡¯ property useful to be a new property in css-round-display?
>> - Is naming of the property reasonable?
>> - Is value types of the property suitable? Any other types to be considered?
>> 
>> Happy to have your feedback!
>> 
>> Regards,
>> Jihye Hong
>> 
>> [1] http://www.w3.org/TR/css-round-display-1/ 
>> [2] https://www.w3.org/Style/CSS/Tracker/actions/714
>> [3] http://www.w3.org/TR/2014/WD-css3-background-20140204/#background-position
>> [4] http://anawhj.github.io/jRound/demo/polar/anchor.html 
>> [5] http://anawhj.github.io/jRound/src/css-polar.js 
>> ©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥©¥
>> Jihye Hong
>> Research Engineer
>> SoftWare Platform R&D Lab,
>> CTO Division, LG Electronics Inc.
>> Mobile : 82-10-7276-5695
>> E-mail : jh.hong@lge.com
> 
> 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 overflowing.
>        - 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 value.
> Which definition of auto is more appropriate?
> Do you have any thought?
> 
> Thanks : )
> - Jihye Hong
> 
> [1] https://lists.w3.org/Archives/Public/www-style/2015Oct/0012.html 
> [2] https://drafts.csswg.org/css-round-display/#propdef-polar-anchor 
> [3] http://log.csswg.org/irc.w3.org/css/2015-08-26/#e583134
> [4] https://github.com/anawhj/jRound/blob/master/demo/polar/polar_anchor_auto_method1.JPG
> [5] https://github.com/anawhj/jRound/blob/master/demo/polar/polar_anchor_auto_method2.JPG 

I've been thinking about this for a while. If what you want is something to nudge a polar positioned item vertically or horizontally, then my earlier proposal would give you that. What I suggested was: don't make 'polar' a separate value of 'position'. Instead, let 'polar-angle' and 'polar-distance' combine with positions absolute, fixed, and relative, in the same way that left, right, top, and bottom do. The effects of left, right, top, bottom, polar-angle, and polar-distance would be cumulative, so if you wanted a horizontal or vertical offset, you would usually use 'top' and 'left' for that. 

As a bonus, this would also enable you to use angle and distance for relative positioning, which might be useful (some might find it more convenient than setting horizontal and vertical offsets). 

The way this could be made to work is that the initial value of 'polar-distance' would be 'auto', meaning it would have no effect on positioning. Non-auto values for absolute or fixed position items would be measured from the center of the contains block. 

I think most of the time, having a 2-dimensional polar-anchor seems like overkill. Isn't the real issue that you often (usually?) want 'polar-distance: 100%' to just touch the inside edge of the containing block? I would do this (an effect similar to 'polar-anchor: auto) by adding an optional keyword to 'polar-distance' value of either 'outer' or 'center' which determined the anchor point used for 'polar-distance: 100%'. 

'Polar-distance: 100% outer' would mean that an imaginary ellipse that touched all four sides of the border box (equivalent to border-radius:100%) would be be positioned as far out along the ray as it could without passing the inner edge of the containing block's border shape. 

Polar-distance: 0% would still mean completely centered, and all other percentages would be between those two points. 

This would mean the center of the positioned object would always be the same distance from the inner edge of the round display, without having to give each element a separate value, and would also hug the inner edges of a rectangular display. A little extra padding on the positioned element would further help prevent overlap with the edge (as would 'polar-distance: 95%' instead of 100%, as would nudging individual items with 'top' and 'left' properties). If even more control is needed, we could have a 'polar-margin' property that guaranteed a distance between the imaginary ellipse and the inner border edge of the container. 


Brad Kemper
> 

Received on Friday, 9 October 2015 17:45:27 UTC