Re: DeviceOrientation Clarification

Hi,

Thanks everyone for the great feedback. I noticed that a number of the
threads also touched on the Screen Orientation api
<https://w3c.github.io/screen-orientation/>. I am also currently working at
implementing this API for Chrome OS. I'll take this information into
consideration while working on these.

I plan to identify what issues I encounter while developing these, and to
provide that feedback. I would certainly like to find a way to make these
interact in a way that web developers can use them as easily as possible.

Lars, thank you for bringing up axis of device orientation vs the natural
hardware orientation (portrait/landscape.) I can see this being compounded
further by convertible devices Where the specification would consider the
state with an active keyboard to be a landscape device, but where when
converted to a tablet form factor one might consider it to be a portrait
device.

Regards,
Jonathan

On Sat, Nov 1, 2014 at 6:42 AM, Lars Knudsen <larsgk@gmail.com> wrote:

> I did write something that might make sense to you too a while back:
> http://lists.w3.org/Archives/Public/public-web-mobile/2014Apr/0018.html
>
> IMO, it is important with a holistic view when adjusting all orientation
> and full screen related specs.
>
> Br
> Lars
>
> On Nov 1, 2014 11:26 AM, "Rich Tibbett" <richt@opera.com> wrote:
> >
> > On 1 Nov 2014 11:19, "Lars Knudsen" <larsgk@gmail.com> wrote:
> > >
> > >
> > >
> > > On Sat, Nov 1, 2014 at 10:41 AM, Rich Tibbett <richt@opera.com> wrote:
> > >>
> > >> Hi Jonathan, Lars,
> > >>
> > >> On 31 Oct 2014 16:17, "Jonathan Ross" <jonross@google.com> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > I am currently working on implementing the DeviceOrientation Event
> Specification for Chrome OS.
> > >> >
> > >> > I wanted to get a clarification on one of the examples. The final
> example in Section 2 Introduction:
> > >> >
> > >> >>> A device is mounted in a vehicle, with the screen in a vertical
> plane, the top uppermost and facing the rear of the vehicle. The vehicle is
> travelling at speed v around a right-hand bend of radius r. The device
> records a positive x component for both acceleration and
> accelerationIncludingGravity. The device also records a negative value for
> rotationRate.gamma:
> > >> >>>
> > >> >>>       {acceleration: {x: v^2/r, y: 0, z: 0},
> > >> >>>
> > >> >>>        accelerationIncludingGravity: {x: v^2/r, y: 0, z: 9.81},
> > >> >>>
> > >> >>>        rotationRate: {alpha: 0, beta: 0, gamma: -v/r*180/pi} };
> > >> >
> > >> >
> > >> > From the description of the device I would have expected that the
> gravity component would be applied to the Y-axis. Giving
> accelerationIncludingGravity: {x: v^2/r, y: 9.81, z: 0}. Is that a correct
> interpretation?
> > >> >
> > >> > Furthermore, while testing implementations of the API I have
> noticed a discrepancy between the Chrome Android, and the Safari iOS
> implementations. Currently Android orients gravity in the same manner as
> the specification, with a flat device reporting
> accelerationIncludingGravity: {x: 0, y: 0, z: 9.81}. However I am seeing
> the gravity reversed with iOS, which reports accelerationIncludingGravity:
> {x: 0, y: 0, z: -9.81}.
> > >> >
> > >> > Currently I am planning to follow the specification and Android
> implementations. I wanted to bring this up because the inconsistency could
> make the API hard for web developers to use.
> > >> >
> > >> > Please advise.
> > >>
> > >> I sent an email to this list in July with the same observations:
> > >
> > >
> > > I feel your pain:
> https://groups.google.com/forum/#!msg/mozilla.dev.webapi/Qal4EQ1s2E0/yDM6JbtAGhwJ
> > >
> > > (been ranting about the faulty specs and implementations for years -
> but apparently you will quickly be put on the ignore list if you don't
> agree with the spec'er in charge ;))
> >
> > Tim and I only recently picked up  the editing of this spec. Please know
> we are very keen to get some consistency here any way we can.
> >
> > >>
> > >>
> http://lists.w3.org/Archives/Public/public-geolocation/2014Jul/0024.html
> > >>
> > >> I'm also not sure how we proceed here. My current interpretation is
> that Chrome for Android is providing the correct values and iOS values are
> inverted according to the spec guidelines.
> > >>
> > >> In that previous email I provided a demo of the problem.
> > >>
> > >> Is it possible to fix this inconsistency without breaking some
> existing content?
> > >>
> > >> On 31 Oct 2014 16:33, "Lars Knudsen" <larsgk@gmail.com> wrote:
> > >> >
> > >> > See this nice little compensation lib:
> https://github.com/richtr/Full-Tilt
> > >>
> > >> I wrote this library. I did not include any normalisation between iOS
> and Android DeviceMotionEvent.acceleration or
> DeviceMotionEvent.accelerationIncludingGravity data as I considered browser
> detection the incorrect way to fix inconsistencies at the time (e.g.
> if(iOS) then invert accelerometer values). Using browser detection would
> also make this library not future compatible in the case that either iOS or
> Android want to invert their implementations to provide consistency.
> > >>
> > >> I'm as uncertain what to do as you both are.
> > >>
> > >> What could we do? We can add whatever solution we decide on to the
> spec of course.
> > >>
> > >> - Rich
> > >
> > >
>
>