Tess: Are we going to define hit testing in XR before in the rest of the platform?

Tess: I wonder if we should be figuring out how to expose hit testing more generally and then figure out how to apply it in XR

Assigning Tess and David

Tess: I linked to the mozilla standards position issue which raised some good concerns... security & privacy in particualry. Has not been prototyped... Basic worry I had a month ago - I am concerned we define hit testing for webxr before we define it for the rest of the platform. Adding additional concepts on top of the current model. I don't want to say " you can't work on this until we do xyz". but what are the common concepts? If there were to be general work, how could this work inform it so it could be architecturally aligned in the future?

Dan: security & privacy issues need to be addressed.

We discussed Mounir's feedback..

Alice: yes, agreed that this type of hit testing is different from document hit testing.

Dan: yes -

Dan: and agreed on Mozilla's feedback as well as the feedback on use of this API in the VR enviroment.

Tess: mounir replied that the underlying webxr platform also does what I asked about (matrices). Why not use DOM Matrix? Might have to send that back to WebXR group.

Rossen: this might be inertia about what they're used to. It's a good point though.

Tess: I will file an issue on the main WebXR issues tracker about it.

Rossen: would this hit testing allow pixel readbacks

Tess: I think it's real-world only; they said virtual was "just a matter of maths (sic)"

Rossen: combining virtual and realworld testing.

Rossen: pixel reduxing would have a dependency on the graphics subsystem which would be pretty bad... as soon as you go to readback the values you have to sync the pipeline. I will go through the proposal.

Dan: Let's try to revisit in the plenary. I will bump one mor week.

Rossen: needs use cases and test cases.

Tess: when we last left it - after we marked it as proposed closed - we noted the non-use of dom matrix. This was due to consistency with WebXR. So I filed that issue - I don't think that should hold this up however.

[discussion on closing]

Dan: +1

Tess: yes I think we can

Tess: lack of use cases & examples... was Rossen's comment.

Rossen: yes.

Tess: I think it would improve the document.

Rossen: we can leave the feedback. I will write the closing comment.

Yves: I will TAG track the issue in WebXR.

Rossen: noting previous comment from David... Mounir answered this doesn't answer the question. Eric suggests a rename to clarify it's real world only. But Mounir replies it's up to the implementer.... So let's push it for another week and I will prompt to answer the question and clairify Eric's point.

[so bumped]

Rossen: They have not taken our feedback into consideration... a bit disappointed.

Dan: I'll ping the group chair about it... ?

Rossen: they have no examples of how it should be used... the current incarnation of their spec has no intention to be read by developers.

Dan: proposes closing comment:

We're going to close this off. The TAG is satisfied with the design and that feedback has been taken to account, however there is still a lack of uses cases and examples as @atanassov has pointed out in the last comment. We would therefore strongly encourage that these be added to the spec in subsequent revisions. We

[we acutally decide not to leave this comment yet]

Dan: will reach out to group chair

[bumped]

Closed with feedback for more examples in spec

Dan: kind of stalled still - we have left feedback and the group chairs have been contacted but no resposne yet