Peter: Concerned about conflating XR events and DOM events...

...

David: Extra events seem ok, as long as normal events also happen

Peter: I'm reading it as the select events being overloaded to mean different things... I could be wrong.

Rossen: Is this running under the assumption that there can only be a single such layer?

Tess: the API assumes that...

Rossen: that seems unnecessarily restrictive...

Peter: Can see you might want to have multiple overlays in different places

Rossen: One of the early discussions I had with hololens... we were working on the browser and how we could decompose the browser and use HTML in scenes, especially int he immersive world... is geared and focused toward having multiple interactive HTML panels.

... imagine you want to put a <streaming TV service> player on your wall. That's what holo experience allows you to do... you pin these experiences and it serialises all the geo-locked data for you so can recosntruct your experience

... want to be able to incoropoate your daily activities in the scene... restricting the experience to saying you can only hve one HTML-based panel that is going to be always in front of you sounds like you are solving a specific use case... having a hard time imagining why this should be restricted to only one...

... we don't have these types of restrictions elsewhere int he platform

Tess: Well, fullscreen is a counter-example...

Rossen: Watch this space...

... Just not sure this restriction is warranted

Peter: How will this interact with future APIs that let you push DOM content into the scene? Is this just a special case of that? Should they be different APIs at that point?

Peter: They asked for issues in their repo for each point of feedback, so we can each open an issue and link it back to the TAG review

Alice: Suggest we push this for another week until both myself and Tess catch up on this one

Alice: some additions to the explainer

(reading of explainer)

Alice: side note: should we add the Declarative Shadow DOM explainer to the list of good explainers?

Tess: some thoughts:

• many readers of explainers aren't AR experts
• we're also not the explainer police. Does us saying we won't review until we can parse/understand the explainer cause improvements or do they just move on? That is, what do we accomplish by saying it's hard to review given state of explainer.

Alice: but how much TAG time should we dedicate to something that they should have been making easier to read?

Tess: TAG became relevant by providing reviews that people find useful. How do we send people away with the feeling that it was worth coming to us? (And is the effort differential of that worth it?)

Tess notes that the "design sketch" link in the explainer errors out.

Alice: Why have root? In what context would you use the other elements on the page?

Tess: Are the other elements for when you're not in the immersive experience?

Tess: The element is forced to fullscreen.

David: I think maybe what it's saying about fullscreen is that the fullscreen mode in the HTML spec applies, but it's not necessarily taking up the full screen?

( disagreement within the TAG about which parts of the two screenshots are supposed to be the overlay! Disagree about the green rectangle or purple swirl, or the "Enter VR" and "Exit AR" buttons.)

Alice and Tess to add specific questions and David to comment about the explaine

looking at the updated explainer

Also taking a look at Ada Cannon's example app which demonstrates the use of DOM Overlay.

Alice: on input event duplication the "bubbling" seems backwards...

Alice: on Compositing - couldn't they specify the alpha blend blend mode for DOM content [automatically]?

Dan: [the way they have it] seems unfriendly.

[Discussion on what is the default dom overlay type?]

Dan: Code has comment // Show which type of DOM Overlay got enabled (if any) so what does that mean? Can you have a dom overlay without a type?

Alice: writes up comment

...discussion on whether users might consider overlay content as trusted UI and therefore is there a need for additional mitigation against 3rd party content... we decided not to leave an additional comment...

Tess took a look a the explainer updates, wants to re-review, moved to next week

Thanks for bearing with us. We're happy to close this as satisfied. We appreciate the changes you made based on our feedback. Thank for sailing with TAG.

[posted and closed

Dan: came back to us with a bunch of stuff they have done, responses to Alice's comments. A number of closed PRs referenced.

Tess: would like to look at the PRs to see if they adequately address things we brought up before

Dan: [proposed close] something something the abyss looking into yo

[bumped]