I don’t understand this comment. > On Jan 11, 2018, at 12:50 PM, Martin Thomson <m...@mozilla.com> wrote: > > As Anne said, I don't know why you would define a new API rather than > enhancing the existing one, other than NIH. But I guess the damage is > now done. > > On Fri, Jan 12, 2018 at 4:48 AM, Blair MacIntyre <bmacint...@mozilla.com> > wrote: >>> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre <bmacint...@mozilla.com> >>> wrote: >>>> First, this discussion pertains to FF on Windows, Mac, Android and Linux, >>>> I assume? FF for iOS just uses the wkWebView and it’s up to Apple to >>>> decide on things like this. Is this correct? >>> >>> I believe there's some tricks we could pull on iOS in theory. >> >> Perhaps. But is that part of the discussion? I ask because >>> >>> >>>> From a WebVR perspective, the polyfill (that uses device-orientation) >>>> defers to the built in WebVR API if it exists. >>> >>> So WebVR/XR has its own equivalents for these APIs? I was not aware of >>> that. >> >> No, it’s different: WebVR/XR provide precise 3D orientation and position >> (assume 3D position tracking is available) of the display. Typically, >> that’s a Head-Worn Display (ie., a Vive or Rift or whatever). Currently, >> WebVR has only been implemented only for head-worn displays. The polyfill >> was used to fill in the gaps; provide “VR” on those paper “cardboard” >> display holders, for example. >> >> Moving forward, WebXR will include the notion of “Magic Window” displays, >> meaning “you’re holding the device in your hands and it tries to give the >> appearance of a portal into the virtual or AR world”. So, “tracked 3D >> content”. >> >> For the WebVR/XR api to work, it must provide a super-set of the >> device-orientation capabilities to the application. There are separate >> discussions about the security aspects of WebVR/XR: it will not be >> accessible without permission or user-gesture, as this API is. >> >> So, it’s not an “equivalent” API, but is rather providing the information >> needed to do 3D AR/VR directly, without relying on getting device >> orientation from this API. >> >> >>> In that case I'm not entirely sure why we'd also pursue new >>> variants separately. >> >> I’m not sure what this means? >> >>> >>> >>> -- >>> https://annevankesteren.nl/ >>
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform