Re: [w3ctag/design-reviews] WebXR DOM Overlay Module (#470)

> Thanks for the explainer updates!

Thank you for the feedback!

> * Could you explain the reasoning behind the decision to require developers to listen for the `beforexrselect` event to avoid events targeted at DOM content triggering XR events in the content behind the overlay? Would it be possible to avoid needing this event by having events bubble from the DOM to the XR scene, so that if, say, a `click` event is handled and propagation stopped in the DOM, no `select` event gets fired in the XR scene?

This would introduce a significant delay - the goal is to deliver the `selectstart` event as soon as possible to minimize latency, i.e. when the screen is first touched for phone AR. The DOM `click` event is only generated when the finger is lifted. If the delivery of XR events depended on propagation being stopped on the `click` event, it would need to delay delivery of the XR `selectstart` event until that point. The alternative of tying XR event delivery to pointerdown/mousedown/touchstart would potentially get complicated and a bit messy, especially if existing DOM UI elements have their own handlers and expectations for such events.

The `beforexrselect` approach is intended to be a fairly lightweight handler that is run at the start of the selectstart/selectend/select sequence, and either allows all of them to proceed or suppresses all of them. This helps ensure that the XR events happen in the expected sequence independently of DOM event handling. Since it's independent of other DOM input events, it doesn't interfere with them.

Also, XR frame and input timing isn't currently required to be tightly synchronized with DOM frame and input handling. It's entirely possible for the XR scene to be running at a different framerate than DOM animations. In general, the goal for an AR system is to process XR frames and input with minimal latency, while DOM is often tuned for smooth animations even at the cost of slightly increased latency. Requiring a tight coupling between DOM and XR input events could be a significant challenge for implementations and could cause performance degradations.

> * We were confused about `xrsession.domOverlayState.type`.
>   
>   * There are three different values there - does the author choose which one applies?

No, this is chosen by the user agent, this field just informs the page about which is currently active. I'm adding a clarification.

>   * Can it change during the session?

No, it's intended to stay the same for the duration of the session. This isn't currently explicit in the spec, I'll add an update there.

>   * The example code says "Show which type of DOM Overlay got enabled (if any)" - when would none apply?

Sorry, this was a mistake in the example. It is supposed to check for `xrsession.domOverlayState` being present before referencing the `type` field. If the `domOverlayState` attribute exists, it must have a non-null `type`. I'm updating the example snippet to match the full code example where I had fixed this already.

> * The section on [Compositing](https://github.com/immersive-web/dom-overlays/blob/master/explainer.md#compositing) mentions:
>   > A see-through AR headset typically uses the `"additive"` blend mode where black pixels appear transparent and dark colors on a transparent background are likely to be hard to see. Opaque black is only visible if the session uses `"alpha-blend"` blend mode.
>   
>   * This seems like a potential "gotcha" - is there some technical limitation meaning that authors are required to know that black (typically the default colour for text in web content) is likely to be rendered as transparent?

Yes, this is a technical limitation of additive see-through headsets such as HoloLens. The waveguide optics can only add light to the scene, they don't have any way to darken the perceived image, and therefore cannot display an opaque black. The result is basically equivalent to a `lighten` [blend mode](https://developer.mozilla.org/en-US/docs/Web/CSS/blend-mode) due to the way the hardware works.

There's a corresponding `@media(environment-blending: additive)` mode in [mediaqueries-5](https://www.w3.org/TR/mediaqueries-5/#environment-blending), though I'm unsure how widely this is currently implemented. I'll add a note to the explainer to point to this.

See https://github.com/immersive-web/dom-overlays/pull/40 for the planned changes.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/470#issuecomment-768551042