-
Notifications
You must be signed in to change notification settings - Fork 9
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
DOM overlay not well-defined for non-roots #20
Comments
@chrishtr the spec does have this note in https://fullscreen.spec.whatwg.org/#new-stacking-layer:
As you say, there does not seem to be any mention of transform, scrolling, filter (I'm sure there are others to consider). It seems to be somewhat hand-wave-y with regards to "overflow, opacity, masks, etc. cannot affect it" - this seems like it deserves a more comprehensive explanation. That said: my interpretation of the spirit of the text is that details inherited from tree ancestors that would affect the element layout and paint are no longer in play, and that layout is adjusted so that by default the element fills the whole viewport. Does that sound right to you? |
Would it help if the choices for a DOM overlay element was restricted to, say, an iFrame or simply "src="? |
@RafaelCintron I would like to offer that requiring the overlay to be an external document would prevent it from being used for some common conditions where it might otherwise be desired. For example, let's say I have some UI layered on top of a When I activate an |
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.
Item 1 solves the problem of backdrop-filter being ill-defined and the top layer element failing to be a containing block for 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. |
Thank you very much for the suggestion, I think this sounds very reasonable. I've taken a stab at this in #22 . It's a bit hard to do so without corresponding updates in Fullscreen API, so I tried to keep it self-contained, but it could be streamlined once Fullscreen API covers the overlapping parts (no pun intended). What do you think? As a side note, I think having both "root stacking context" and "root element stacking context" as distinct concepts in a spec is potentially confusing, I just got this mixed up myself. I'm having a hard time thinking of better alternatives though. Maybe "fundamental stacking context" just to make it more distinct? |
The reason I suggested the "root" and "root element" naming is because that's how the compositing spec states it. But I do agree there is some potential for confusion. |
@chrishtr , does the current state (including the changes in PR #22 which you had approved) cover the needed changes from the WebXR DOM Overlay side? We'd need to follow up with changes to the Fullscreen API separately, but as far as I can tell that shouldn't affect this spec assuming that they are incorporated as suggested. |
As suggested in immersive-web/dom-overlays#20 (comment) This ensures that top layer elements act as a containing block for "position: fixed" descendants. Bug: 1060731 Change-Id: Id5bedac6ecde75a11d83442c025c0bd1da4e1cc2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098178 Reviewed-by: Chris Harrelson <[email protected]> Commit-Queue: Klaus Weidner <[email protected]> Cr-Commit-Position: refs/heads/master@{#749458}
Yes I agree. If you wish to close this issue you can, but if so could you open a new issue against the fullscreen spec and mention me in it? |
Closing, I opened whatwg/fullscreen#165 for Fullscreen API followup. |
The current API allows any element to become the "Root" of a WebXR DOM overlay.
As specified, this is not well-defined. For example, what happens if there is a filter, scrolling, or transform on an ancestor element of that root? Are these properties somehow just ignored?
The fullscreen API also has these issues, but is already out in the wild and we have a limited ability to do anything about it. We shouldn't make that mistake again.
The text was updated successfully, but these errors were encountered: