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

Thanks for the explainer updates!

We had a look at this in our virtual face-to-face, and we had some questions:

- 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?
- We were confused about `xrsession.domOverlayState.type`. 
   - There are three different values there - does the author choose which one applies? 
   - Can it change during the session? 
   - The example code says "Show which type of DOM Overlay got enabled (if any)" - when would none apply?
- 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?


-- 
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-767375543