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.