Re: [css3-background] box-shadow syntax

On May 9, 2008, at 7:58 AM, Eli Morris-Heft wrote:

>
> I apologize in advance for the length here. I'm feeling verbose  
> today. ^^
>
> Alan Gresley wrote:
>>> box-shadow: none | <shadow> [inner | outer] [, <shadow> [inner |  
>>> outer]]*
>>> where <shadow> is: [<length> <length> <length>? || <color>]
>> Ok, the default could be.
>> 4px
>> and optional keywords (in brackets)
>> 4px(even) -  no graduation.
>> 4px(inner)
>> 4px(electric)
>> 4px(ghostly)
>> 4px(foggy)
>> 4px(cloudy)
>
> Whoa, there. If I may be so bold, I think this is the *wrong* way to  
> approach this. This is an entirely new sort of format to be using  
> for values of CSS properties, and I'm not sure it buys us anything  
> over just using keywords. Plus, there're already kinds of values  
> that use parentheses, and they generally indicate functions, and  
> don't have names that change: rgba(), url(), hsla(), etc. Making UAs  
> parse for these when you could have 4px(), -3px(), 1em(), 0.5in(),  
> 18cm(), etc., is a nightmare.

I agree. What I originally proposed was using a minus sign on the blur  
value to indicate that it was an inner shadow instead of outer. The  
reason I thought that would be good is because it would use existing  
value types, would not change how box-shadow and text shadow are used  
with outer shadows, and would be simple to parse (in theory).

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

> Setting aside that "inner" wouldn't control the same kind of thing  
> "cloudy" might, and that I don't know how I'd draw an "electric"  
> shadow, I think that (a) UAs would have a heck of a time trying to  
> figure out what to do with this, (b) it would make UA  
> implementations vastly different and unpredictable, and (c) as a  
> developer, I happen to think this is a pretty confusing syntax.
>
> Having two lengths for positioning, a possible length indicating the  
> extent of the blur on the shadow (which, keep in mind, doesn't  
> extend the shadow any; it just makes the outer edges and portions  
> more blurry), a possible color, and an indication as to whether it's  
> an outer or inner shadow is perfectly fine for here, I think.

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.

Received on Friday, 9 May 2008 17:02:41 UTC