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

Re: [css3-background] does border-radius round the border-image ?

From: Brad Kemper <brad.kemper@gmail.com>
Date: Mon, 12 Jan 2009 13:31:48 -0800
Cc: CSS mailiing list W3C <www-style@w3.org>
Message-Id: <2F2580AE-0644-4D29-B19C-9D2B2E7CF3B0@gmail.com>
To: Faruk Ateş <faruk@apple.com>

On Jan 12, 2009, at 11:46 AM, Faruk Ateş wrote:

> On Jan 10, 2009, at 10:15 PM, Brad Kemper wrote:
>> I did some test cases and saw how they rendered in a recent WebKit  
>> nightly and Firefox 3.2 nightly. I used 'background-clip:padding- 
>> box;', which shows the importance of not clipping the border-image  
>> based on the border-radius (at least not to do so in that  
>> situation, IMO, but I believe its the same problem with default  
>> background-clip, just not as obvious).:
>>
>> http://www.bradclicks.com/cssplay/BorderImageAndRadius.html
>
> I think there's just a different interpretation of the spec, here.  
> To me, using background-clip: padding;  would presumably render the  
> background to content+padding box, clipped only by the external  
> radius of any possibly-applied border-radius. This is what WebKit  
> does.
>
> What you're expecting, however, seems to be that the background  
> should be clipped to the inner circle of the border-radius, in this  
> case severely impeding on the boundaries of the padding box. Or  
> really I should say, largely not even reaching the boundaries of the  
> padding box. This is what Firefox does.
>
> I don't think either browser is right or wrong, I think the spec is  
> inconclusive as to what the behavior should be like.

That's why I mentioned it. I think the spec should say one way or the  
other so that implementations are consistent.

> I can see arguments for both interpretations, but I'm personally  
> inclined to side with WebKit's implementation simply because the  
> padding of the box (and the content box itself) don't get their  
> foreground dimensions curved, i.e. the text is still in a  
> rectangular box, and the padding around the text is still a  
> rectangular box as well.

I couldn't find a definition of "padding-box" anywhere, but presumably  
it is based on "padding edge" [1], which was defined without any  
expectation that the inside edge of the border would be any different  
from the outside edge of the padding. Border-radius makes it different.

 From an author utility perspective, with regards to backgrounds, the  
difference between padding-edge and border-edge for "background-clip"  
is about two things:

1. Whether or not part of the background will be covered by the border  
(when tiling, for instance), and

2. Whether or not the background will be visible in the gaps between  
dashes or dots(or in the space between double lines, presumably,  
although I have not tested that).

So for authoring, I would expect "background-clip" to determine  
whether "border-radius" does its clipping on the inside of the border  
or the outside. But WebKit just shows the intersection of the clipping  
based on the outside edge of the border-radius and a clipping based on  
the outside edge of the padding. I find that significantly less useful  
when combining these properties. I cannot imagine any cases where I  
would want the background to continue under the border when background- 
clip: padding-edge is used, since it would generally be used  
specifically to prevent that.


>
> Perhaps an expansion to the spec here would be useful, as I can see  
> reason for both scenarios to co-exist rather than one being dropped  
> in favor of the other.

Can you give an example of where you would see a reason for the  
background to continue under the border when background-clip: padding- 
edge is used?

>
> Faruk

[1] http://www.w3.org/TR/2007/CR-CSS21-20070719/box.html#box-dimensions
Received on Monday, 12 January 2009 21:32:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:15 GMT