Re: [screen-orientation] Remove the ability to lock to multiple orientations?

I'd be fine with changing the API to only take a single string value.
I agree the usecases for locking to multiple orientations isn't strong
enough to warrant the compatibility complexities that come from the
fact that you can't implement the API on android. At least I haven't
heard such usecases.

However it does mean that we need to also have a way to define that
orientation should be completely unlocked. This is needed since the
manifest spec allows overriding the default unlocked orientation. I.e.
it should be possible to use the manifest to say that an app should be
in portrait mode, but then allow a page to temporarily override that
to allow any orientation.

/ Jonas

On Thu, Mar 13, 2014 at 11:21 AM, Mounir Lamouri <> wrote:
> Hi,
> I would like to change the Screen Orientation API to make the locking
> steps a bit simpler. Currently, the API tries to be flexible and allow
> locking to any combination of values like "portrait", "landscape",
> "portrait-primary" but also [ "portrait", "landscape-primary" ], [
> "portrait-primary", "landscape-primary" ]. The three first orientations
> are very common. The others are pretty odd and I doubt I ever saw that
> in the wild.
> Allowing to pass an array of orientation has a lot of impact on the
> specification:
> - given that the combinations are pretty exotic, we should assume that
> some UA will not be able to lock because the system will not allow it
> [1];
> - we have the problem of whether all the items in the array should be
> available or only one of them to work. The specifacation currently
> answer the question of whether "portrait" <=> [ "portrait-primary",
> "portrait-secondary" ] but what about [ "landscape-primary",
> "portrait-primary" ].
> Removing this feature will allow the specification to enforce that all
> states are working because it is fair to assume that the system will not
> block the UA to lock to those basic orientations. In addition, this
> would be a future-compatible change in the sense that adding this later
> will be smooth. I am really eager to make the specification a bit less
> flexible because right now, implementing this specification without
> being able to lock would be following the specification.
> I am particularly interested to hear feedback from Microsoft and Mozilla
> who have prefixed implementations. I know that Firefox Android only
> allows the basic orientations but Firefox OS allows any orientation to
> be passed I believed [2]. I unfortunately can't test IE11 on mobile.
> [1] Very likely, any UA could simply re-write the mechanism that listen
> for device orientation changes and do manual screen locking based on
> that, though...
> [2]
> -- Mounir

Received on Friday, 14 March 2014 05:10:10 UTC