RE: [css-round-display] What is the % in device-radius relative to?

On Fri, Oct 16, 2015 at 1:50 PM, Florian Rivoal <florian> wrote:
> On 16 Oct 2015, at 02:49, Tab Atkins Jr. <> wrote:
>> This doesn't work; it assumes that the length/percentage is identical
>> in both dimensions.  If they're different, it's still undefined.
>> Take an elliptical screen.  It's 50% in both dimensions, but the
>> <length>s are different.  Or take a square screen whose corners are
>> elliptical.  Here, neither the <length> nor the <percentage> are the
>> same across the two dimensions.
>> You need to define a *single* way of measuring the size of the screen
>> and the size of the curve, so we can resolve the <length> and
>> <percentage> unambiguously.

> I don't think we need percentage and lengths to be equivalent to eachother.
> Each of them absolutely needs a clear and unambiguous definition, but there's
> no reason it has to be the same.
> Lengths have to match in both dimensions, so they can only ever match with
> circles, not ellipses, when used in equalities.
> For percentages, making the horizontal radius of the ellipse relate to the
> width and the vertical one relate to the hight is useful and unambiguous.
> This means that a fully rounded screen matches device-radius:50%, regardless
> of whether it is a rounded square screen (circle) or a rounded rectangle
> screen (ellipse).
> If you have a circular (non elliptical) rounded corners on a rectangular
> they never match (device-radius: X%), for any value of X. However, we can make
> them work with inequalities.
> A definition of inequalities that works well for circles / ellipses of
> various sizes, and gives meaningful results for arbitrary sizes is to base
> it on how much the shape obstruct the corners. Any shape that obscures the
> corners at least as much as the circle/ellipse with radius X matches
> (device-radius > X), and any shape that obscures the corners at most as
> much as the circle/ellipse with radius X matches (device-radius < X)
> So on a tall and narrow rectangular screen, a full ellipse would match
> (device-radius <= 50%), but so would circularly rounded corners with a
> radius of half the width of the screen (or less).
> The other way around, a full ellipse would match (device-radius > 25%),
> but so would a rhombus.

This problem happens only when horizontal radius and vertical radius are not
identical, but no problem in cases of fully rounded screen or rectangle whose
corners are regularly circled (not elliptical).

I considered this problem before, and came up with two values of device-radius
so that horizontal radius and vertical radius could be defined respectively. It
allows author to define an elliptical curves as a display shape with a pixel
unit in the Media queries, but it seemed to be a little complicated and not to
match the existing Media queries' convention (only one value). This issue has
been discussed in last thread as follow.

I also think that percentages and lengths don't need to be equivalent to each
other. Percentages are proportional to width and height of the screen each and
it can specify various shapes like ellipse whose horizontal radius and vertical
radius aren't identical. percentages are capable in that ellipse shape could be
identified using percentages of device-radius, while lengths are capable in that
a circular (non elliptical) rounded corners on a rectangular screen could be
identified. As Florian mentioned in the last thread, the more display shapes
could be identified like rhombus, diamond, rectangle with oblique line, using
prefixes like min/max and percentages. I will apply this concept as well as a
clear and unambiguous definition of the measuring method to the spec as a note
or issue soon.

As a result, I think this syntax(one value of device-radius and relationship btw
length and percentages) is the best way as of now, but there might be better way
to test display's shape using Media queries. The other platforms have very
simple method to identify the display shape. (e.g. isRound() in Android) The
upcoming displays could be well handled using the device-radius described above
for the time being.

Hyojin Song

Received on Saturday, 17 October 2015 09:29:08 UTC