- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Fri, 11 Sep 2009 14:01:53 -0700
- To: David Hyatt <hyatt@apple.com>
- Cc: www-style list <www-style@w3.org>
On Sep 11, 2009, at 1:00 PM, David Hyatt <hyatt@apple.com> wrote: >> 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. Another related thing was that I wanted to be able to use drop-shadow, box-shadow, or text-shadow on a child element, with a non-default value, to be able to override the shadow that the parent was giving it. That's in there somewhere too (I don't have the document in front of me at the moment). Would that be equally problematic in your view, or would that be an acceptable way to cause it to break out of the inherited shadow? Perhaps any value other than 'inherit' on any of those three properties would cause this break out behavior. I'm not sure if I mentioned it, but I was assuming that this 'drop- shadow' property would override 'box-shadow' and 'text-shadow' set on the same element. So the override would happen in the opposite direction if the drop shadow was just being applied as a result of opacity-like inheritance. I'm not sure something so simple could work for opacity though, without breaking existing Web pages.
Received on Friday, 11 September 2009 21:02:42 UTC