Re: [css3-background] box-shadow syntax

On May 9, 2008, at 5:09 PM, Alan Gresley wrote:

>
> Eli Morris-Heft wrote:
>> Alan Gresley wrote:
>>> 0px 0px 0px 4px blue
>>>
>>> What does the third value do?
>> The third value is blur radius, as it currently is in the spec. The  
>> fourth value is Brad's proposed 'spread' width.
>
>
> Ops, sorry, I should have said what is the fourth value?
>
>
>>> For me a minus value is no value at all if we are talking about a  
>>> width. Having a -4px width doesn't sound right and can be mixed up  
>>> with minus (x/y) positions of a shadow.
>>> /* ...snip... */
>>> What we were initially talking about is glow, blur or inner.
>> I thought what we were initially talking about was a shadow, not a  
>> glow...
>
>
> Well of course we talking about shadow, text-shadow and box-shadow.  
> What I am suggesting is what type of shadow it is. Does it show a  
> graduation? Is it pixelated or smooth?. Does it suggest graduation  
> to emulate depth of field (perspective)? It it neon, glow, electric  
> (suggesting energy). All is it misty, foggy, ghostly (suggesting  
> movement)?
>
>
> What could be possible by implementation in 2020?

I don't think we need to deal with that yet, and I would like to see  
useful features implemented, rather than endlessly adding on extra  
parameters until it becomes a tool for designing logos or something.

Being able to control spread, and being able to cast the shadow inside  
as well as outside, are features that would be very useful, much used  
additions. I don't think it has to replicate everything that PhotoShop  
can possibly do to shadows, but I already miss "spread" when I am  
trying to create CSS shadows in Safari, etc. And as Eli pointed out,  
it would open up the ability to have more control over making a shadow  
look like a glow (the only difference between a shadow and a glow is  
color and offset). And being able to cast an inner shadow is also a  
very useful effect, especially for boxes. Anything more, such as glow  
type, is likely to just delay and complicate the implementation, and  
would not be very important for most authors (IMHO).

> Do we just have now for CSS the first case.
>
> box-shadow: 0 0 blue;
> box-shadow: 0 0 ? blue;
>
> An implementation that only support shadow offset will only use the  
> first declaration and throw out the second declaration since it has  
> four values. Future implementations could use either declaration,  
> the second one with value (?) allowing for progressive enhancement  
> in CSS4.
>
> I can see this getting out of hand already (let's consider the  
> consequences). I believe that all extra inner, outer and whatever  
> values should appear last as.
>
>
> box-shadow: 0 0 blue ?;
>
>
> since an implementation supporting an extra values as
>
> box-shadow: 0 blue ?;
>
>
> will be considered by an implementation as.
>
> box-shadow: 0 0 blue ?;
>
>
> Any non supporting implementation would throw the declaration out.

That would be the case regardless of order. I'm not exactly sure I  
know what you are getting at with the question mark. At least with box- 
shadow, the implementations are still experimental, so changes can be  
made. But for both, if we followed Eli's syntax (in which the spread  
distance and the inner/outer keyword follow the other three  
distances), people would be able to continue to specify the shadows  
the same as they have been, and that would still do the same thing. It  
allows for progressive enhancement, because you could have one rule  
for older implementations (of text-shadow), followed by a rule for  
newer ones.



>
>
>
> Alan
>
>

Received on Saturday, 10 May 2008 03:52:38 UTC