- From: Faruk Ateş <faruk@apple.com>
- Date: Mon, 12 Jan 2009 11:46:55 -0800
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: CSS mailiing list W3C <www-style@w3.org>
- Message-id: <35ABCEA2-8F71-4B47-B33A-8A9FDE72761B@apple.com>
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. 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. 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. Faruk
Received on Monday, 12 January 2009 19:47:37 UTC