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

Re: Drop-Shadow proposal

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 11 Sep 2009 14:55:12 -0700
Message-ID: <4AAAC740.2090604@inkedblade.net>
To: Brad Kemper <brad.kemper@gmail.com>
CC: David Hyatt <hyatt@apple.com>, www-style list <www-style@w3.org>
Brad Kemper wrote:
> 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.

'drop-shadow' should definitely not inherit. If it does, it means there's
no way to tell what element the shadow is actually specified on. (Or,
alternatively, that every element it inherits to is shadowed, which is
not useful.)

Received on Friday, 11 September 2009 21:55:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:39 UTC