Re: [css-round-display] Percentages of 'polar-distance' when origin is not the center of the containing block

> On Jan 28, 2016, at 16:39, Jihye Hong <> wrote:
>> On Jan 28, 2016, at 4:06 PM, Florian Rivoal < > wrote:
>>> On Jan 27, 2016, at 20:43, Jihye Hong <> wrote:
>>> Sorry, I used confusing expression, 'circular' dependency.
>>> What I want to explain was, using the #2, the calculated value of the
>>> percentage polar-distance changes depending on the polar-angle value.
>>> There are some usecases when all the elements in a containing block
>>> have '50%' for polar-distance properties and the origin of polar
>>> coordinates isn't center.
>>> For #1 [1], all the calculated value of the percentage polar-distance
>>> of elements are same because they have same percentage values.
>>> But for #2 [2], the calculated distances between the each element and
>>> the origin point are different.
>>> I couldn't find any usage of percentage for the property's value
>> which
>>> has dependency on another properties.
>>> If there exists cases, then #2 seems to be appropriate, but if not,
>> #1
>>> or another way can solve this problem.
>> I see what you meant. Ultimately, we will need to deal with this
>> dependency to take care of "polar-distance: ***% contain", so I don't
>> think it makes a huge difference.
>> Speaking of which what use cases do we have for using polar-distance
>> with a percentage and not using contain? I'm wondering if we should
>> make "contain" the default, or possibly the only behavior for
>> percentages.
> There is an usecase about using "polar-distance: 100%".
> As you can see in the main screen UI of a page[1], there are buttons for
> calls, messages, and mail.
> And there are rounded text boxes to notify the number of calls, messages,
> and mail at upper-right part of the buttons.
> Those text boxes can be positioned with "polar-distance: 100%; polar-angle:
> 30deg" when their containing blocks are the buttons.
> In this case, the polar-distance with a percentage without contain seems
> useful.
> [1]

Thanks. I see, it's a good example. That leaves the question of which one
should be the default behavior open, but being able to support both use cases
does make sense.

 - Florian

Received on Thursday, 28 January 2016 09:03:25 UTC