Open Bug 1616361 Opened 1 month ago Updated 26 days ago

Firefox and chrome differ on how stacking contexts are formed, with a relatively-positioned inline

Categories

(Core :: Layout: Positioned, defect, P3)

defect

Tracking

()

People

(Reporter: dholbert, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

Attached file testcase 1 (obsolete) —

STR:

  1. 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.

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).

Attached file testcase 1

(reposting testcase to fix a non-functional typo -- a redundant <html> tag)

Attachment #9127368 - Attachment is obsolete: true
Attachment #9127379 - Attachment mime type: text/plain → text/html

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.)

The opacity one at least was done intentionally in bug 660682.

Flags: needinfo?(dbaron)

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 :-).

You need to log in before you can comment on or make changes to this bug.