Re: Screen Orientation API: Feedback

On Tue, Apr 9, 2013 at 4:01 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Sun, Apr 7, 2013 at 10:44 AM, Lars Knudsen <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