Re: Screen Orientation API: Feedback

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.

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.

Application developers are usually not stupid - but do many mistakes and
need to test and develop workarounds for a load of different devices if the
specs are not aligned and the values are not consistent.

PLEASE (seriously) consider not letting the device manufacturer decide what
is the "natural 0 degree" - but require that DEG_0 = PORTRAIT_UP = (0,1,0)

As i mention above - it's MUCH easier for game developers to figure out
that they need to do a 90 degree mapping of everything if they choose to do
a landscape locked game than somehow handling weird translations in some of
the cases (with devices they might not even have access to).

In any case, any spec should be smoke tested on real developers before
going out of draft :)

br
Lars Knudsen


On Sun, Apr 7, 2013 at 6:33 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> This is feedback for the draft located at
> https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html
>
> 1) Per http://dev.w3.org/csswg/cssom-view/ Screen does not inherit
> from EventTarget so dispatching events to it will not give you
> anything meaningful. That should be fixed one way or another.
>
> 2) Rather than using sequence, the preferred way for creating an API
> that takes a list is using a variadic:
>
>   boolean lockOrientation(DOMString... orientations);
>
> 3) The algorithms end up dispatching events, however no task is
> queued. That's a bug.
>
> 4) Rather than using DOMString, an enum should be used. This should
> also simplify the algorithms somewhat (though beware that by using a
> variadic no argument passed is a possibility).
>
> 5) An event handler attribute IDL definition should not have
> "[TreatNonCallableAsNull]".
>
>
> --
> http://annevankesteren.nl/
>
>