Re: [screen-orientation] When window orientation != screen orientation...

On Wed, Nov 27, 2013, at 23:46, John Mellor wrote:
> How should the Screen Orientation API handle cases where the web page's
> window has the opposite orientation to the device's screen? Examples
> where
> this can occur include:
> 
> - Split screen tablet (like Win 8 Metro)
> - Non-maximized window on tablet (like Win 8 non-Metro)
> - WebView embedded in native app
> - <iframe> within larger web page
> 
> The orientation media query is defined to
> be<http://www.w3.org/TR/css3-mediaqueries/#orientation>
> :
> 
> "'portrait' when the value of the 'height' media feature is greater than
> or
> equal to the value of the 'width' media feature. Otherwise 'orientation'
> is
> 'landscape'".
> 
> 
> That definition cleverly handles this situation, by always returning the
> orientation of the window - so apps that haven't considered this
> possibility (i.e. almost all of them) will behave as intended.
> 
> We can do the same thing for screen.orientation, and have it return
> portrait/landscape using the same logic as the media query (i.e., really
> it
> would provide window orientation). The trickier question, is how should
> this interact with locking the orientation?
> 
> For example it would be disastrous if on a portrait split-screen tablet,
> a
> game's window was initially landscape, but the game then locked the
> screen
> to landscape, and the game's window ended up becoming portrait as a
> result!

I think this is an interesting problem. I thought the specification was
pointing that it is an implementation detail but it seems that nothing
is said about that. Also, the intent of Screen Orientation is not to
give the orientation of the window or lock it but to give the
orientation of the screen. The window orientation is a pretty trivial
information to get.

> There are four possible solutions:
> 
> 1. Only allow locking orientation when the web page's window is maximized
> or fullscreen (hence the orientation of the screen and window should
> almost
> always be the same.

That sounds reasonable. The only issue is that it is mostly a UX issue
and I feel that the specification should limit itself to recommend this
but not enforce it. What do you think?

> 2. Rely on developers to notice that their window has the opposite
> orientation to the device's screen, and do the right thing.

Relying on developers to do the right thing in order to not shoot
themselves in the foot is probably a good recipe for a bad API ;)

> 3. In cases where the current window is neither maximized nor fullscreen,
> make orientation lock rotate the individual window, not the entire
> screen.

Not a fan of that solution. The Screen Orientation API should be about
the screen, not the window. If you want to rotate your window, you can
use window.resizeTo().

> 4. In cases where the window has the opposite orientation to the device's
> screen, invert the orientation values that the developer passes in, i.e.
> calling lockOrientation("landscape") in the portrait split-screen case
> above would keep the device's screen as portrait (and hence the web
> page's
> window would remain landscape), and conversely calling
> lockOrientation("portrait") would rotate the device's screen to landscape
> -
> which would hopefully cause the web page's window to become portrait,
> though that depends on how the window manager handles rotating a split
> screen; if the split is kept in the same orientation rather than being
> rotated, the window end up becoming even move landscape than it used to
> be!
> As you can see this is window-manager-dependent, and isn't completely
> reliable.

As you said after, this is not reliable.

> So, #2 won't work, #4 isn't reliable, and #3 is guaranteed to work but
> isn't necessarily great UX. So I'd recommend that we add #1 to the spec
> as
> a non-normative recommendation. Conveniently though, this is easily
> extensible without breaking compatibility, so if a future browser/OS
> decides that e.g. #3 is fine UX, then they can allow that.

I think the solution #1 is probably the best. We should just judge how
strict should the specification be. I would tend to be lose but I do not
know the best practices regarding UX considerations in specifications.

> In all cases though, making screen.orientation match the media query is
> important.

I do not agree actually. By definition, on my laptop, screen.orientation
should always return 'landscape-primary' unless I play with the display
properties. However, if the orientation media query is based on the
window, I could resize a window in a way that the content will see
itself as portrait wrt the orientation media query and landscape wrt the
screen orientation API. I do not think that needs to change.

--
Mounir

Received on Thursday, 28 November 2013 11:31:30 UTC