Re: Drop-Shadow proposal

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

Received on Friday, 11 September 2009 23:23:02 UTC