- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 16 Jan 2009 12:34:29 -0600
- To: "Brad Kemper" <brad.kemper@gmail.com>
- Cc: "David Hyatt" <hyatt@apple.com>, "L. David Baron" <dbaron@dbaron.org>, www-style@w3.org
On Fri, Jan 16, 2009 at 11:49 AM, Brad Kemper <brad.kemper@gmail.com> wrote: > I have created a test page: > http://www.bradclicks.com/cssplay/TV-Border.html > This page shows how "border-image" can interact with a few other properties > to meet my authoring expectations, and how well the bleeding-edge versions > of WebKit and Firefox (Minefield) meet those expectations. The design and > expectations are based on the notion that one of the key benefits > of border-image is in creating border shapes that cannot be created with > traditional border edges. Another is that the author may want to be able to > create a best-case fallback for UAs that don't support border-image. > Among my observations: > 1. "background-clip" plays a vital role in combining "border-image" and > backgrounds. Agreed. > 2. That while some might consider it reasonable to clip the border-image > based on the curved corners of a stroked border of a different width that is > hidden by border-image (I don't), it really doesn't make sense to do so when > the background is clipped to the padding-box. In those cases, the > border-image (which can create a completely different shaped and width > border than the stroked border) is the only thing that is being clipped by > that line. And if, as David Hyatt indicated elsewhere, WebKit will be > trimming the background and foreground to the inner edge of the curve, then > the outer edge curve of the corner should not play a role in clipping other > things anyway. But the border-radius does still have a useful purpose for > fallback and for trimming other things along its inner edge. Agreed on both counts. I don't think border-radius should clip border-image when background-clip is set to border-box, but it *really* shouldn't do so when set to padding-box. As you noted, border-radius is essentially a fallback for border-image. It is used only when your display doesn't need anything as complex as a full border-image, and can be employed to mimic a border-image in agents that don't yet support them. > 3. Box-shadow can be useful for fallback, but has no other significant > useful role when border-image is present. Any desired shadow can be created > in the same image pieces used anyway for border-image. The only (slight) > advantage box-shadow has over image-based shadows (once you are using images > for your borders anyway) is that box-shadows don't take up space. But given > that the space can be dealt with via negative margins, etc., and that the > shadow will often (if not usually) follow a different path that that of the > outer edges of the images, then fallback becomes the most useful reason to > combine border-image and box-shadow. Thus, just as the stroked border is > hidden when border-image is being used, so should the box-shadow be hidden. It took me a bit, but I agree with you now. Sometimes box-shadow can be usefully combined with border-image, but in those cases you can just put the shadow in the image directly. In other cases, though, box-shadow produces a *horrible* effect when combined with border-image. So the choice is between occasionally *slightly* increasing the work of the web designer (though they're already creating an image, so putting a shadow on it shouldn't be difficult), and often preventing any sort of shadow fallback at all. I support the former. So, to be completely clear, I support border-radius clipping both foreground and background content, but not border-image, no matter what value background-clip is set to. I also support border-image overriding box-shadow. ~TJ
Received on Friday, 16 January 2009 18:38:31 UTC