- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sat, 7 Feb 2009 19:21:12 -0600
- 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'). ~TJ
Received on Sunday, 8 February 2009 01:21:49 UTC