Re: [css3-background] box-shadow and border-image

On Jul 23, 2009, at 2:41 PM, fantasai wrote:

>  First: The purpose of 'box-shadow' is to create the effect of
>         cutting the box out of the canvas and shifting it up
>         above the canvas. It is not about drop-shadowing the
>         foreground content. Drop-shadowing all or part of the
>         foreground content is a cool feature, but it's a different
>         feature. Not part of this discussion. See e.g. roc's work
>         on SVG filters for HTML. [1]

I agree with this sentiment in principle. Specifically, it is about  
creating a box-shaped shadow (note that it does not follow the  
contours of dashed lines, etc.). It has never been about the alpha  
channel. It is not about creating shadows for images. It has never  
been about shadowing background images, foreground images, list-item  
images, translucent fills, or translucent border colors, and so seems  
out of place to create a special kind of shadowing images in the  
border. To rephrase your sentence a little: Creating shadows based on  
images and transparency is a cool feature, but it's a different feature.

>  Second: box-shadow as a fallback for failed border-image loads
>         is IMHO a very minor concern, and not enough to block
>         significant use cases for box-shadow. Fallback design
>         for when images are turned off is a general problem:
>         I don't disagree that it warrants a solution, but a
>         general solution such as a media query is a far better
>         approach than trapping ourselves here.

Graceful degradation is a laudable goal, and not something that should  
be dismissed too quickly. It is a short conceptual difference between  
saying that "fallback to regular box shadows is not important" and  
"fallback to regular borders is not important" (they are both  
decorative effects that help delineate the edge). Yet we do have a  
mechanism to allow regular borders as fallback, but not currently to  
allow regular shadows as fallback.

I agree that graceful degradation should not block significant use  
cases for box-shadow, but I question how significant the use cases are  
that are being blocked, and their relative importance if they are only  
edge cases.

> Third: This module is very close to done, and its features are
>         highly desired in the CSS design community. Unless we
>         are painting ourselves in a corner with a limitation or
>         e.g. roc and hyatt are super-excited by a new ability
>         and are like "I am so going to implement this now", new
>         capabilities should be deferred to the next level of
>         this module. Otherwise CSS3 Backgrounds and Borders
>         isn't going to make it this year.

This is exactly my feeling. I think we mostly agree though that the  
current effect of "basing the shadow on some rectangle that no longer  
exists once a fancy border is added" is not what we want (especially  
since it fills that shadow differently in WebKit than in Firefox). So,  
we should anticipate 'border-shadow' or SVG drop shadows or the like  
for some point in the future, but for now suppress the undesirable  
rectangular shadows when border-image is in use. Then, later, when we  
have something to do fancier non-box-shaped shadowing, it too can  
suppress the more rudimentary box-shadow.


> Use Case and Constraints:
>
> There are many possible border-images that don't fit the use case
> for 'box-shadow': specifically, border-images that don't create a
> continuous division between the interior and exterior of the box,
> so the concept of "cutting out the box" doesn't make any sense.
>
> The border-image in Chris's document is one such image:
>  http://www.w3.org/2009/07/B-and-B/no-drop.png
>
> Such images are not candidates for 'box-shadow': there is nothing
> reasonable you can do with them to get a pop-out effect for the
> box itself even if you Photoshop the whole element after rendering.

I agree.

> [...]
> There are three classes of border-images that can be box-shadowed.
>
>  A. Cases that can be easily handled by UA alpha-masking
>  B. Cases that can be easily handled by adding the shadow to the  
> image.
>  C. Cases that can't be easily handled by either method.

The thing is, I think that for real-world use cases, "B" would be the  
vast majority. Even without considering shadows, there are limits to  
what you can do with border-image. You cannot create opposite side  
sections that have different lengths from each other, for instance, or  
divide the 9 sections using diagonal or non-straight lines, or have  
side sections that are wider than the corner sections. So it is always  
up to the artist to create an image that can be divided well into the  
9 sections according to the constraints this puts on the design, while  
still ending up with sections that can stretch or tile effectively.

In my view, Chris' s image does not do that so well, and is an  
unlikely choice from a designer in a real-world situation. I think it  
is unlikely that a designer would create a perfectly circular shape  
and then expect it to stretch well to something like 9 times its  
original height (aside from the fact that it turns a circle into a  
long pointy thing, in a raster image you would get more pixilated the  
more you stretch it, and the pixels on the ends start looking chopped).

If I was working with this design and wanted something that could  
stretch well vertically, I would probably cut the image differently,  
with the end-caps of the vertical circle inside the corner sections,  
and a flat-edged middle-left-and-right-sides doing the stretching  
(creating more of a lozenge shape). Because "stretch" works best with  
designs that are straight and flat, or can otherwise handle a lot of  
distortion better than a circle can (or with elements that are  
expected to stretch only a little if at all). The designer/author has  
to consider how much an image is likely to stretch when he creates the  
image section to be stretched, and if he desires a shadow that will  
also figure into the design decisions. But at least he has the power  
to make those decisions.

Adding another circle or so in the horizontal position and then  
dividing it differently would allow the circles and shadows to tile  
nicely horizontally, without a change in the design.

I think the changes I describe above would look better this way even  
without the shadow, and would allow the shadow to also work much  
better. Good design is always about working within certain  
constraints; given the distortion that stretching creates, and the  
limits it puts on my desired shadow, I would thus adjust the design to  
compensate, and not feel that I had lost something important.

Here is the image I described, with blue lines indicating where it  
would be sliced:

http://www.bradclicks.com/cssplay/New_transborder.png

And how it would look in a text block like Chris's:

http://www.bradclicks.com/cssplay/New_drop.png

My main point with all this is that even though we can create  
hypotheticals that don't work well with the shadow built into the  
image, in actual usage this will be much less of a significant design  
constraint, compared to existing constraints. Having a good fallback  
situation is thus more important to me than dealing with edge cases  
such as Chris's design (no offense, Chris).