On Wed, 27 Nov 2013 01:22:47 +0700, John Mellor <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
        [email protected]         Find more at http://yandex.com

Reply via email to