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

On Thu, Nov 28, 2013 at 12:31 PM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> 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?

IE11 implemented this to only work for fullscreen (via Fullscreen API
or F11). Making it work for "standalone" apps also makes sense. I +1
for a recommendation. We added something similar to the CSS Device
Adaptation spec.

>> 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 ;)

I agree.

>> 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().

I think that screen orientation should relate to screen orientation only.

>> 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.

Why not introduce a device-orientation MQ. There are already plenty of
existing Screen/Device related MQs.
http://dev.w3.org/csswg/mediaqueries4/#mf-dimensions

Kenneth

>
> --
> Mounir
>

-- 
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone  +45 4294 9458 ﹆﹆﹆

Received on Monday, 2 December 2013 13:07:37 UTC