Re: Measuring the gap between the spec and browser implementations

Hey Tim,

thanks for the detailed response.


> The demo looks pretty cool ;)

8) lots more to come!


> What version of Chrome did you use for testing? There is a
> spec-conforming implementation for Android since Chrome M32 (which
> should go stable tomorrow). Additionally there is a somewhat smoother
> implementation for Device Orientation in Chrome M33 (goes beta in a few
> days).

Ah that's awesome news! I was using 31 as it was the latest public 
version. Will definitely re-test and update our browser exclusion when 
32 is out.


> As you mentioned there are differences in implementations across
> browsers and I have contacted developers at Apple and Mozilla about this
> issue.

Yay...that's exactly the type of dialogue I was hoping had happened!


> The Apple engineer responsible for this was aware of this issue
> and expressed the hope to fix this soon.. Additionally Safari currently
> only provides the non-absolute version of Device Orientation, hence the
> alpha angle depends on how you hold the device at the start of Device
> Orientation. It was mentioned as something that would need fixing in the
> future.

Hrm I hope they catch up to the Android browsers soon. And without WebGL 
and WebRTC the iOS Safari browser is now definitely at least a 
generation behind the market 8(


> As a side note regarding the current spec using Euler angles, I've heard
> of an idea to expose something similar to Android's
> Sensor.TYPE_ROTATION_VECTOR which is a quaternion based representation.
> While probably less intuitive for developers this representation would
> not suffer from discontinuity at gimbal lock positions as compared to
> the Euler angles..

Yep I think having an alternative quaternion representation would be 
great and we would definitely use it. It took quite a bit of fiddling 
around to get the euler order right.

But, for us the buggy offsets and the gamma 90/-90 create bigger 
implementation issues than any gimbal lock we've seen in practice.


> Regarding recommendations wrt ranges in the spec. The ranges have been
> chosen to map uniquely to all possible orientations in space (except for
> the so-called gimbal lock position). If gamma is in 180,-180 this would
> introduce a not well defined representation.

Hrm...could you please provide me some pointers to discussion and 
background on this? We really just can't understand the logic here but 
perhaps we're missing some info.

If it's only 90/-90 then from all our development it seems impossible to 
derive a usable position of the phone in landscape mode for up/down 
rotation. I'd be happy to provide working demos and some test code 
(along with some 3D diagrams/animations) that show exactly what we're 
struggling with here.


> Regarding the "absolute" property in iOS I recall Apple mentioned it is
> currently always undefined which should translate as close enough to false ;).

Yep that's how we treat it 8)


> Please note that there is a more recent version of the spec (June 2012)
> available at http://dev.w3.org/geo/api/spec-source-orientation.html.

Awesome thanks.

roBman

Received on Monday, 13 January 2014 17:43:48 UTC