- From: David Hyatt <hyatt@apple.com>
- Date: Fri, 11 Sep 2009 13:49:03 -0500
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: www-style list <www-style@w3.org>
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 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. dave
Received on Friday, 11 September 2009 18:49:46 UTC