css - Why can't child elements override the opacity of parent with a greater value?

Question

As we know, child elements cannot as of now override the opacity property of its parent. The opacity property of the parent always takes effect.

This makes sense when the child is trying to underride (override with smaller value) the opacity of the parent. But what about if the child is trying to override it with a greater value? Shouldn't that be allowed? Why can't a translucent parent have an opaque child? Can anyone share thoughts on why such a restriction was decided as part of the CSS design?

Would really appreciate if someone can shed some light on the theoretical reason for this. I'm essentially trying to find out the why-can't part of this (not workarounds; as those've been talked about a lot of times already). I'm sure this is something a lot of newbie SO'ers like me would wanna know.

question from:https://stackoverflow.com/questions/12613191/why-cant-child-elements-override-the-opacity-of-parent-with-a-greater-value

Answer 1

I've never seen that as "overriding" or "underriding". It's a matter of relative opacities. If the parent has an opacity of 0.5, the child has it too (in relation to the parent's stacking context). The child can have its own opacity value between 0 and 1, but it will always be relative to the parent's opacity. So if the child also has opacity: 0.5 set, it will be 0.25 the opacity of some of the parent's sibling with opacity 1.

The spec treats it as an alpha mask, where opacity can only be removed. An element is either opaque, or has some degree of transparency (anything < 1):

Opacity can be thought of as a postprocessing operation. Conceptually, after the element (including its descendants) is rendered into an RGBA offscreen image, the opacity setting specifies how to blend the offscreen rendering into the current composite rendering.

and later on:

If the object is a container element, then the effect is as if the contents of the container element were blended against the current background using a mask where the value of each pixel of the mask is <alphavalue>

As for why it was implemented that way, I don't think it was intentional in the sense of "let's forbid that". Maybe this approach was chosen for being simpler to calculate, and only later an actual need for something different was recognized (then rgba color and background-color were introduced – and I may be wrong about the timeline here).