W3C home > Mailing lists > Public > www-style@w3.org > September 2007

Re: [CSS3 Backgrounds and Borders] border-radius

From: Brad Kemper <brkemper@comcast.net>
Date: Mon, 10 Sep 2007 21:50:57 -0700
Message-Id: <33D1F2C4-A52E-4CD3-A32A-E6D8A5F72F69@comcast.net>
Cc: fantasai <fantasai.lists@inkedblade.net>
To: www-style@w3.org

>>> Brad Kemper wrote:
>>>> As a designer, I can't imagine ever wanting my curved corners to  
>>>> be chopped off to a pointy juncture between top and bottom  
>>>> curve. I would expect the radius to get smaller if the one  
>>>> specified doesn't fit, so that a rounded-corner box remained a  
>>>> rounded corner box.  As far as exploiting the effect, keeping  
>>>> the corners round would be a cool way to create a cheap circle  
>>>> box. just specify a corner radius of 100 inches, and then a box  
>>>> size of 1em x 1em. Resize the text and get different sized circles.
>>>> If you want pointy circles, you could use border images that did  
>>>> not resize.
>>>
>>> On Aug 29, 2007, at 7:53 PM, fantasai wrote:
>>>
>>> Ok, makes sense to me. If the bottom of the box had a zero border- 
>>> radius,
>>> would you allow the top border-radius to extend past 50% of the  
>>> box height?
>>> E.g. 100% to make a half-circle?
>> That's an interesting point. I can see both arguments:
>> 1. By limiting the radius to 50% or the box height and width, if  
>> you specified just one radius for the box, and then had zero  
>> radius for one corner, then the other three corners would still  
>> match each other. If you used JavaScript to change just one corner  
>> to zero radius, you would probably not expect the corner above or  
>> below it to double in size.
>> 2. There would be plenty of times though when you would want the  
>> the radius to be the full height of the box, such as when you  
>> apply the top rounded corners to the headline and the bottom  
>> rounded corners to some footer text. Or if you just wanted a  
>> rounded corners "tab" type of effect sticking up above the main  
>> block.
>> I suspect that the second option would be more important in more  
>> cases. For the first option, the negative points would just be a  
>> consequence of saying that you wanted the corners radiuses to be  
>> as large as possible.
>> So, if there was a "max-corner-radius", I would prefer it to  
>> default not to "50%", but to "implicit", that is, to as large as  
>> it can be which still maintaining a quarter-circle shape.
>
> Ok.
>
>>> What about more than 100% of the box height (the bottom corners  
>>> would be < 90deg)?
>>  I don't think I understand the question. If you mean less than  
>> 90 of arc on the rounded corner, I don't  think I would ever want  
>> that. At that point, it becomes a different shape, not a quarter  
>> circle anymore, and would be better handled by the limitless  
>> shapes of border-images.
>
> On Sep 9, 2007, at 9:13 PM, fantasai wrote:
>
> What I meant by more than 100% of the box height is e.g.
> border-radius 2in on a 1in box. The bottom corner would,
> if you drew a tangent line to the arc, also be less than
> 90deg, like this:
>
>               ###########
>            #            #
>          #              #
>         #               #
>        ##################
>
> ~fantasai
>

Ah, I see. I would say that it should try to maintain the aspect  
ratio of what was specified. So, if I was trying to specify the  
corners to be quarters of a perfect circle, and they could only fit  
in at half height, then they should also be half width. I say that  
because for most projects I can imagine, I would want perfect circle  
quarter-rounds. I think the overall shape of the curve specified is  
much more important than the maximum size available in one dimension,  
if the other dimension can't match it. See, this is consistent with  
my original assertion (no pointy joins if curves are specified) that  
the _shape_ of the corners is what is most important, as I would  
include aspect ratio as an important aspect of shape.
Received on Tuesday, 11 September 2007 04:51:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:52 GMT