41

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.

j08691
  • 204,283
  • 31
  • 260
  • 272
techfoobar
  • 65,616
  • 14
  • 114
  • 135
  • 17
    There's a way to achieve this: using a translucent background in the parent (ex. `background-color:rgba(0, 0, 0, 0.5);`, where the background of the parent is a `rgba` color, which has an alpha channel. – JCOC611 Sep 27 '12 at 02:25
  • 2
    Yeah, i know. What about if i'm using a background-image in the parent and child elements? More over, I've not looking for workarounds actually. I'm looking to understand why such a design decision was made in CSS. – techfoobar Sep 27 '12 at 02:26

1 Answers1

48

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

bfavaretto
  • 71,580
  • 16
  • 111
  • 150
  • Yes, that part is clear. Opacity of 0.5 over an opacity of 0.5 is like 0.25. But, the thing I'm still puzzled about is why can't translucent parents have fully opaque children? Why not by design? – techfoobar Sep 27 '12 at 02:34
  • 1
    Because the children are *part of the parent*, their opacity is intrinsic. – bfavaretto Sep 27 '12 at 02:35
  • 1
    That would mean that we can have an opaque child over a 0.5 opaque parent, if we specify the opacity of the child as 2.0 - But that doesn't happen does it? There's got to be more reason for not allowing this i believe. – techfoobar Sep 27 '12 at 02:38
  • Updated my answer with a possible reason. – bfavaretto Sep 27 '12 at 03:00
  • +1 Thank you for the explanation. Simpler to calculate and easier on the rendering logic are the only things that could have been the reason like you said. – techfoobar Sep 27 '12 at 05:58
  • 7
    Its possible to handle this effect using rgba color mode. For example this works: .parent{background: rgba(background: 255, 255, 255, 0.7);} .parent .child{background: rgba(255, 255, 255,1);} – aUXcoder Sep 20 '15 at 16:24