clean up mentions and discussions of devicemotion

[blairmacintyre]

There are a number of discussions of devicemotion in the documents. The API was never standardized, and multiple organizations are pushing to change or remove it. So, for example, we should not assume a developer can use device motion before or instead of creating a session, and may want to be explicit in ensuring that WebXR handles all the use cases it needs to without assuming devicemotion exists.

[toji]

Which documents do you see devicemotion mentioned in? I did some searches and turned up nothing.

[blairmacintyre]

Sorry: deviceorientation.

[toji]

Ah, got it. FWIW the bulk of references to the API are in the "Why not use thing X instead of a new API?" section of the explainer. As a result I would suggest that the appropriate step to take it to add a line to that section about how the API is non-standard and being pushed for removal, since that seems like a good reason not to use it. 😁 I'll scrub references to it from the rest of the doc, though.

[toji]

Also, do you have any links handy that demonstrate the effort to change or remove the API? It would be good to point to them in the explainer in the "why not" section.

[blairmacintyre]

Looks good.

[anssiko]

The new API: https://w3c.github.io/orientation-sensor/

[cvan]

btw, there's a ton of context and good discussion about the Generic Sensor APIs here when support was recently added to the WebVR Polyfill: immersive-web/cardboard-vr-display#10

(note: cardboard-vr-display is an npm package dependency of webvr-polyfill)

[anssiko]

Now that webvr-polyfill recommends users to enable Generic Sensor APIs (see https://github.com/immersive-web/webvr-polyfill/releases/tag/v0.10.3) it is probably a good idea to acknowledge them in the Explainer in place of the legacy deviceorientation/devicemotion API.

Any concerns? I can craft a PR.

[toji]

No concerns here. Given that you seem more familiar with the Generic Sensor APIs than I am I'd appreciate it if you could put together a PR, thanks!

[anssiko]

@toji, see PR #334.