Oh, I see what you are saying. I think there is some confusion here (perhaps on my part only).
I do not know if the main use of (and motivation for) the sensor APIs is webvr, but I have not been involved in it. I thought that (newer) API was brought up in this discussion as a suggestion for a replacement for the deviceorientation APIs. (Again, I’m unaware of the history or motivations behind that API.) There has been some supposition in this discussion that the main use of the device orientation APIs is the WebVR polyfill. I do not know if that is true, I don’t think Chris or I said that — I haven’t seen any mention of any data to support or not support that. It is clear that _a_ use of the device orientation APIs is supporting WebVR polyfill. But it also used for panoramic photo viewers, 360 video viewers, and probably other (legitimate) things. Regardless, I fully understand the security/privacy concerns. My message this morning was intended to (perhaps) reframe the discussion and (perhaps) let us move forward. Specifically: I was wondering about the real impact of the webvr polyfill not working, on Firefox users. My mention of the work implementing WebVR was pointing out that we will hopefully not need to worry about the webvr-polyfil working on Gecko-based browsers in the not-to-distant future, whenever we have full platform coverage for a real WebVR/WebXR implementation. What is/was unclear to me is: - if we’re including iOS in the list of platforms we may want to try and remove device orientation from. Matters insofar as we WON’T be able to implement WebVR/WebXR there. - when WebXR (including “Magic Window” support) will ship in all versions of Firefox. I could “guess” but that’s not useful (I have no control over that). But, if we laid out a plan that said “in the short term we’ll do X, which may not be ideal, when WebXR is available we’ll do Y”, that might help. I hope that the second step is not too far in the future, but thinking of it that way at least doesn’t lock us into “we need to find a satisfactory solution that keeps the webxr-polyfill working indefinitely” since it doesn't need to work indefinitely. Please forgive me for the lack of clarity. And, of course, if that sort of approach isn’t acceptable, just say so. > On Jan 11, 2018, at 12:53 PM, Anne van Kesteren <ann...@annevk.nl> wrote: > > On Thu, Jan 11, 2018 at 6:48 PM, Blair MacIntyre <bmacint...@mozilla.com> > wrote: >>> In that case I'm not entirely sure why we'd also pursue new >>> variants separately. >> >> I’m not sure what this means? > > That if our main usage for the new sensor APIs (those discussed in > https://github.com/w3ctag/design-reviews/issues/207) is WebVR/XR and > we don't have any other uses that are compelling enough, and WebVR/XR > will come with their own APIs for this, there's no reason for us to > worry about the new sensor APIs. > > > -- > https://annevankesteren.nl/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
