Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify backdrop/filter/paint behavior for Fullscreen API #165

Open
klausw opened this issue Mar 18, 2020 · 4 comments
Open

Clarify backdrop/filter/paint behavior for Fullscreen API #165

klausw opened this issue Mar 18, 2020 · 4 comments

Comments

@klausw
Copy link

klausw commented Mar 18, 2020

In separate issue immersive-web/dom-overlays#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:
  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
Copy link
Author

klausw commented Mar 18, 2020

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
Copy link
Author

klausw commented Mar 18, 2020

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:
screen-fullscreenblend-1

After entering fullscreen, with transparent backdrop:
screen-fullscreenblend-2

Fullscreen with black backdrop (disabling the custom backdrop color):
screen-fullscreenblend-3

@klausw
Copy link
Author

klausw commented Mar 18, 2020

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
Copy link
Member

annevk commented Mar 20, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants