Text inside the block part of an IB split isn't affected by parent opacity. |
|||||
Issue description
Chrome Version : <Copy from: 'about:version'>
OS Version:
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari: FAIL
Firefox: OK
IE/Edge: OK
What steps will reproduce the problem?
1. Open the attached test-case.
What is the expected result?
"Block" text color is grey, since it has an ancestor with opacity on it.
What happens instead of that?
"Block" text color is black, not affected by the parent's opacity.
I _think_ Firefox and Edge are right here, and this is just a WebKit / Blink bug, but I don't know that much about how IB splits and stacking contexts interact, so ICBW.
Please provide any additional information below. Attach a screenshot if
possible.
,
Apr 24 2018
,
Apr 24 2018
,
Apr 24 2018
So Mats Palmgren pointed out that recently the spec had been clarified around this in https://github.com/w3c/csswg-drafts/issues/1477#issuecomment-380771705: > In a block-in-inline split, the block is inside the inline in the box tree, and is a sibling of the two fragments of the inline in the fragment tree So it doesn't matter whether the spec refers to box or element tree, opacity should apply to the block.
,
Apr 24 2018
I looked at this an am leaving it untriaged so layout and css can look. My understanding from the spec conversation is that the div is not inheriting the opacity because it is not a child of the span in the layout tree. Is that right? I would deeply appreciate it if someone could educate me on what code is responsible for associating opacity with the div in this situation. Or would it all magically work if we created the right layout tree?
,
Apr 27 2018
,
Apr 30 2018
This *should* work magically if we create the tree "correctly"...
,
May 1 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by emilio@chromium.org
, Apr 24 2018213 bytes
213 bytes View Download