WebXR Device API (delta/aiming 2nd CRS)

[himorin]

こんにちは TAG-さん!

I'm requesting a TAG review of WebXR Device API.

This specification describes support for accessing virtual reality (VR) and augmented reality (AR) devices, including sensors and head-mounted displays, on the Web.

• Explainer¹ (minimally containing user needs and example code): Overall WebXR explainer
• Specification URL: url
• Tests: wpt webxr
• User research: n/a
• Security and Privacy self-review²: security and privacy questionnaire on WebXR Device API immersive-web/webxr#1379
• GitHub repo: https://github.com/immersive-web/webxr/
• Primary contacts (and their relationship to the specification):
  • Brandon Jones (@toji), Google, Editor
  • Manish Goregaokar, (@Manishearth), Google, Editor
  • Rik Cabanier (@cabanier), Meta, Editor
  • Ada Rose Cannon (@AdaRoseCannon), Apple, Chair
  • Chris Wilson (@cwilso), Google, Chair
  • Ayşegül Yönet (@Yonet), IE, Chair
• Organization(s)/project(s) driving the specification: Immersive Web WG
• Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification
• Key pieces of multi-implementer support:
  • previous whole review for 1st CRS WebXR Device API #545
  • CRdelta review WebXR Device API XRSession::enabledFeatures attribute (CR Delta) #782
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • https://chromestatus.com/feature/5680169905815552
  • https://developer.mozilla.org/en-US/docs/Web/API/WebXR_Device_API#browser_compatibility

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: Expecting to update existing CRS, no specific target date
• The group where the work on this specification is currently being done: Immersive Web WG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): n/a
• Major unresolved issues with or opposition to this specification: no
• This work is being funded by:

You should also know that...

changes from 1st CRS is listed in specification, and we've got TAG review for first one at #782
We'd like to get review over remaining five substantive changes: immersive-web/webxr#1314 immersive-web/webxr#1332 immersive-web/webxr#1343 immersive-web/webxr#1353 immersive-web/webxr#1359

[matatk]

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!