Define the relationship between device orientation/motion events and screen orientation in the spec

[richtr]

The spec should include information about how deviceorientation and devicemotion events are expected to behave relative to the current orientation of a device's screen.

Some background reading on this topic is available here:
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0296.html
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23072
https://groups.google.com/d/msg/mozilla.dev.webapi/SCK80a0Oqws/X2PrzXDMk6UJ
http://lists.w3.org/Archives/Public/public-geolocation/2014Jan/0010.html (bottom of response email reply)

Requests in the above discussions seem to indicate that the spec should be changed from mandating that 'the device coordinate frame is defined relative to the screen in its standard orientation' to 'the device coordinate frame is defined relative to the current up orientation of the screen' (where we should define 'up orientation' also in the spec).

It makes sense to define this according to the window.orientation API for now (with screen rotations available as 0, 90, 180, -90 degrees from the standard screen orientation position as it rotates counter-clockwise) until the Screen Orientation API [1] is updated to include window.orientation-like behavior (proposed at [2]).

Having deviceorientation/devicemotion events report data relative to the current 'up' frame of the screen will mean web developers will not have to manually 're-wire' deviceorientation/devicemotion data according to the current screen 'up' frame in order for their creations to work as expected.

An alternative approach is for the DeviceOrientation Events spec to provide developers with the necessary way to 're-wire' deviceorientation and devicemotion events via their own JavaScript as the screen orientation changes (e.g. [3]). This would be sub-optimal because it assumes all web developers will incorporate this 're-wire' code in their deviceorientation/motion based web apps.

Any further ideas here? Is there broad agreement from developers and implementers that deviceorientation should be provided relative to a screen's current 'up' frame?

[1] https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24698
[3] http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/att-0296/Remapping_Table.PNG

[richtr]

Further discussion on this topic is at http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0203.html.

In this thread @sicking also argues that we should incorporate Screen Orientation in to returned Device Orientation data – therefore providing alpha, beta and gamma values that match the current 'up' frame relative to the screen – by adding the following to the spec:

partial interface DeviceOrientationEvent
{
  readonly attribute double? screenAlpha;
  readonly attribute double? screenBeta;
  readonly attribute double? screenGamma;
}

[richtr]

Proposed spec change is now available as Pull Request #10.

[marcoscaceres]

Is there some way we can stop with the alpha, beta, gamma nonesense?

[richtr]

What do you want to see instead @marcoscaceres?

[marcoscaceres]

Angles and x, y, z.

[richtr]

Generally speaking we can say that alpha = z, beta = x, gamma = y.

But depending on the world coordinate system you use that can change. e.g. three.js employs a different coordinate system where alpha = y, beta = x, gamma = -z (see: https://github.com/mrdoob/three.js/blob/master/examples/js/controls/DeviceOrientationControls.js#L48).

[marcoscaceres]

What three.js is doing might be good - Do you know of other libs that are changing the coordinate system?

[richtr]

I believe CSS transforms match the z-x-y convention of device orientation events.

There are lots of different conventions for coordinate systems though. You can have left-handed and right-handed conventions, the Y and Z axis switched around (like in three.js) or the axis that is perpendicular to the ground being either positive or negative toward the center of the earth. You can also have any combination of those factors together. It isn't a one-size fits all thing.

[marcoscaceres]

Sure, but no one is doing alpha, beta, gamma and negative angles, right?

[richtr]

The angles are mathematically sound :) That is to say, you can compute quaternions and rotation matrices from them as they are defined today. Euler angles are generally defined using both positive and negative offset from a default position. More info is available at https://en.wikipedia.org/wiki/Euler_angles#Signs_and_ranges.

[marcoscaceres]

Why am I reminded of this cartoon? :)

[richtr]

I'm sorry if that is how this discussion came across.

We do not plan to re-define standard 3D Cartesian coordinate space though. If you have more info on an alternative coordinate system then we can discuss it here.

[marcoscaceres]

Wikipedia appears to say that it's not a requirement that one use negative angles. I don't think we need to define some alternative system: just one that is more developer friendly. If we are seeing evidence that developers are changing coordinate systems, they might have a good reason.

[anssiko]

Closing as a long overdue task per #10 (comment) decision to not add new features that are not implemented by any vendor.