Martin: it's pretty big... It's hard to put your web frame of reference into the XR space... No safe space, no chrome...

let's bring to plenary and if not by next week

Matthew: Coming back to this, I completed my review, and took some input from a colleague; here is a proposed closing (satisfied) comment:

Thanks for your review request—and for highlighting the changes since last time. Here are a few comments on these changes.

HT @m-alkalbani for assisting with the review.

1. Expose XRSession’s granted features (GitHub #1296)

   Looks good!

2. Add support for the isSystemKeyboardSupported attribute (GitHub #1314)

   This Boolean's name starts with 'is' whereas others' names don't seem to. Is there a reason for this, such as consistency with other specs? It seems inconsistent with other parts of WebXR Device API.

3. Clarify getPose behavior with visibile-blurred (GitHub #1332)

   Looks good!

4. Transient intent addition (GitHub #1343)

   This looks good — but gave rise to a question about an instance of one of the terms used in the definition of targetRayMode enum values...

   Assuming that the gaze enum variant is talking about getting input from the direction someone's head is facing...

   The definition for the transient-pointer enum variant states: "Some examples are user intents based on information too sensitive to expose directly such as gaze..." — however in this phrase, is "gaze" actually referring to input that comes from eye gaze (i.e. eye tracking)? If so, the word "gaze" is referring to two differnet things; would you be able to re-phrase this to make that clear?

5. First draft for adding a property to XRInputSource to say it’s visible elsewhere (GitHub #1353)

   This looks good — but the PR referenced here should be 1352, so the Changes section should be updated.

6. Clarify rgb vs srgb behavior (GitHub #1359)

   We want to keep reminding people to try to align colors between CSS, canvas, and the other drawing surfaces in the platform. That said, that's a long-term project, and we don't expect this incremental change to solve it. Otherwise looks good!

Also...

7. The definition for transient-pointer has a typo; it mentions "W3C design principals" — I think you mean to reference Web Design Principle 2.9: Don’t reveal that assistive technologies are being used; if so, perhaps you could include this link.

   That you made the reference, and read the principles, is appreciated!

Matthew: most of the way through this, PRs are well explained, most not architectural. One is to do harmonization with other specs and I believe them, so that sounds good - feature detection related - found a different way to do parameters so feature detection is the same across specs. I'd sense check that with others. A few small clarifications. A couple of bigger ones which I don't see any concerns with but need more time to look into. One was originally about conveying user intents derived from the OS or the UA in the XR space and it would take into account what the user is looking at at the time, and quite a bit of discussion about how that should work and what it should be called. And one about on screen keyboards that's important and interesting. I might be able to leave some notes this week.