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

On Tue, Oct 20, 2015 at 7:17 PM, Florian Rivoal <florian@rivoal.net> wrote:
>>
>> 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.

Equalities and inequalities have to work exactly the same.  (x: y)
must be exactly equivalent to ((x <= y) and (x >= y)), or else algebra
doesn't work.

> 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.
>
> https://s-media-cache-ak0.pinimg.com/236x/29/c3/10/29c3109f738881d3b0cb4b12e9de15fc.jpg
> http://www.gadgetfolder.com/wp-content/uploads/2014/09/asus-zenwatch-official-1.jpg
> http://static.dezeen.com/uploads/2012/05/26632AA.jpg
> https://cdn2.bigcommerce.com/n-pktq5q/wgja22j/products/107/images/2875/E2D7643__25245.1417203721.1280.1280.jpg?c=2

I'm not sure why these wouldn't work.  #1, #3, and #4 are
non-elliptical curves, but can still be treated the as elliptical for
these purposes - just track how far into the shape the curve starts.
#2 is elliptical and small (the real screen - the face is the same as
the others).

> 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.

The problem is that "at least as much" is intrinsically ambiguous.
Non-elliptical shapes can stretch both inside and outside of an
elliptical curve.  Do you compare areas?  That's fairly complicated,
and I'm not convinced it'll do something useful. Do you weight
"inside" and "outside" differently?

>> 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.

I'm not sure I see how this works.

~TJ

Received on Wednesday, 21 October 2015 23:22:28 UTC