Spell out how optional Fullscreen API integration works

[foolip]

https://immersive-web.github.io/dom-overlays/#fullscreen-api-integration says this:

The UA MAY implement DOM Overlay as a special case of the [FULLSCREEN] API. In this case, the UA MUST prevent changes to the active fullscreen element, rejecting requestFullscreen requests for the duration of the immersive session.

From the discussion in #14 (comment) it sounds like the "MAY" here is to allow for the integration to work differently depending on what the hardware is. However, my reading of it was that integrating with the Fullscreen API at all is optional.

If the flexibility here is around the hardware and not differences between implementations, then it would be clearer if the integration is spelled out detail in terms of what steps in which algorithms do what. Then, make certain steps conditional on a concept that explicitly depends on what hardware is available, with a non-normative note saying what kinds of scenarios it could make sense to return true or false from this check.

https://fullscreen.spec.whatwg.org/#fullscreen-is-supported is a limited example of this, saying "Fullscreen is supported if there is no previously-established user preference, security risk, or platform limitation."

https://html.spec.whatwg.org/multipage/media.html#concept-media-load-resource is another example, where one step says "Optionally, run the following substeps."

[klausw]

Created #17 - does that help clarify the intent? It adds these paragraphs:

Alternatively, the UA MAY implement DOM Overlay independently of the [[FULLSCREEN]] API. In this case, the DOM overlay root element MUST still match the [=:xr-overlay=] pseudoclass and MUST be styled using the [[#ua-style-sheet-defaults]] for this pseudoclass. The UA MAY separately support using the fullscreen API for elements outside the DOM overlay root element, but this MUST NOT have any effect on how the DOM overlay content is displayed.

NOTE: Handling DOM Overlay and Fullscreen API independently is intended to support a multi-display system such as a desktop PC with an attached VR headset. In this case, the Fullscreen API could be used to show page content on the 2D monitor, for example a canvas element with a third-person rendered view, while the DOM Overlay element and immersive content is separately displayed in the headset.

[RafaelCintron]

If the UA decides to implement this feature using fullscreen, this aspect needs to strictly stay as an implementation detail and NOT bleed into aspects of how to use the WebXR API.

This bleed over risks compatibility bugs across implementations and, in my opinion, imposes an undue burden on web developers who need to add just-in-case CSS attributes to account for diversity of implementation details.

[RafaelCintron]

I'm specifically referring to the following section of the spec:

The UA MAY implement DOM Overlay as a special case of the [FULLSCREEN] API. In this case, the UA MUST prevent changes to the active fullscreen element, rejecting requestFullscreen requests for the duration of the immersive session.

The following CSS properties in the "User-agent level style sheet defaults" seem problematic:

/* If there’s a backdrop from fullscreen mode, set that transparent. */
:xr-overlay:fullscreen::backdrop {
  background: rgba(0,0,0,0) !important;

[klausw]

@RafaelCintron, we can remove the :xr-overlay:fullscreen::backdrop rule from the spec, I agree that issues such as ensuring that the DOM overlay isn't obstructed by a fullscreen backdrop should be implementation details and not visible to applications.

A goal of the "Fullscreen API integration" section in the spec was specifically to avoid compatibility bugs, for example that applications must not be able to use Fullscreen API to change the visible DOM overlay element. I don't think it would work to strictly treat this as an implementation detail since there's some functionality overlap between these two APIs even if the implementation doesn't directly use Fullscreen API.

[klausw]

I updated PR #17 to remove the backdrop CSS rule, and I also updated the Chrome implementation to no longer use that.

It also contains clarifications for the non-fullscreen-API-based and multi-display scenarios.

@RafaelCintron , does that address your concerns?

[RafaelCintron]

I left a PR comment on #17