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 10:08:34 -0500
Message-ID: <dd0fbad0907230808x3201e317md4f59526433f38f@mail.gmail.com>
To: François REMY <fremycompany_pub@yahoo.fr>
Cc: CSS 3 W3C Group <www-style@w3.org>
On Thu, Jul 23, 2009 at 9:55 AM, François REMY<fremycompany_pub@yahoo.fr> wrote:
> From: "Tab Atkins Jr." <jackalmage@gmail.com>
>> On Thu, Jul 23, 2009 at 9:30 AM, François REMY<fremycompany_pub@yahoo.fr>
>> wrote:
>>> From: "Tab Atkins Jr." <jackalmage@gmail.com>
>>>> 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.
>>> Would a keyword be a good solution at your eyes ?
>> Did you mean this to be off-list?
> Not particulary. Pressed the Reply button instead of Reply all. Fixed.
>> Anyway, what would this keyword *do*?  I don't want to switch between
>> capped and uncapped radiuses, like Hakon is talking about.  That's a
>> red herring.  I want percentage-based radiuses that work as expected,
>> rather than the odd way that FF currently has them working.  I don't
>> think that a keyword should be necessary to switch between my expected
>> behavior and FF's current behavior, either - from my pov FF's behavior
>> is just plain wacky, and not actually useful to me as a designer.
> As you noted, they are ugly artifacts when the the border-radius is too
> small
> on a part, and great on the other part. A designer may want a square radius
> as it's more beautiful.
> You may argue that the problems may be solved using antialiasing, but even
> with that, you will continue to notice problems.

Yeah, but that really only happens when they get *really* thin in one
direction.  In most situations it's no problem at all.  If I'm
expecting that my box may commonly get below one line-of-text in
height, I should probably use a length unit instead.

> Personnaly, I would love to have a way to have the 100% unit to have the
> same
> value as min(width, height). It can help me to make a circle radius border
> that
> grows as the box I use grows.
> Imagine the case of a [25% * 2000px] box that would be the main content of
> my page. If I want the rounded border to be in function of the width of the
> page,
> I must use a % unit. But if the result DIV is 250px * 2000px, your behaviour
> will
> result into a not so beautiful radius. The solution used by FireFox would
> produce
> a better result, to my opinion.

Yeah, but when your div is 2000px by 250px, the Firefox solution gives
you a lozenge (half-circles on the ends).  That's not so attractive,
and almost certainly not intended.

> Try it with a 1% border radius. Your solution would create a 3*20px border
> radius
> while the FireFox solution produces what I intended : a 3*3px border radius.
> Would it be so bad having a (facultative) keyword that specify whether to
> use one
> or the other solution to compute the % unit ?

While I wouldn't overly *object* to such a thing, I just don't find it
very *necessary*.  In every situation I can currently imagine myself
using a % border radius, I don't want the FF behavior.

Received on Thursday, 23 July 2009 15:09:35 UTC

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