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