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

Re: [CSSWG] Minutes and Resolutions 2009-02-04: box-shadow and border-image

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sat, 7 Feb 2009 19:21:12 -0600
Message-ID: <dd0fbad0902071721w44d9bf51l61387d972ba118b6@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: robert@ocallahan.org, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>

On Sat, Feb 7, 2009 at 5:04 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> Feature A: image-border (which can do the same things as feature B)
> Feature B: box-shadow & border-radius
> If these were consistent it would make them easier to understand.

This is the distillation of my feelings exactly.

As an author, I have a concept of "things that make the edges of boxes
look pretty".  The existing border properties, and border-radius
accomplish this, and they do this *well*, by providing me an extremely
simple way to add some common visual effects.

Conceptually, border-image is a distillation of that entire group into
a single comprehensive, powerful property.  It does *every* thing that
border, box-shadow, and border-image can do, and then some.  The
downside is that it's more complicated to use, and I have to do some
image editting.

These two things, the group of border properties and the single
border-image property, overlap each other completely.  Generally, I'll
only want to use one or the other.

This is how it feels to me as an author, and the spec writers agree.
When you use border-image, the border properties are completely
suppressed and border-radius is suppressed wrt the actual border (its
ability to clip content to the curved border is kept, as that has
nothing to do with the border per se).

Box-shadow is a slight outlier, but for the most part I, and I believe
most authors, consider it as a "thing that makes the edges of boxes
look pretty".  This may just be an artifact of the way we've been
forced to add shadows for years, through the use of background images,
but I feel it is also a relatively natural way to categorize it.

The connection isn't perfect, of course.  As noted, box-shadow doesn't
alter the flow of content, and it is transparent to mouse events.  In
most cases these are insignificant differences; as well, they are ones
that we authors have worked around for years with our own shadows, and
so have developed authoring methods to deal with it.

In time, I can see shadows being conceptually separated from the
border properties.  Right now, though, it does *not* play well with
border-image, and won't *ever* play well until we gain the ability to
define the shadow edge ourselves.  Despite Hakon's protests to the
contrary, I am certain that *I* will be using border-image mostly for
fancy shapes (our marketing department is enamored with a particular
shape of button that isn't reproducible with border-radius, even
ignoring the fancy display that is so hard to use in a flexible
manner), and I believe most authors will be similar.

Fwiw, I support changing the name of box-shadow to border-shadow, if
it helps the conceptual unification.  After all, since it responds to
border-radius, it is *not* actually a box shadow (as border-radius
doesn't alter the box - the cut out bits of the corners are still
opaque to events).  If we ever *do* support more complex shadow edges,
or more complex border edges in general, it will become even more
inaccurate.  There's some cognitive dissonance with calling it a
border property too, but I personally don't think it's as bad (and can
reconcile it with the fact that it's a 'shadow').

Received on Sunday, 8 February 2009 01:21:49 UTC

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