z-index on `position:relative;display:inline` element also affects its {ib}-split block children.
Categories
(Core :: Layout: Block and Inline, defect, P3)
Tracking
()
| Webcompat Priority | P2 |
People
(Reporter: dholbert, Unassigned)
References
Details
Attachments
(3 files)
FF vs Chrome.png
In Firefox and Edge, it seems that z-index-affected display:inline;position:relative elements will apply their z-index to their block-level children as well, whereas in Chrome and WebKit, they don't.
I'm not sure who's right. IB splits are weird. (If we're right, we should try to get bugs filed, because we'll be the odd one out once EdgeHTML is superseded by Edgium.)
This is the root of https://github.com/webcompat/web-bugs/issues/36951
STR:
- load attached testcase.
Blink/WebKit results:
An orange area is visible, with Can you see this text?
Gecko/EdgeHTML results:
No orange area is visible. No text is visible.
|
Reporter | |
Comment 1•6 years ago
•
|
||
Here's a similar testcase where I'm using filter instead of z-index on the inline-level element that has a block-level child.
In Firefox and EdgeHTML, the block-level child gets filtered as well. In Chrome and Safari, it does not (so the "Can you see this text" orange area is visible/crisp there).
|
|
Reporter | |
Comment 2•6 years ago
|
||
dbaron, is this a behavior-difference that you're familiar with, and do you happen to remember who's correct? (or whether this is specced at all?)
I think based on the wording in the spec:
When an inline box contains an in-flow block-level box, the inline box (and its inline ancestors within the same line box) are broken around the block-level box (and any block-level siblings that are consecutive or separated only by collapsible whitespace and/or out-of-flow elements), splitting the inline box into two boxes (even if either side is empty), one on each side of the block-level box(es). The line boxes before the break and after the break are enclosed in anonymous block boxes, and the block-level box becomes a sibling of those anonymous boxes. When such an inline box is affected by relative positioning, any resulting translation also affects the block-level box contained in the inline box.
the only thing from the inline that should apply to the block is relative positioning. (I argued against that, but lost.)
So we should probably remove this line and maybe some other lines in the same rule.
|
||
Comment 5•6 years ago
|
||
The spec wording in comment 3 is quoted from https://www.w3.org/TR/CSS22/visuren.html#anonymous-block-level
|
||
Comment 6•6 years ago
|
||
I feel pretty strongly that our rendering is the correct one and that this is a bug in Chrome.
It's insane that a property only affects only some of the element's boxes, but not all.
Basically the rest of the working group thinks that the block wrapper isn't really there, and the inline just has two inline boxes that are broken in half, with the block child not really being a child of the inline. And then there's an exception to make relative positioning work.
I argued that it should be like there's a block wrapper box, but I lost that argument. And it does match what the spec says.
|
|
||
Comment 8•6 years ago
•
|
||
Fair enough, but not having a block wrapper means that the box tree becomes more complex since DOM tree children can create box tree siblings. Then again, we already sort of have that with display:contents anyway so perhaps not a big deal...
Oh well, I'm not a fan of our IBSplitSibling setup anyway - maybe we can get rid of that now?
|
||
Comment 9•6 years ago
|
||
We still need the anon block to do relative positioning, unless we want to somehow apply it to all the individual child blocks, right?
As far as the specific z-index rule goes, I looked at the history and it was first added in https://github.com/mozilla/gecko-dev/commit/3b93ffe84819ca54b2e2be7ae9af780ed6f46bdf but none of the discussion in bug 6625 mentions why it would have been added other than "yeah, this seems right to get rid of that XXXwaterson comment". So if it's not matching the spec and other UAs, and we have already tried to litigate this and lost, then we should just remove it and not waste time on it....
|
||
Comment 10•6 years ago
|
||
FWIW, we have similar rules for opacity and such that WebKit/Chromium doesn't have and which they consider a bug on their impl.
|
|
||
Comment 11•6 years ago
|
||
So that is an interesting question. Per spec, z-index applies to a positioned box, so it's the box tree that matters. In particular, if you have a rel pos inline with a float child, that child would not be affected by z-index on the rel pos inline, right? At least per spec... in impls it sure seems to be. :(
On the other hand, opacity is clearly defined to act on elements, not on boxes.
|
|
||
Comment 12•6 years ago
|
||
(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #9)
We still need the anon block to do relative positioning, unless we want to somehow apply it to all the individual child blocks, right?
Right, but we need to implement something like that to support CSS Alignment for blocks anyway (bug 1105571).
Fwiw, I recently tried removing the table-cell anon child just to see what it's actually needed for and the only thing that remained in the end was the alignment of the cell contents. So, if we implement bug 1105571 (without introducing an anon box obviously) then I think we can get rid of the table-cell anon box.
It seems like it should be possible to implement relative positioning without using a wrapper (again, it might be possible to re-use some code from bug 1105571 for this). I don't know about the other properties though, opacity/z-index etc seems hard to do without a wrapper.
|
|
||
Comment 13•6 years ago
|
||
(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #11)
On the other hand, opacity is clearly defined to act on elements, not on boxes.
A word of caution: the terms "element" and "box" are often interchanged rather liberally in CSS specs (especially in older specs, but also in recent ones). I would not assume that those terms are used correctly.
If we're going to make implementation decisions based on those wordings then I would recommend asking the CSSWG for the intended meaning.
|
|
||
Comment 14•6 years ago
|
||
<sigh>. If people can't even use the terms their own specs introduce right...
Yes, we should be filing bugs on specs that do that.
|
|
Reporter | |
Comment 15•5 years ago
|
||
Removing "negative" from bug summary, because this is just as much of a compat-issue for positive z-index. (the sign doesn't matter)
(https://github.com/webcompat/web-bugs/issues/48945 is a case where we're bitten by a z-index:2 on an inline-level wrapper that we honor on its block-level child but Chrome does not.)
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Updated•3 years ago
|
|
||
Comment 16•1 year ago
|
||
Based on the test cases there isn't really much of a difference on Firefox vs Chrome now. Should we mark this as fixed?
Environment:
Operating system: Windows 10
Browsers tested: Firefox Nightly 128.0a1 (2024-05-29) / Firefox Release 126 / Chrome 125.0.6422.113
|
|
Reporter | |
Comment 17•1 year ago
|
||
Thanks, you're right! It looks like Chrome aligned with the Firefox (and pre-Chromium Edge) behavior here.
Bisecting with testcase 1, it looks like Chrome 100 has their old behavior, whereas Chrome 101 and newer match us.
WebKit still disagrees, but it's probably reasonable to consider that a WebKit bug at this point (which Chromium/Blink inherited and then fixed).
So I think we can consider this INVALID as a Firefox bug.
|
|
Reporter | |
Updated•1 year ago
|
|
|
Reporter | |
Comment 18•1 year ago
|
||
I filed https://bugs.webkit.org/show_bug.cgi?id=274903 on the WebKit behavior here.
|
|
Reporter | |
Comment 19•1 year ago
•
|
||
Also, I spun off bug 1899829 for webcompat issue https://webcompat.com/issues/60176 which was linked here but seems to still show a reproducible difference between Firefox vs Chrome/Safari.
Description
•