W3C home > Mailing lists > Public > public-geolocation@w3.org > February 2014

Re: Device Orientation specification co-editor

From: Rob Manson <roBman@buildAR.com>
Date: Mon, 17 Feb 2014 06:15:24 +1100
Message-ID: <53010E4C.9030703@buildAR.com>
To: public-geolocation@w3.org
Hey Tim,
> I think your input is very valuable as you actually built something 
> using the existing API :).

8)


> 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.


> 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 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.


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.


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/

> 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.

roBman
Received on Sunday, 16 February 2014 19:15:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:07 UTC