- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 23 Jul 2009 10:08:34 -0500
- 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. ~TJ
Received on Thursday, 23 July 2009 15:09:35 UTC