[whatwg] Forcing orientation in content

[Tobie Langel]

On Tuesday, September 10, 2013 at 11:22 PM, Ian Hickson wrote:
> On Sat, 13 Jul 2013, Tobie Langel wrote:
> > It is not uncommon for mobile experiences to rely on the accelerometer
> > as an input mechanism, for example to control page scrolling (e.g.
> > Instapaper) or for gameplay.
> >  
> > In such cases, auto-rotation of the viewport is completely disruptive to
> > the user's experience and needs to be inhibited.
>  
> Sure, but that's an OS-level feature.

Arguably. Signaling auto-rotation inhibited requirements isn't, though. That's application-level. Auto-rotation inhibition needs to be automatic and scoped to the document.
> > So this isn't so much about forcing orientation as it is about
> > inhibiting auto-rotation.
>  
> This would only work if the page was already in the orientation the user
> wants, but how can we ensure that?

The UA is free to provide whatever UI it wants to allow the user to enable/disable auto-rotation inhibition and/or pick a preferred orientation. From the use cases can be derived requirements for the content author to be able to signal to the UA the preference to inhibit auto-roation. Whether the UA decides to comply to this stated pref, allow its user to override it, etc. should be implementation-specific.
> > Your desktop comparison is inadequate, as there aren't comparable
> > auto-rotation mechanisms there.
>  
> It would be equivalent to forcing a particular window size.

No. A better analogy is the autoplay feature of video elements. Merely a hint that can be overridden by the user/UA.

And frankly even that comparison is dodgy: playing a video doesn't have close to the discoverability and usability issues inhibiting auto-rotation at the OS level has.
> On Mon, 15 Jul 2013, Kornel Lesiński wrote:
> > Since specific, locked screen orientation is mostly needed in games, and
> > forced rotation is disruptive to other things on the screen (e.g. moving
> > buttons/addressbar to other physical edge of the screen), maybe it
> > should be tied to the Fullscreen API?
> >  
> > element.requestFullscreen({orientation:'landscape', autorotation:false})
> That makes sense to me. Anne?

Agreed these requirements are generally tied to fullscreen/absence of browser-chrome context. Unfortunately, this is achieved using a variety of AP across implementations (e.g. iOS/Android?). So this proposition would only cater to those situation where the fullscreen API was used.



--tobie