W3C home > Mailing lists > Public > www-style@w3.org > June 2009

Re: border-image masking/hiding box-shadow

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 17 Jun 2009 13:07:42 -0500
Message-ID: <dd0fbad0906171107u66ff6d59saf9846b74ee1e39d@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org
On Wed, Jun 17, 2009 at 12:51 PM, Brad Kemper<brad.kemper@gmail.com> wrote:
> On Jun 16, 2009, at 11:47 PM, fantasai wrote:
>>  fantasai: using border-image to mask box shadow
>>  <fantasai> seems to be a slight preference for masking
> I think on first blush that a generated drop shadow sounds pretty cool. And
> maybe it would be appropriate if we had a 'drop-shadow' property. Once you
> create a non-rectangular, non-flat-sided border, you no longer have a box
> shape.
> What I think a lot of authors don't realize, and what wasn't presented as an
> important point in the blog prior to the polling, is that it means giving up
> much of the power, flexibility, and control that you get by putting the
> shadow directly into the pixels of the image itself when you create it, or
> else giving up the ability to have box-shadow as a fallback for the much
> more custom shadows people can create themselves in the image.
> By having the shadow in the image itself, the author or artist can decide
> exactly which parts get a shadow or not, whether or not the padding box
> should be shadowed in addition to the pixels of the actual border design,
> whether or not the shadow should extend behind translucent areas (and how
> much, or where the cut-off point should be). Plus, the artist can have
> different colors, blurs, distances, etc. for different elements of the image
> if he wants. But if he does any of that, then he would not want
> automatically generated shadows too, and would therefore have to turn off
> box-shadow if it was going to generate them (which means no fallback).
> I think if this point was made, the voting might have been different. Most
> box shadows in the wild will not need to be animated, and hover effects on
> shadows, if needed, can be done with a second image (which would not be a
> large imposition of the types of things that you would actually use hover on
> (like buttons), due to their small size.
> Automatically generated drop-shadows for non-box shapes really seems like a
> separate property to me, just as text-shadow is.

Again, I'm still with Brad on this.  Box-shadow should be a non-image
fallback for the more complex and complete shadows offered by
border-image (especially now that border-images can run outside of the
box without affecting layout), in exactly the same way that border,
itself, is a fallback for border-image when images are off.

There are also inherent issues with the masking approach when
non-transparent image formats are used.  In the center-clipping issue
several of the group expressed the desire to use jpgs in border-image,
but that conflicts with a masking approach here, as there's no good
way to specify what's supposed to be opaque and what's 'transparent'
for the shadow (at least, not without changing more syntax, frex to
specify a color that can be treated as transparent for masking

I do think that a masked shadow would be really cool, but, like Brad
suggests, as a separate property (or as an SVG control).  That way you
have more control over the shadow, can feed it an image that is
specially designed for masking, etc.

Received on Wednesday, 17 June 2009 18:08:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:27 UTC