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

On Sat, Feb 7, 2009 at 4:55 AM, Brad Kemper <brad.kemper@gmail.com> wrote:

> On Feb 5, 2009, at 9:11 PM, "Robert O'Callahan" <robert@ocallahan.org>
> wrote:
>
> 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 not a huge deal, but it's something. You can use SVG images in
border-image to get nice scaling of those images; using SVG filters in the
image to produce a nice shadow would be a pain.


> 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.
>

So what?

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.
>

I don't know if your assumption is true, and you can't rule out other uses
even if it is.


> 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).
>

What has 'box-shadow' got to do with borders, on the face of it? If
border-image suppressed border-radius that would make a lot more sense,
since at least they both have 'border' in the name. If it was
'border-shadow', sure.

You may think it makes perfect sense for one property to turn off another
property whose name is not related, but I don't think you can speak for all
authors. Having "position" enable "z-index" made sense to someone but it's
real disaster for authors in practice. I don't want to go there again.

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?
>

Because "box-shadow" is not a border property. Dunno about border-radius;
the only reason to keep applying it would be to get proper hit-testing, and
there might be a better way to do that. That's a separate issue.


> 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.
>

As a browser developer, I can assure you that the vast majority of all users
do not disable images. The few users who do disable images obviously don't
care about visual effects on the Web and will not be disturbed by pages not
falling back to box-shadow.


> 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?
>

Because that's a very tiny benefit and the price is adding a confusing wart
to the platform which removes useful functionality.

If you want to serve these users better, I suggest adding a media-query
value that lets you detect in the stylesheet when image loading is disabled.


> 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.
>

So that designers can do useful effects and the platform is as uniform and
predictable as possible.

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.
>

I don't know.

You have very fixed ideas about how authors should and will use border-image
and box-shadow. In my experience it is difficult to predict how properties
will be used and in what combinations. It has usually been a mistake to
compromise orthogonality to try to optimize for some particular desired
combination.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]