Chrome doesn't apply the opacity to the div. We do. What's the spec say? Maybe dbaron knows.

If you read https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#anonymous-block-level literally, then it's probably not supposed to apply, but that spec was written "before" (in spec levels) 'opacity' existed. On the other hand, if you read https://drafts.csswg.org/css-color-3/#transparency literally, it probably is supposed to apply. Neither spec is particularly aware of the other, and something should probably be reconciled.

Edge matches Firefox.

We also support drawing all three lines as a single pass so that the proper group nature of opacity is respected. This adds quite a bit of implementation complexity, as we encounter all 3 frames that have opacity property, and then have to do a post-processing pass on the display list to merge the nsDisplayOpacity items together. We also have complexity within FrameLayerBuilder for handling merged items that source from multiple frames. If we do decide that the block in the middle doesn't need opacity, then it's no longer possible to guarantee group opacity for the other two (since they all overlap, and the block is in the middle of the z-order). It would be nice to be able to simplify our code, if we decide that the WebKit implementation is preferable. Note that this also applies to other post-processing effects, like filter, mask, and blend-mode.

(In reply to Matt Woodrow (:mattwoodrow) from comment #3) > It would be nice to be able to simplify our code, if we decide that the > WebKit implementation is preferable. Is some of that complexity also needed to support an inline broken over multiple lines? Because Chrome does agree with us on that case -- it's just the case where it's broken by a block that's different.

Ah yes, indeed it is. It looks like chrome isn't splitting the inline in their render tree, only the actual content gets split across lines, so they end up with a single node with opacity. We split the InlineFrame across the lines, and end up with two nsDisplayOpacitys that need to be merged.

This is a WebKit / Blink bug afaict.

Had a look into this more, since display item merging seems to continually cause us pain in FrameLayerBuilder. My reading of bug 660682 comment 10 is that we should always succeed in merging the split display items together, so it seems like we should be able to instead insert a single frame that wraps the split frames, and store the opacity style on that. The current frame tree for the testcase is this: https://pastebin.mozilla.org/9084655 If we had a new frame child of 'Block(body)(1)@104d92a30', that wrapped all 3 lines, and had the opacity style (and other style?) for the span element, then we'd only build a single nsDisplayOpacity (as a true stacking context) and wouldn't need to merge. Is this possible? Are there cases where we need to have the frames for the span element as siblings and not wrapped? My understanding is that this is what blink/Webkit are doing already (but they break in block-in-inline case). I'd be happy to try work on this, but I don't know much about frame construction and figuring out how to resolve the right styles to each frame.

Based on discussions in the CSS Working Group, I think handling of block-in-inline in other browsers may be a bit different from ours, in that they don't have a block-container representing the inline going around the block children, and thus act more like the block isn't contained within the inline. Figuring out more details probably requires a bit more testing, but it's possible we'd want to make substantial changes to our behavior for compatibility with other browsers. (On the other hand, (a) I think the current behavior is pretty reasonable and (b) we should probably get the column-span patches landed first, since they build on that behavior pretty heavily, and refactor it.)

(In reply to David Baron :dbaron: ⌚️UTC-7 from comment #9) > Based on discussions in the CSS Working Group, I think handling of > block-in-inline in other browsers may be a bit different from ours, in that > they don't have a block-container representing the inline going around the > block children, and thus act more like the block isn't contained within the > inline. Figuring out more details probably requires a bit more testing, but > it's possible we'd want to make substantial changes to our behavior for > compatibility with other browsers. (On the other hand, (a) I think the > current behavior is pretty reasonable and (b) we should probably get the > column-span patches landed first, since they build on that behavior pretty > heavily, and refactor it.) I was thinking (based on Emilio's comment) that Webkit/blink would be changing to match our behaviour, not us changing to match them. My idea is hopefully one that doesn't change our behaviour, just uses a different frame tree structure to implement it (one that is much easier for display lists to deal with).