RE: Screen Orientation API: Feedback

Another question about this spec.

3.3 Lock the orientation
The action to lock the orientation consists of forcing the rendering of the current browsing context to be shown as if the screen was oriented in one or many of the current orientation.

Says there is a window and an iframe in the window. Calling lockOrientation with portrait in window and calling lockOrientation with landscape in iframe, what is the correct behavior of user agent in the case?

-Bin

From: Lars Knudsen [mailto:larsgk@gmail.com]
Sent: Tuesday, April 9, 2013 10:24 PM
To: Jonas Sicking
Cc: Anne van Kesteren; WebApps WG; Mounir Lamouri
Subject: Re: Screen Orientation API: Feedback



On Tue, Apr 9, 2013 at 4:01 PM, Jonas Sicking <jonas@sicking.cc<mailto:jonas@sicking.cc>> wrote:
On Sun, Apr 7, 2013 at 10:44 AM, Lars Knudsen <larsgk@gmail.com<mailto:larsgk@gmail.com>> wrote:
> Hi,
>
> Having some background in both webapps and actual browser development
> (webkit, Nokia N9), I see a few issues with the current proposal (some
> already mentioned in the mozilla thread about this last year).
>
> 1. whatever terminology chosen for portrait/landscape and primary/secondary
> it NEEDS to be aligned with the media queries terminology AND values or
> every web developer will have to somehow make their own mapping to handle
> things.
I agree that we should align with media queries.

> 2. IMO, one of the primary reasons for having orientation lock is to be able
> to (finally) do proper accelerometer (DeviceOrientation) based games.  For
> this to work smoothly for the developers, the axis orientation NEED to be
> aligned with the orientation.
I think that the direction that per DeviceOrientation is "up" is
what's *rendered* as "up" and not what's "up" on the hardware. That
way the only difference between a page that's locked in landscape mode
vs. portrait mode is the dimentions of the window, and not the
coordinates that you receive from the deviceorientation events.

As long as both MediaQueries, xyz-accelerometer data, orientation lock and more *all* are aligned, this could work.
However, we need to have this tested with a bunch of developers - to see where they make mistakes caused by possible confusion.

My own opinion on this is still to keep it in a specific orientation also (e.g. "portrait up") as 0 degrees, as it makes everything more easy to handle
when the basics are kept static.  I can tell you that even inside the same company (mobile phone manufacturer), I have seen mistakes in the mapping
of the xyz-accelerometer values *alone* between units coming from slightly different branches.  This was because some were "landscape" devices
and some were "portrait" and everything have to match from the low level HW to the high level javascript API.

If we make sure that a device - no matter how the rest of the UI is turning - is always considered "0 degrees" when held - e.g. "portrait up", (x,y,z) = (0,1,0), then:

1. non-game developers can be happy with "lock to landscape" and never need to worry about the inner workings  and
2. game developers (using the accelerometer) won't have to reinvent strange mappings when juggling media queries, accelerometer and orientation lock.

If we allow "natural landscape" units and "natural portrait" units - then in some cases, when in a landscape locked game, the gravity goes in the direction of "negative X" - and in some cases it goes in the direction of "negative Y".  And it gets worse if you don't even know which landscape (left or right up) you got.

If we enforce that the device always has "0 degrees" when held portrait up (Y positive pointing at 90 degrees) - then "lock to landscape right up" always gives gravity in "negative X".



This definitely needs to be defined somewhere.

/ Jonas

- Lars