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

Re: Drop-Shadow proposal

From: Brad Kemper <brad.kemper@gmail.com>
Date: Fri, 11 Sep 2009 14:01:53 -0700
Message-Id: <19B03F4F-BB97-4D5C-ADD7-E5EF1463227C@gmail.com>
To: David Hyatt <hyatt@apple.com>
Cc: www-style list <www-style@w3.org>
On Sep 11, 2009, at 1:00 PM, David Hyatt <hyatt@apple.com> wrote:

>> This author finds the inability to 'opt out' of the inheritance of  
>> opacity (to have a child that is more opaque than it's parent) to  
>> be a huge limitation. Since I was drafting my ideal, I did not want  
>> to repeat that limitation.
>>
>
> Not being able to opt in is just as problematic.  I think  
> consistency with opacity is more important.  If we ever want to  
> "break something out of" a pushed layer, I think we could come up  
> with a consistent way that could apply to shadows and opacity anyway.

Another related thing was that I wanted to be able to use drop-shadow,  
box-shadow, or text-shadow on a child element, with a non-default  
value, to be able to override the shadow that the parent was giving  
it. That's in there somewhere too (I don't have the document in front  
of me at the moment). Would that be equally problematic in your view,  
or would that be an acceptable way to cause it to break out of the  
inherited shadow?

Perhaps any value other than 'inherit' on any of those three  
properties would cause this break out behavior.

I'm not sure if I mentioned it, but I was assuming that this 'drop- 
shadow' property would override 'box-shadow' and 'text-shadow' set on  
the same element. So the override would happen in the opposite  
direction if the drop shadow was just being applied as a result of  
opacity-like inheritance.

I'm not sure something so simple could work for opacity though,  
without breaking existing Web pages. 
Received on Friday, 11 September 2009 21:02:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:21 GMT