DOM overlay not well-defined for non-roots

[chrishtr]

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.

[cdata]

@chrishtr the spec does have this note in https://fullscreen.spec.whatwg.org/#new-stacking-layer:

Each element and ::backdrop pseudo-element in a top layer has the following characteristics:

 • It generates a new stacking context.
 • Its parent stacking context is the root stacking context.
 • If it consists of multiple layout boxes, the first box is used.
 • It is rendered as an atomic unit as if it were a sibling of its root.

NOTE: Ancestor elements with overflow, opacity, masks, etc. cannot affect it.

 • If its position property computes to fixed, its containing block is the viewport, and the initial containing block otherwise.
 • If it is an element, it and its ::backdrop pseudo-element are not rendered if its shadow-including inclusive ancestor has the display property set to none.
 • If its specified display property is contents, it computes to block.
 • If its specified position property is not absolute or fixed, it computes to absolute.
 • Its outline, if any, is to be rendered before step 10 in the painting order.
 • Unless overridden by another specification, its static position for left, right, and top is zero.

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?

[RafaelCintron]

Would it help if the choices for a DOM overlay element was restricted to, say, an iFrame or simply "src="?

[cdata]

@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 <canvas> that is rendering something in (non-immersive) 3D. It is common enough to do this today, but for a particularly topical example please take a look at this demo, which uses ordinary DOM to display "annotations" on a 3D model rendered with <canvas>.

When I activate an immersive-ar session, I might want to "overlay" that exact same UI (including whatever micro-state it may have had just prior to the immersive-ar session, such as focus state) onto the immersive-ar rendered scene. I may not want to (or be able to) host an external document just to do this, but more importantly I would not be able to preserve the state (micro or otherwise) of the DOM as I transition into the immsersive-ar session.

[chrishtr]

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

2. [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.

3. [WebXR spec] Specify that in WebXR DOM overlay mode, the root element stacking context does not paint.

4. [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]

Thank you very much for the suggestion, I think this sounds very reasonable.

I've taken a stab at this in https://github.com/immersive-web/dom-overlays/pull/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?

[chrishtr]

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.

[klausw]

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

[chrishtr]

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?

[klausw]

Closing, I opened https://github.com/whatwg/fullscreen/issues/165 for Fullscreen API followup.