W3C home > Mailing lists > Public > www-style@w3.org > May 2008

Re: [css3-background] box-shadow syntax

From: Eli Morris-Heft <dai@doublefishstudios.com>
Date: Fri, 09 May 2008 17:02:34 -0500
Message-ID: <4824C9FA.1080605@doublefishstudios.com>
To: Brad Kemper <brkemper@comcast.net>
CC: Alan Gresley <alan@css-class.com>, "www-style@w3.org list" <www-style@w3.org>


Brad Kemper wrote:
 > But it is possible that implementors (or others) might prefer a separate
 > keyword ("inner" | "outer") in addition to the slots for horizontal
 > offset, vertical offset, and blur. That was Eli's idea, Alan. I'm OK
 > with that too. It would be easy to understand and easily parsed . I
 > still like the elegance and brevity of my separate idea of just adding a
 > minus sign to indicate that the shadow is on the negative space instead
 > of the positive. I think "negative space" is a concept most designers
 > are familiar with. And that whole range of negative numbers is just
 > going to waste on blur anyway, which is the whole reason I would use the
 > minus sign there (the offsets already allow negative number measurements).

This much I agree with. But I still think that the fact that there's no way to
indicate a sharp inner shadow is a real impediment. A value of '-0', while
aesthetically consistent, really rubs me the wrong way. Any intuition gained by
using negative numbers is more than outweighed by the discomfort caused by
having to use '-0'. Plus, it would render parseInt functions and the like
unable to distinguish.

Look at it this way: we're using infinitely more numbers that we're throwing
away. /grin.

 > I agree with all that. I would also add a desire for an optional
 > "spread" value, which would thicken the shadow without making it more
 > blurry. The term "spread" is used in Photoshop, and it is similar to
 > drawing a same-color stroke of the specified thickness around the shadow
 > prior to blurring it. It is very useful, especially for shadows on small
 > elements (or text) where you want to see a little more of the shadow
 > without offsetting it more or blurring the heck out of it.

And it makes a much easier way to turn a shadow into a glow (text-shadow: 0px 
0px 0px 4px blue), and add a bit of perspective. I like it. I hope the 
implementors do too.... I propose that it goes after the blur radius:

box/text-shadow: none | [[<shadow-def> || <color>] [inner | outer]] [, 
[<shadow-def> || <color>] [inner | outer]]*

where <shadow-def> is: <length> <length> [<length> <length>?]?

The lengths in <shadow-def> are, in order, the horizontal offset, the
vertical offset, the blur radius, and the spread thickness. Any length omitted
in the box-shadow value is assumed to be 0. The blur radius may not be negative. 
In the absence of an 'inner' or 'outer' keyword, UAs should assume an 'outer' 
keyword. UAs may treat a body/text-shadow value where all lengths given are 0 as 
equal to a value of 'none'.

...assuming everyone else likes this idea too. I do get the slight sensation of 
feature creep, though, so maybe we should stop here before loading too many 
bells and whistles onto this gong?

Eli Morris-Heft
dai@doublefishstudios.com
Received on Friday, 9 May 2008 22:03:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:06 GMT