Re: [css3-background] should radii be capped?

From: "Tab Atkins Jr." <jackalmage@gmail.com>
> On Wed, Jul 22, 2009 at 5:41 AM, Håkon Wium Lie<howcome@opera.com> wrote:
>> Maciej Stachowiak wrote:
>>
>>  > I think authors are more likely to want to achieve and preserve a
>>  > "rounded rectangle" shape with circle-arc corners, and have that
>>  > maintained independent of resizing, than to want to achieve an
>>  > elliptical shape and have that maintained independent of resizing. If
>>  > the latter use case is actually important, then it may deserve some
>>  > special syntax, such as percentage units for border-radius.
>>
>> Yes, I think the use case is important. And it would fall out
>> naturally from % units, when introduced on 'border-radius'. In fact, I
>> discovered that this already works in Opera's implementation (which
>> isn't publically available yet). Test case and screen shot are here:
>>
>>  http://people.opera.com/howcome/2009/tests/border-radius9.html
>>  http://people.opera.com/howcome/2009/tests/border-radius9.png
>>
>> Zack Weinberg wrote:
>>
>>  > As of FF3.5, Mozilla still does support percentages in border-radius,
>>  > but the percentages are always interpreted relative to the outer
>>  > *width* of the border box, even for the vertical semi-axis of an
>>  > ellipse.  This is so we can continue to get circular arcs for
>>  > "border-radius: 10%" without messing with the defaulting rules.
>>  >
>>  > I'd be happy to change that at least somewhat, but I think
>>  > "border-radius: 10%" needs to keep doing quarter circles.
>>
>> So, you'd like for percentage values to always refer to the width?
>>
>> This, alas, seems incompatible with the request for ellipsis.
>>
>> I can see four possible solutions:
>>
>> 1) We introduce % units and specify that percentages refer to width
>>   /or/ height. This makes 'border-radius: 50%' become an ellipsis.
>>
>>   The syntax seems natural, but percentage units would not guarantee
>>   shape.
>>
>> 2) We introduce % units, but only 'border-radius: 50%' gives you an
>>   ellipsis. 'border-radius: 49%' would not.
>>
>>   This is probably not a good solution, as roundoff errors could
>>   create interoperability issues.
>>
>> 3) We introduce a keyword, e.g., 'border-radius: ellipse'.
>>
>> 4) We allow the '/' in the syntax to act as a switch:
>>
>>     border-radius: 50%;         /* refers to width of element */
>>     border-radius: 50% / 50%;   /* refers to width/height of element */
>>
>>   This is probably overloading the '/' notation.
>>
>> My preference is for 1. There are other ways to guarantee shape (use
>> pixels, ems etc). But, it seems that Mozilla would have to change.
>>
>> 3 would also work.
>
> I really hate #2, and dislike #4.
>
> To determine what my feelings were on #1 and #3, I played with FF's
> support for % in border-radius.  After a bit of resizing my browser
> window and watching the pretty corners change size, I think I can
> firmly state that FF's behavior is *not* what I would generally want.
>
> In a normal situation, I tune the size of the box corners to an
> attractive level based on the box.  While the size of the box may have
> some effect on my decision, much more important is the contents and
> visual nature of the box - a more playful box might have larger
> corners, while a more mundane one that I'm just trying to spruce up a
> bit might be given a basic 5px or so radius.  The actual box size is
> more important only in what I *intend* the box to look like - I
> reasonably tend to reserve large corners for larger boxes.
>
> If I *do* want a box's corners to depend strongly on the size of the
> box, it's feels like it would only be in the situation where I know
> that a box can vary wildly and unpredictably in size, and I just want
> to ensure that the corners don't end up looking dumb.  In this case
> maintaining absolute shape isn't as important as maintaining
> *relative* shape.
>
> So in conclusion, I believe that in my work I would be best served by
> % units that scale with the side's length (that is, by the width *or*
> height depending).  This can on occasion produce slightly unattractive
> results (a box that I intend to be fairly squareish ends up very wide
> and short, frex, resulting in a long curve on the corner), but it's
> not overly bad.  It also happens to support the ellipse case, which is
> interesting enough to warrant supporting *somehow*.
>
> Support for #1, then.
>
> ~TJ
>

Another solution would be to take in consideration the smallest side of
the box : 100% == min(width,height)

So, you would have a solution for case when you need a rounded and
not eliptic border, but whose size is adapted to the size of the box.

But, for me, the best solution would be to have a keyword to specify which
behaviour the author want (border-radius-type: (elliptic|rounded))

You would then have two behavior :

border-radius: 50% elliptic; ==> A perfect ellipse
border-radius: 5% rounded; ==> A 'sqare' rounder border (5% refering to
the smallest length between width and height)

Please note that #1 would be great too, but we must then assume that there's
no use case for relative rounded border radius.

Regards,
Fremy

Received on Wednesday, 22 July 2009 15:31:06 UTC