Re: Screen Orientation Status

Hi Mounir,

Thank you for the latest edits to the Screen Orientation API! I've got a
few points of feedback I'd like to share following a review.

Firstly, the current draft makes a strong assumption that screens are
rectangular, and in some cases, non-square. Two examples:

    (1) The OrientationAngle is defined to be an enumeration of four
numbers (as strings...): 0, 90, 180, 270. Non-rectangular screens, for
example a round screen on a watch, should also be lockable to other angles,
for example to point the watch' screen towards the user, depending on the
angle of one's arm.

    (2) Reading the current screen orientation type is defined to *always*
return "portrait-{primary, secondary}" for any of the four possible
orientations for a square screen, which includes round screens. While
"screen.orientation.angle" could be used to get a more precise orientation,
it feels a bit icky.

While I'm not aware of an immediate need for this API on non-rectangular
screens, it's definitely not unthinkable. The proposed OrientationAngle
enumeration is not very scalable for arbitrary orientations, and it may be
better for "screen.orientation.angle" to return a number [0, 360], and
lockOrientation() to accept either a textual representation or a number [0,
360].

Secondly, the specification describes in section 8 that the Manifest API
allows a web application to set the default orientation. Why was this
chosen, rather than the manifest defining the initial orientation lock? If
I were to call screen.unlockOrientation() in a page that defines
[landscape] as the orientations in the manifest file, I think I would
expect all of the platform's default orientations to be available again.

Furthermore, a few points of editorial feedback:

    * The example (section 1) concatenates "screen.orientation" with a
string, while this has been changed to be an OrientationInformation object.
 It should read "screen.orientation.type" instead.

    * The definition of active orientation lock (section 4.3) is used
extensively in section 4.2. Should these be switched around to preserve
some form of chronology?

    * It may be good to clarify in section 4.5 (Default orientation) that
the default allowed values should follow platform conventions.

Thanks,
Peter


On Thu, Apr 3, 2014 at 10:36 PM, Mounir Lamouri <mounir@lamouri.fr> wrote:

> Hi,
>
> I have just updated the specification WD, solving most of the
> outstanding issues:
> https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html (it
> is hot off the press, be gentle with typos and nits)
>
> There are now only two outstanding bugs now:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25053
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25054
>
> I have an idea on how to handle them but I would like to discuss those
> during the F2F next week.
>
> Implementation status:
> - Implemented and shipped prefixed in Firefox Desktop, Firefox Mobile
> and Firefox OS;
> - Implemented and shipped prefixed in IE11 Mobile;
> - Currently being implemented in Blink for Chrome Android
> (implementation match current ED).
>
> Note: the implementations are not compatible with the current ED but no
> implementer raised concerns about the changes when discussed here.
>
> Path to LC:
> Unless there are new outstanding issues being raised, I would like to go
> to LC when the two bugs above are fixed. Hopefully just after the F2F.
>
> Test suite:
> None yet. No test suite coordinator at the moment.
>
> Thanks,
> -- Mounir
>
>