Firefox and chrome differ on how stacking contexts are formed, with a relatively-positioned inline
Categories
(Core :: Layout: Positioned, defect, P3)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
Details
Attachments
(2 files, 1 obsolete file)
Testcase rendering on 2024-04-15
STR:
- Load attached testcase
I'm not sure what the expected behavior is, offhand, but Firefox and Chrome differ. Filing a bug to avoid losing track of this issue. (though we may eventually need to morph this into a Chromium bug if it turns out we're matching the spec.)
Chrome renders the content in this stacking order (back to front):
Lime
Orange
Red
Blue
...whereas Firefox renders the content in this stacking order (with Blue being near the background rather than in the foreground):
Lime
Blue
Orange
Red
This is the underlying compat difference at https://github.com/webcompat/web-bugs/issues/47818 . The relevant inline-level element there is <header> -- if I change that element to be display:block, then Chrome's rendering changes to match Firefox.
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 1•5 years ago
•
|
||
Edge 18 (EdgeHTML, pre-Chromium) has yet another stacking order -- matching Firefox, except with Orange moved to the back:
Orange
Lime
Blue
Red
Safari 13 (WebKit) matches Chrome, somewhat unsurprisingly (given the shared heritage).
|
|
Reporter | |
Comment 2•5 years ago
|
||
(reposting testcase to fix a non-functional typo -- a redundant <html> tag)
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 3•5 years ago
|
||
It looks like Firefox and Chrome disagree on a lot of stacking-context-related property behavior for block-in-inline splits, actually.
Here are a few other examples:
data:text/html,<span style="opacity:0.2">inline<div>block
data:text/html,<span style="filter:blur(2px)">inline<div>block
Firefox applies the effect to both "inline" and "block" text in these examples. Chrome only applies it to the "inline" text.
Based on the way block-in-inline splitting is described in https://drafts.csswg.org/css2/visuren.html#block-boxes , I think Chrome is right, though I'm not entirely sure. I'm curious this rings any bells for dbaron... (I feel like this must've come up before, possibly long ago.)
|
||
Comment 4•5 years ago
|
||
The opacity one at least was done intentionally in bug 660682.
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 :-).
|
||
Updated•3 years ago
|
|
||
Comment 6•3 years ago
|
||
The Chromium bug causing this issue was fixed a few months ago. See crbug.com/716930.
|
||
Updated•3 years ago
|
|
|
Reporter | |
Comment 7•3 years ago
|
||
(In reply to Chris Harrelson from comment #6)
The Chromium bug causing this issue was fixed a few months ago. See crbug.com/716930.
Thanks! That's great to see.
It looks like my Chrome installation (version 104.0.5110.0 (Official Build) dev (64-bit)) does matches the Firefox behavior that I described for my data-URI testcases in comment 3 (and Firefox continues to do so as well.
We also mostly agree on the attached testcase, though it looks like there's still some minor disagreement about the stacking order for the orange element.
Firefox still renders the content in the order I described in comment 0 -- Lime,Blue,Orange,Red.
Chrome nearly-agrees except they put Orange at the back, i.e. Orange,Lime,Blue,Red
|
|
Reporter | |
Comment 8•3 years ago
•
|
||
If I edit the attached testcase (or use devtools) to change .header to have display:inline-block instead of display:inline, Chrome maintains its same stacking order (no change), whereas Firefox changes to match Chrome (we move the orange stuff to be furthest-back in the stacking order).
So our remaining disagreement on that testcase seems to be due to some subtlety around handling of display:inline vs inline-block (as a relatively-positioned thing that forms a stacking context due to having nondefault 'z-index')...
|
|
||
Comment 9•3 years ago
|
||
Interesting. As far as I can tell, Chromium is right in this situation, because display:inline elements can cause a stacking context, and so we end up with the orange stacking context with three descendant stacking contexts with z-index 100) (green and then blue), plus one with z=index 10 (red).
So orange red green below appears to be the correct result, right?
I think the underlying Gecko bug here is that each line of the inline is being treated as a separate stacking context, rather than having all lines of the inline being treated as a single stacking context (which I think is what's supposed to happen). This is easier to see if you remove the class-less <div> from the testcase and make the <div class=absB></div> just be a child of <header>, because then the first line of text is part of the same inline line as the placeholders for the absolutely positioned elements.
|
||
Comment 11•3 years ago
|
||
Setting webcompat priority as P3 since we've only received one report affected by this.
|
||
Updated•2 years ago
|
|
||
Comment 12•10 months ago
|
||
The one real-world breakage we had for this no longer reproduces, unsetting the webcompat-priority flag. Also, I'll note that the linked crbug is now marked as fixed.
The testcase still shows a difference, though, as seen in the attached screenshot. I'll assume that this issue is still valid, and leave it open for any future breakage we find (if any). :)
|
|
Reporter | |
Comment 13•10 months ago
|
||
(In reply to Dennis Schubert [:denschub] from comment #12)
The one real-world breakage we had for this no longer reproduces, unsetting the webcompat-priority flag
(This unsetting got lost as part of posting the screenshot, I think, since the add-attachment UI doesn't let you change flags. --> Unsetting the flag now.)
Description
•