Re: [screen-orientation] screen orientation angle

+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
>>
>>
>