-
Notifications
You must be signed in to change notification settings - Fork 372
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove XRDevice from the spec text #427
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good. Only one substantive comment regarding the behavior of ondevicechange.
|
||
The page can request a device by calling the <dfn method for="XR">requestDevice()</dfn> method on the {{Navigator/xr}} object. When invoked it MUST return [=a new Promise=] |promise| and run the following steps [=in parallel=]: | ||
Any time an [=XR device=] is needed by an algorithm it can <dfn>ensure an XR device is selected</dfn> by running the following steps: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to imply that it might change from call to call even after a session has been established..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the logic to indicate this shouldn't happen. It's reads a bit weird, though. 😝
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I followed it, though yes... a bit convoluted :)
As a sanity check, are we certain about the ordering of those last three steps? As in, can we think of any reason why we might want to fire the devicechange before shutting down the session?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I gave some thought to that, and the primary reason I came up with for the current order is that some developers may try and create a session in response to the event. We wouldn't want to end it immediately after, so this order simply makes the logic cleaner.
@@ -982,42 +950,41 @@ WebGL Context Compatiblity {#contextcompatibility} | |||
|
|||
<pre class="idl"> | |||
partial dictionary WebGLContextAttributes { | |||
XRDevice compatibleXRDevice = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Etiquette question: given that these are WebGL changes, can they actually be specified in this document or do they need to be done differently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are existing scenarios where one spec implies additions or related functionality to another one. (That's more-or-less why we have the partial
keyword.) So I think this is appropriately scoped. For example, search for "WebGL" here: https://www.w3.org/TR/2017/WD-html52-20170718/single-page.html
Thanks for the speedy feedback! Took another pass to address your comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remaining comments aren't blocking sign off :)
Thanks for putting this together!
Update the existing spec text to take into account the changes made in #405, removing XRDevice.