Re: [screen-orientation] screen orientation angle

Lars wrote:
> it would make sense to agree on portrait or landscape to be *the* primary
orientation for all devices

Hmm, but some devices don't have a primary portrait orientation. For
example the Motorola Xoom has a clear primary landscape orientation, but
users are equally likely to hold it in either portrait orientation
(depending on handedness, etc). So games would at least need to deal with
180 degree rotations of the device orientation.

It seems a better option would be for the Device Orientation API to provide
values relative to the current screen up direction. This could be optional
if anyone can think of use cases where you both a) need absolute device
orientation, and b) wouldn't have already locked the screen orientation.


On Tue, Nov 26, 2013 at 5:59 PM, Lars Knudsen <larsgk@gmail.com> wrote:

> +1 to this new angle ;)
>
> Seriously, it would be great if we can finally get closer to a solution
> where (especially) new web apps developers will not get too confused about
> different representations of orientation between different specs and
> devices.  It would be great with some reference apps to hold this up
> against while the spec is still possible to change.  If anyone feels it
> makes sense, I'd be happy to chip in with that.
>
> One thing that is not 100% clear to me if handled yet though:  IMO, it
>  would make sense to agree on portrait or landscape to be *the* primary
> orientation for all devices - and let everything else be a relative angle
> (in degrees) to that.  Most cases where developers will need this feature
> will be for games utilizing the accelerometer (xyz readings) AND they will
> most likely design the game for portrait or landscape use.  Not having to
> deal with differences between landscape/portrait devices but just be able
> to rely on "(X,Y,Z) = (0,1,0)" when holding the device "portrait up" in all
> cases will eliminate one layer of mapping.  If this is already handled
> here, I am sorry for repeating myself.
>
> best wishes
> Lars
>
>
>
> On Tue, Nov 26, 2013 at 9:25 AM, John Mellor <johnme@google.com> wrote:
>
>> This all sounds reasonable; it's great that we'll be able to remove the
>> spec's artificial requirement that "if the device is in landscape-primary
>> and is rotated 90 degrees clockwise, that should be represented as
>> portrait-primary".
>>
>> And it potentially opens the door to using a less error-prone selection
>> of keywords too.
>>
>>
>> On Tue, Nov 26, 2013 at 4:38 PM, Mounir Lamouri <mounir@lamouri.fr>wrote:
>>
>>> Hi,
>>>
>>> The Screen Orientation API defines an angle relationship between
>>> portrait-primary and landscape-primary. The reason for that is that
>>> developers would know which orientation is at 90 degrees from the
>>> current orientation, which one is at 180 degrees, etc. However, by
>>> forcing the two primary orientations to have a relationship, we prevent
>>> UA to do clever things like having landscape-primary being related to
>>> how the user uses his phone (eg. usually depending on which hand is
>>> used, the most common landscape is not going to be different).
>>>
>>> In addition, some use cases might need to know the angle between the
>>> current orientation and the native device orientation. For example, a
>>> compass using DeviceOrientation would need to know this angle to be able
>>> to draw the correct information on the screen [1].
>>>
>>> This is also a UC that Mozilla has with Firefox OS where some apps want
>>> to lock the orientation to the native device orientation (ie. angle=0)
>>> [2].
>>>
>>> So, the Screen Orientation API should allow locking to a specific
>>> orientation angle. For that, we could allow an integer to be passed to
>>> the lockOrientation() function, a modulo operation would be applied on
>>> the number to have it in the [0; 360[ range. If the UA is not able to
>>> lock to the specified angle, the method should fail (return false for
>>> the moment, the promise should fail in the future).
>>>
>>> The orientation angle should also be read. It would be possible to
>>> simply use window.orientation. I am not a big fan of that solution [3]
>>> but this is implemented by most Mobile UAs already so it might as well
>>> be the best thing to do. An alternative would be to have something like
>>> screen.orientationAngle or screen.orientation.angle (and
>>> screen.orientation.name).
>>>
>>> WDYT?
>>>
>>> [1] http://oldworld.fr/google/compass.html
>>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=908058
>>> [3] the value can be negative, which is a footgun and the having this
>>> value living in window and the rest in window.screen is odd
>>>
>>> --
>>> Mounir
>>>
>>>
>>
>