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

Re: Drop-Shadow proposal

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 16 Sep 2009 10:12:21 -0700
Cc: www-style list <www-style@w3.org>
Message-Id: <400FDCC1-FC23-4EBC-8FE2-1F70C51D7E41@gmail.com>
To: David Hyatt <hyatt@apple.com>

On Sep 11, 2009, at 4:22 PM, Brad Kemper wrote:

> On Sep 11, 2009, at 1:00 PM, David Hyatt <hyatt@apple.com> wrote:
>>>> Opacity means you push a single layer, do all the painting into  
>>>> that layer, and then apply the alpha to the entire layer.   
>>>> Shadows would work the same way, but applying a shadow rather  
>>>> than an alpha.  That's why opacity establishes a stacking context  
>>>> and has a z-index of 0 by default.  By doing so, you guarantee  
>>>> that you don't ever have to push individual layers even if you  
>>>> have positioned children.
>>>> It's far more intuitive to simply follow the document tree like  
>>>> opacity does.  Authors get so confused when you start bringing in  
>>>> these other child hierarchies and trying to make exceptions for  
>>>> certain children.
>>> 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.
> OK, I am willing to revise my proposal.
> With opacity, there's some clear logic to mutiplyong the opacities  
> of children to the opacities of parents. But with shadows, I don't  
> think it makes sense for a child with its own drop-shadow (or box- 
> shadow or text-shadow) to also share the drop-shadow of the parent  
> layer, does it? Could giving it a different shadow than that parent  
> context be enough to mean that it should bust out of that parent  
> shadow layer and form it's own stacking context? It would be  
> different from opacity though...

Or maybe a new property, like this:

.no-more-shadows { reset(drop-shadow: 0 0 0 transparent); }
.opaque-regardless-of-parent { reset(opacity: 1); }
.viewport-context { reset(position: static);  }

I'm not exactly sure how that last one would work, or if it could  
somehow, but the idea is that the element would appear in the same  
place and z-index it would have if its ancestor(s) had not been  
Received on Wednesday, 16 September 2009 17:13:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:29 UTC