- From: Jonathan Ross <jonross@google.com>
- Date: Mon, 3 Nov 2014 17:08:27 -0500
- To: Lars Knudsen <larsgk@gmail.com>
- Cc: Rich Tibbett <richt@opera.com>, Robert Flack <flackr@google.com>, Eugene Girard <girard@google.com>, public-geolocation@w3.org
- Message-ID: <CAFRAvkifoh2eTXCkmekZVLzfgOoEf+EwNy5L+0=RKrJtHuUC6A@mail.gmail.com>
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 > > > > > > > >
Received on Monday, 3 November 2014 22:08:54 UTC