Re: Device Orientation specification co-editor

On Mon, Feb 17, 2014 at 10:11 AM, Rich Tibbett <richt@opera.com> wrote:

> Hi Rob,
>
> On Sun, Feb 16, 2014 at 8:15 PM, Rob Manson <roBman@buildar.com> wrote:
> >
> >> It would be great if you could send us some pictures/3D models you have
> >> that you think would clarify the specification.
> >
> >
> > We'll refine what we've got then send them through for discussion.
>
> Looking forward to your feedback :)
>
> >
> >> Was there anything in particular you would like to see improved in the
> >> current specification aside from visual examples?
> >
> >
> > I think if we want more general js developers to use the API successfully
> > then some more worked examples might be good - and no I don't think the
> > current matrix-based examples are what most js devs would think of as
> > "worked examples" 8).
>
> I agree and we should discuss what examples to include could be more
> helpful for web developers.
>
> FWIW, I think the current worked example included in the spec is
> useful but a little hard to parse for developers. Here is a JavaScript
> implementation of the worked example currently provided in the
> specification:
> http://people.opera.com/richt/release/tests/orientation/spec_workedexample.html
> .
>
> It may be good to include accompanying JavaScript code for any
> mathematical notation used.
>
> >
> > I know there's a lot of blog posts explaining how the API works...but I
> > couldn't find any that dealt with the additive nature of Euler angles -
> they
> > really just show how to access the events and the data returned. I know
> it's
> > a standard part of this concept...but it took us a while to work out this
> > issue as we were thinking of the 3 axes as independent. It was really
> only
> > when we noticed the third "code extract" in the spec that we realised the
> > flawed assumption in our code/approach.
> >
> > {alpha: 270 - alpha,
> >        beta: 0,
> >        gamma: 90};
> >
> > Just describing this more explicitly would lead to more developers
> > understanding this and then better implementations.
>
> Perhaps we can clarify this with additional JavaScript examples being
> added to the spec. Let us know what would you like to see.
>
> >
> > Another issue we have is with capability detection, especially on
> excluding
> > PC browsers.
> >
> > Many PC browsers have the window.DeviceOrientationEvent function
> > defined...yet never ever return a deviceorientation event. e.g. this code
> > registers a listener that never gets called...so we are left falling
> back to
> > some sort of timeout based assumption 8/
> >
> > if (!!window.DeviceOrientationEvent) {
> >   window.removeEventListener('deviceorientation', function() {
> >     // clearly supported
> >   }, true);
> >   // not clear at all until deviceorientation event called or some
> timeout
> > occurs 8(
> > } else {
> >   // clearly not supported
> > }
> >
> > This is the same for both DeviceOrientation and DeviceMotion.
> >
> > Having browsers NOT implement window.DeviceOrientationEvent unless they
> > truly do support it would be best. But I'm open to discussion of other
> > options or tips on how we could code around this more effectively.
>
> Would the following addition to the specification suffice here?
>
> "When support for a feature is disabled (e.g. as an emergency measure
> to mitigate a security problem, or to aid in development, or for
> performance reasons), user agents must act as if they had no support
> for the feature whatsoever, and as if the feature was not mentioned in
> this specification. For example, if a particular feature is accessed
> via an attribute in a Web IDL interface, the attribute itself would be
> omitted from the objects that implement that interface - leaving the
> attribute on the object but making it return null or throw an
> exception is insufficient."
>
> Of course, this would be entirely dependent on implementers following
> this requirement.
>

At least in Chrome/Chromium there is an implementation snag in hiding APIs
this way. It requires sniffing e.g. sensor presence or permissions and then
communicating that cross process, at page startup time. This is a blocking
process, to avoid (not) exposing the API incorrectly for some time. It's a
speed bump.

Perhaps we have a good solution for this now, it's worth checking.


>
> Until then it is likely developers will need to fallback with
> timeout-based DeviceOrientation feature detection as you mention
> above. I wonder whether we should include that in the spec considering
> it is (hopefully) a short-term problem.
>
> >
> >
> > Plus, as I mentioned earlier. I think Rich's point about having some way
> > from the API to clearly know how the device frame is related to the
> origin
> > orientation would be very good. Maybe just describing how it could/should
> > relate to screen-orientation would be useful - but I know that's still
> just
> > in draft http://www.w3.org/TR/screen-orientation/
>
> Yep. Just to clarify this issue: the key problem is if a user loads a
> web page using a non-default screen orientation (i.e. they rotate
> their screen and then load the page or the user rotates their screen
> at runtime). A web developer using DeviceOrientation is always
> required to currently do the following:
>
> 1. Obtain DeviceOrientation data as provided by our DeviceOrientation
> Event specification.
> 2. Hotfix returned DeviceOrientation data depending on the current
> screen orientation (if window.orientation <> 0 then real device
> rotation no longer matches provided the default DeviceOrientation
> data).
> 3. Listen for ongoing window.onorientationchange events and hotfix
> DeviceOrientation data whenever this event fires and
> window.orientation !== 0.
>
> We already find that _most_ DeviceOrientation demos do not respond
> correctly as screen orientation changes [A] [B] [C]
>
> [2]
> http://www.html5rocks.com/en/tutorials/device/orientation/deviceorientationsample.html
> [3] http://www.jeremyselier.com/s/demo/device_orientation.html
> [4] http://wellcaffeinated.net/demos/device-orientation
>
> There are a few different fixes we could pursue here at the
> spec/implementation level:
>
> 1. We could mandate that DeviceOrientation should always align to the
> current screen orientation (i.e. implementations hotfix
> DeviceOrientation to match screen orientation changes themselves).
> 2. We could provide developers with the necessary JavaScript-based
> DeviceOrientation axis hotfixes required as window.orientation moves
> through 90, 180, -90 degrees (i.e. away from the default
> window.orientation === 0).
> 3. We could provide developers with alternative solutions for fixing
> DeviceOrientation if window.orientation changes. e.g. developers can
> rotate a displayed HTML canvas element by -window.orientation to
> offset the change in screen orientation but continue to maintain the
> correct DeviceOrientation event behaviour.
>
> This problem needs more discussion on this list and in the spec :)
> Feedback on the three 'fixes' above would help to inform what we put
> in to the specification regarding this.
>
> >
> >
> >> Regarding Quaternion representation I think it would be good to have
> more
> >> justification for it's inclusion in the specification. Euler angles have
> >> known issues (at least theoretically e.g. gimbal lock) and were more or
> less
> >> abandoned in Android in favor of the quaternion representation. It is
> not
> >> clear though if this would be a useful addition for developers in
> Chrome.
> >> This may probably be worth a survey actually ;).
> >>
> >
> > Now that we've worked out how we should really be coding for this API and
> > that the main browsers have implemented it correctly then we're happy to
> > just work with Euler angles. But I think a survey could definitely be a
> good
> > idea.
>
> I'd like to see if there is further interest from developers or
> implementors for different rotation representations here. Step 1 is
> likely to be improving the clarity of the spec and the state of
> current implementations though (using the currently specified
> Tait-Bryan angles).
>
> - Rich
>
>