Clarify backdrop/filter/paint behavior for Fullscreen API

[klausw]

In separate issue https://github.com/immersive-web/dom-overlays/issues/20, @chrishtr pointed out several issues related to the interaction of the fullscreen API and WebXR DOM Overlays, and suggested several changes to the Fullscreen API to better define the expected behavior:

@chrishtr wrote:

I researched the fullscreen and DOM overlay specs in some detail, together with @progers and @mfreed7. @cdata thanks also for the links and comments, they were very helpful.

I think there is a simple way forward, via a few small spec tweaks to the fullscreen and WebXR DOM overlay specs.

1. [Fullscreen spec] Specify that each element in a top layer:

• is a backdrop root
• has contain:paint

1. [Fullscreen spec] Clarify that there is a "root stacking context" above the "root element stacking context", whose children are the root element stacking context and the top layer elements' stacking contexts, in that order. The root stacking context has simplified behavior: it paints the root element stacking context, then the stacking contexts for the elements in the top layer.
2. [WebXR spec] Specify that in WebXR DOM overlay mode, the root element stacking context does not paint.
3. [Fullscreen spec] Specify that the viewport does not scroll overflow when elements are present in the top layer.

Item 1 solves the problem of backdrop-filter being ill-defined and the top layer element failing to be a containing block for position: fixed descendants otherwise, which is bad because it makes the position of those elements ill-defined.

Item 2 results in a spec that makes clear that no transforms, filters, etc. on any DOM elements not in the overlay subtree apply to it, including the HTML element.

Items 3 (pus item 2) solves the problem of ensuring that, in WebXR DOM overlay mode, content outside of the overlay does not paint anything. This is necessary because the backdrop of the overlay needs to be an XR scene, not the other DOM content. In fullscreen mode, OTOH, there is by default an opaque backdrop to the fulllscreen element, but if you manually override its transparency, you can see the rendering output of other elements.

Item 4 avoids scrollbars occurring on the page due to content behind the overlay having scrolling overflow.

[klausw]

In case it helps, I experimented with Fullscreen API here: https://fullscreenblend.glitch.me/

Specifically, this includes a style rule that sets the fullscreen backdrop transparent, overriding the UA's "backdrop: black":

:not(:root):fullscreen::backdrop {
    background-color: transparent;
}

This leads to odd effects in Chrome (I tested 80 and 82), where it appears that the backdrop filter in the fullscreen element unexpectedly applies to content that's supposed to be hidden by the backdrop. If I'm understanding it right, this means that the top layer isn't yet acting as a backdrop root?

[klausw]

Here are screenshots of the experiment on my Android phone, this also appears to act the same way in Chrome Linux and ChromeOS.

Before fullscreen:

After entering fullscreen, with transparent backdrop:

Fullscreen with black backdrop (disabling the custom backdrop color):

[klausw]

To clarify, the behavior appears to be as expected when using the default black backdrop. The unexpected results appear for a transparent backdrop, and I'm unsure if this is expected to work, but the browser doesn't currently stop me from doing this. The experiment just used normal CSS rules, I didn't modify the browser or UA stylesheets.

[annevk]

I think we've reached the point where Fullscreen has done sufficient amounts of monkey patching of CSS algorithms and the CSS WG ought to take over these concepts.

cc @whatwg/css