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

On Thu, Feb 5, 2009 at 12:11 PM, Håkon Wium Lie <howcome@opera.com> wrote:

> Also sprach Tab Atkins Jr.:
>
>  > > That's fine, you are free to do so.
>  >
>  > Well, do you expect the majority of your border-images to be
>  > completely rectangular?
>
> I expect both. The example I've pointed to in the past is rectangular:
>
>  http://people.opera.com/howcome/2009/tests/borders/frame.png


That is a good example of an image you would edit before using. Because of
the color shifts along the sides from top to bottom, it would not work well
for tiling. And would look even worse if it had to be stretched much (the
pattern along the sides would be very distorted, but the corners wouldn't).
The only way it'd work is if your border-box was exactly the same size as
the image, in which case you mioght as well just use it as a single
background image. Plus, its huge (wastes bandwidth). No, you'd have to
reduce the length of each side to just one of those smaller pattern
elements, and then tweak the color and use the clone tool a little in order
to get a seamless pattern that matches up to the corners well.

And if you go to all that work, you might as well add whatever shadows you
want too.


 > >  > box-shadow will be more than useless in these
>  > >  > cases - it will produce a completely unintuitive shadow that
> doesn't
>  > >  > correspond to any visible edge.
>  > >
>  > > Perhaps. The solution is simple: don't set a box-shadow.
>  >
>  > That's perfectly fine in the case that you know all browsers are
>  > supporting border-image, and you know that your visitors are
>  > downloading images.  If they suppress border-image, or are using a UA
>  > which doesn't support it at all (but does support box-shadow), the
>  > simple solution doesn't work.
>
> We should aim to have implementations support complete modules --
> that's part of the motivation for splitting into modules in the first
> place.


As I mentioned earlier, it already doesn't stand by itself. It allows a
traditional border to be set, and then it overrides that, even to the extent
that it changes the border thickness. Why? For fallback. So that you can
have a regular border visible when image-border is not supported or not
being shown for some other reason.

By your logic, image-border should not prevent regular borders from being
shown. I can think of some useful effects if the original border appeared in
its original location and thickness (or perhaps centered within the new
width) behind the image-border. That could be used to change colors of the
border in places where you allowed it to show through transparent areas of
the image. Not that I would advocate that, but it follows your same logic of
not allowing the hugely valuable fallback story, in favor of a very marginal
benefit that can be replicated without having to give up on fallback.

It just doesn't make sense to allow border to be overridden but still exist
as a fallback, but not extend the same grace toward border-radius or
box-shadow.