Re: Drop-Shadow proposal

On Sep 11, 2009, at 11:49 AM, David Hyatt <hyatt@apple.com> wrote:

> On Sep 11, 2009, at 1:40 PM, Brad Kemper wrote:
>
>> On Sep 11, 2009, at 10:57 AM, David Hyatt <hyatt@apple.com> wrote:
>>
>>> "As mentioned previously, the default behavior is to cast a shadow  
>>> from the entire element. This means pre-rendering the element,  
>>> including borders, background, border-images, text, and non- 
>>> positioned child elements, and using that to cast a single shadow."
>>>
>>> Why non-positioned only?
>>
>> It just seemed more useful to me that way, as positioned content  
>> would be more likely to be less closely associated in space with  
>> the element casting the shadow, and less likely that I would want  
>> to generate a single shadow from the item and it's positioned  
>> child. It would be easy to add a second shadow within the same rule  
>> that added position to the child.
>>
>>> It seems like a property like this should behave like opacity (and  
>>> just establish a stacking context with a z-index of 0), with all  
>>> the same rules for consistency.
>>
>> That would create individual shadows for each child, and I was  
>> trying to create a way to generate a single shadow for union of the  
>> element and it's children.
>
> I don't see why it would? 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.

> This will also be annoying to implement if the layers we have to  
> push involve a different clip bounding box computation than the ones  
> for opacity.

Wouldn't you have to cross that bridge anyway in order to have  
separate shadows for borders, backgrounds, etc. (a central feature of  
this proposal)? Or is that what you are referring to?

>

Received on Friday, 11 September 2009 19:17:06 UTC