Re: [screen-orientation] screen orientation angle

On Wed, 27 Nov 2013 01:22:47 +0700, John Mellor <johnme@google.com> wrote:

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

In fact, if you know the handedness of the user (heuristically available  
 from the orientations the user chooses freely), you can request the e.g.  
portrait orientation that makes sense. On some devices (e.g. with game  
controllers) this is almost irrelevant, as virtually nobody uses them  
upside down, but on phones with a couple of extra keys - e.g. most camera  
apps, or where you primarily move from talking to looking and back, it  
seems like a reasonable use case.

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

Initialising an app that uses visual display and the accelerometer, or  
where you use two orientations (e.g. portrait for entering data, followed  
by switching to landscape)...

cheers

Chaals

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



-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
         chaals@yandex-team.ru         Find more at http://yandex.com

Received on Tuesday, 26 November 2013 20:37:20 UTC