W3C home > Mailing lists > Public > www-style@w3.org > July 2009

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 23 Jul 2009 08:55:50 -0500
Message-ID: <dd0fbad0907230655i7418930ey8edeb46d97278f70@mail.gmail.com>
To: Håkon Wium Lie <howcome@opera.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On Thu, Jul 23, 2009 at 4:12 AM, Håkon Wium Lie<howcome@opera.com> wrote:
> Also sprach fantasai:
>  > The issue has already seen much discussion, not just here but the
>  > last time it came up. It's closed, we have a resolution on it,
>  > and I do not want to reopen.
> The spec is only at WD stage -- when going to CR, W3C will specifically
> ask for implementation experience etc. Opera is reporting
> implementation experience now and I don't think the disucssion should
> be closed at this point.
>  > Please note that the use case for border-radius is to round the
>  > corners of a CSS box. It is not designed or intended to create
>  > wacky shapes.
> When other shapes naturally fall out from implementations, it may be
> worth reconsidering. Many CSS properties are used in ways that the
> designers didn't originally intend. Insisiting on limited use may not
> always be the best choice.
> Naturally, if Opera is the only ones who see any benefit from
> non-circular shapes, it will not happen. But, I believe we crossed
> that line by introducing (the syntactically quite challenging)
> different border radii for horizontal and vertical radii.
> Here's a suggestion: without the "/", radii are capped. This gives
> people the circular, protected shapes they want. However, when the "/"
> is used, radii are uncapped (or capped according to other, more
> liberal rules). Alternatively, another separator character or keyword
> can be introduced to express uncappedness.

Have we already forgotten the discussion over the % unit?  It was just
yesterday!  A solid % unit (unfortunately, implemented differently
from how FF currently does so in its prefixed property) solves real
use cases (I want a box that can maintain the same relative corner
shape/size no matter what size/shape it has) while it also happens to
allow those 'wacky shapes' you just demonstrated.

Here's the behavior I'm looking for (view in any recent Safari or
Chrome): http://www.xanthir.com/etc/stretchy-corners.html

Magic behavior switching *will* be confusing, whether it's based on
the presence of the / or the number of values or anything else.  When
I omit values I expect it to act *exactly* as if I had specified them
according to normal rules.

(The wacky shapes are awesome, by the way.)

(IMO, Chrome renders the curve better than WinSafari when either the
vert or horiz radius is much smaller than the other.  Safari seems to
do better when they're closer to the same size, though.)

Received on Thursday, 23 July 2009 13:56:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:27 UTC