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

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

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 21 Oct 2015 11:17:02 +0900
Cc: Hyojin Song <hyojin22.song@lge.com>, www-style list <www-style@w3.org>
Message-Id: <B4F66F8E-1280-44C1-A847-66BE71005A13@rivoal.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
> On 21 Oct 2015, at 03:28, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Sat, Oct 17, 2015 at 2:28 AM, Hyojin Song <hyojin22.song@lge.com> wrote:
>> 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.
> Yes, I agree that a single value is best, but my issue is that *the
> current definition doesn't work*, for the reasons I gave earlier in
> the thread.  It still needs fixing.  (I think Florian's suggested fix
> is far too complicated for such a simple value, and I believe it's
> also ill-defined in a number of ways.)

I disagree that my definition for equalities is complicated. I am merely
treating both axes separately, which I believe leads to intuitive results.

For the inequalities, it is a bit more involved, but it is useful.

* it gives intuitive and useful results when comparing elliptically rounded
corners to non-percentage values, and circularly rounded coners

* From a few seconds of googling for "rounded corners watch", here are a few
watch shapes that would never match any equality or inequality under your
definition, but would under mine.


I'm happy to draw a bunch of examples on a white board at TPAC to
convince you that the results of my definition are intuitive.

> Just saying that it's relative to the width, or the height, or the
> geometric mean of the two, is sufficient.

That's easier to spec, but less useful. I'm happy to include the
results of that approach (and its variants) in my TPAC board
drawing to show that it is intuitive and useful in fewer cases.

> Percentages and lengths *do* need to be relative to the same thing.
> If they're not, then you can't use calc() well.  We already made this
> mistake a few times in CSS, and we have a wiki page dedicated to
> warning against it: https://wiki.csswg.org/spec/calc-and-percentages

Good point, but I think this is a borderline case, on the good side of
the border. With the definition I gave, calc math works just fine as
long as you consider each dimension separately, which you would have to 
do with that definition even if calc is not involved.

 - Florian
Received on Wednesday, 21 October 2015 02:17:34 UTC

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