Re: [css-device-adapt] Wording regarding orientation.

Kenneth and Brad - both really good points. There might be two context-dependent recommended default behaviours.

Kenneth's point about the "normal browser" disabling orientation change is well heard. This is broadly covered where the last line states "It is recommended that it is ignored for normal web navigation to avoid confusing the user." In that context, modifying orientation of the DOM contents is more overtly experienced as a `behaviour` rather than an element of `presentation,` so I agree that defaulting to (b) and then allowing user action to instigate the switch seems logical.

Brad and I have the same gut instinct about mimicking the way native apps honour orientation preferences. But this is probably only (or at least more significantly) relevant in a standalone/fullscreen context. Because there is an expressed desire on the part of the user to treat this as an app, (a) makes more sense to me as the default. Incidentally, the fullscreen browser toggle on iOS is only available via landscape mode so at least on that platform it'd be pretty harmonious with the way the browser works.

If we defaulted to (a) in the browser w/ chrome, it'd be a bit of a weird experience. In native apps, the orientation only ever forces a change based on user action (even if that action is just launching the app). If the user hits your URL in portrait and the content really only works in landscape, then there should probably be an interstitial instructing them the rotate their device, or (as Kenneth has suggested) a button that makes use of a programmatic interface [1] to lock the orientation to landscape. But I think it's best that people don't have to be rotating their phones by default in the "normal browser."

Thoughts? I'm really leaning to (a) for app-like contexts and (b) for the "normal browser".

Cheers.
-Ryan

[1] http://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html#current-orientation

On 2012-11-07, at 2:52 PM, Brad Kemper <brad.kemper@gmail.com<mailto:brad.kemper@gmail.com>> wrote:

On Nov 7, 2012, at 9:52 AM, Ryan Betts <rbetts@adobe.com<mailto:rbetts@adobe.com>> wrote:

Hey Kenneth,

Good point about potential conflicts between the @viewport orientation attribute and UA/OS restrictions. I think the way this is clarified might warrant more discussion, as I can think of a number of instances when I've been using devices locked in an orientation and the app's preference has over-ridden it (landscape-locked games are a great example).

The question at hand: in the instance of a conflict should it be the @viewport attribute or the UA / OS that is allowed to narrow the scope of available orientation options?

Where '->' expresses the direction of the orientation override, the options seem to be:
a) @viewport -> UA -> OS
b) OS -> UA -> @viewport

So, if the OS says "portrait only" and @viewport says "no - landscape only," then (a) would result in `landscape` being honoured whereas (b) would result in `portrait` being honoured. Given that (b) could break the user experience I think that (a) would be the desired behaviour. Does that sound reasonable?

I think that's right If I lock the orientation of my iPhone screen to vertical, then AFAIK, none of my apps will know the difference between that and the situation where I've never rotated my phone out of that orientation. But this does not prevent some apps from using the device's long dimension as width (and some apps are like that, as you point out). So the browser app should be consistent. If @viewport is telling the browser to go landscape, then it should (or at least let the viewport go landscape), regardless of what is known or not about orientation.

Otherwise, your fixed width/height HTML app might end up letterboxed and tiny on a vertical screen. While I have seen some video that acts that way in some apps, I've also seen some that will always play the video in device landscape regardless of orientation and orientation lock. So that kind of thing should be allowed via @viewport.