Re: Drop-Shadow proposal

On Sep 11, 2009, at 2:16 PM, Brad Kemper wrote:

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

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.

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

Not really.  The clip bounding box doesn't have to be precise.

dave
(hyatt@apple.com)

Received on Friday, 11 September 2009 20:01:18 UTC