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

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

Received on Wednesday, 22 July 2009 15:18:24 UTC