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

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!

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.

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

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

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.

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.

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