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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 16 Jan 2009 12:34:29 -0600
Message-ID: <dd0fbad0901161034r37521ae1qc0d9659d507a0f3d@mail.gmail.com>
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.


> 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

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.

Received on Friday, 16 January 2009 18:38:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:23 UTC