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