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

On Feb 5, 2009, at 9:11 PM, "Robert O'Callahan" <robert@ocallahan.org>  
wrote:

> On Fri, Feb 6, 2009 at 5:31 AM, Brad Kemper <brad.kemper@gmail.com>  
> wrote:
>
> 1. Having box-shadow and border-image visible at the same time is  
> NOT useful. Those who are creating the images for border-image can  
> very easily create them with shadows already included in the  
> images[3].
>
> Incorrect.

No it's not.

> CSS box-shadows will typically look a lot better than image shadows  
> if the user zooms or prints.

You really think that matters? It's a shadow! It usuallyvisnt sharp  
anyway!  I really don't understand why the resolution of a few blurry  
gray pixels of shadow is so much more important than the resolution of  
the decorative border right along side it (when it does occasionally  
happen to be right along side it). What kind of detail do you hope to  
see when you zoom in on a couple millimeters of blurred translucent  
gray? Both the image-border and the shadow serve to decorate the edge  
of the box, but of the two, the detail of the lines and shapes in the  
border are much more important than the sharpness of the blurry shadow  
they cast. And I'm saying this as someone who expects to actually be  
using both properties in my pages. I could care less if the print  
resolution of the shadow is ONLY THE SAME as the rest of the border- 
image. Especially since box-shadow won't be useful for most of the  
images I would use on borders anyway!

> Also, CSS box-shadows do not stop events from reaching the elements  
> underneath them, which is very useful when they're translucent; you  
> can't emulate that with border images.

Well that's a new argument at least. It didn't seem to figure into the  
WG discussion though. Of course, the biggest advantage of image-border  
is to create shape that an ordinary border box can't, so if you use  
them on links, for instance, the active area won't follow the complex  
edge anyway.


> Adding a shadow to a border image is a lot of extra work that you  
> can avoid using box-shadow.

You have got to be kidding. When I put together that TV set image  
border in the example I posted earlier, adding the shadow was by far  
the quickest part of it. It only took an extra couple minutes and was  
very simple to accomplish.

> It will also make the image bigger and slower to load.

Check the file sizes. It adds very little to the file size, especially  
if we ate talking about the very small images that you would use for  
buttons. And on todays Web, it is already the most common way to add a  
shadow to an element. It is not burdonsome at all.

> Having border-image disable box-shadow would add a strange wart to  
> the platform that would confuse authors

No way. I am an author and the main thing that confused me is why some  
of the edge decorating effects that image-border can replace are  
suppressed (border style, weight, and color), and some are not (box- 
shadow and border-radius). Why were the traditional border properties  
allowed to coexist in a way that intrinsicly acknowledged their value  
as fallback, but then fallback is ignored for shadows and corners?


> and prevent useful applications of these features. The only benefit  
> would be better fallback when border images are not loaded or in  
> browsers that support box-shadow but not border-image; but the  
> former is extremely unusual in practice

Turning off images for bandwidth considerations is not all that unusual.

> and the latter is not worth worrying about.

I can easily imagine UAs used in low bandwidth situations that would  
have box-shadow but not image-border. Why don't you want me to give  
them a nice presentation with box-shadow as a substitute?

> In either case, falling back to no shadow at all is just fine.

If it is so fine to have no shadow in that case, then why insist that  
it be visible in the other case when it is specified along image- 
border, when image-border does  a better job of matching it to the  
shape of the edge.

And if fallback for the no image-border situation is so unimportant,  
then why was such effort put into allowing border and image-border to  
be author specified at the same time, with the thickness of the image- 
border based on the border-width of a border it hides? Why didn't we  
just make the two properties independant with one drawn under the  
other? It could have allowed for some interesting color changes of the  
border-with-a-border via DOM during mouseover.