Bugzilla

We intentionally made Gecko work this way. The specs for `opacity` and `filter` say that effects are applied to elements and their descendants, and do not say anything about depending on the box structure. E.g. https://www.w3.org/TR/2018/REC-css-color-3-20180619/#transparency
> 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.
It also seems unintuitive to have the effect apply to some descendants and not others just because of block-in-inline splits.

For z-index https://www.w3.org/TR/css-position-3/#painting-order is also worded in terms of elements and their descendants:
> The painting order for the descendants of an element generating a stacking context (see the z-index property) is:
There's nothing there about block-level descendants escaping from the stacking context of inline ancestors, and again, it seems weird to have some descendants escape.

The specs have always been less clear than they should be due to mixing up "box" and "element" in various places, and I see this is still a problem. Nevertheless I think they're clear enough here and the spec behavior makes more sense than the Chrome behavior. File a Chrome bug and I'll argue for it :-).

We intentionally made Gecko work this way. The specs for `opacity` and `filter` say that effects are applied to elements and their descendants, and do not say anything about depending on the box structure. E.g. https://www.w3.org/TR/2018/REC-css-color-3-20180619/#transparency
> 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.

It also seems unintuitive to have the effect apply to some descendants and not others just because of block-in-inline splits.

For z-index https://www.w3.org/TR/css-position-3/#painting-order is also worded in terms of elements and their descendants:
> The painting order for the descendants of an element generating a stacking context (see the z-index property) is:

There's nothing there about block-level descendants escaping from the stacking context of inline ancestors, and again, it seems weird to have some descendants escape.

The specs have always been less clear than they should be due to mixing up "box" and "element" in various places, and I see this is still a problem. Nevertheless I think they're clear enough here and the spec behavior makes more sense than the Chrome behavior. File a Chrome bug and I'll argue for it :-).