W3C home > Mailing lists > Public > www-style@w3.org > November 2012

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

From: Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>
Date: Thu, 8 Nov 2012 13:48:47 +0100
Message-ID: <CAEC208uC0C0h-YZ1+Pr8GsNvgZV6GBHYnjQMnKJ-=zCo5cP8rg@mail.gmail.com>
To: Ryan Betts <rbetts@adobe.com>
Cc: Brad Kemper <brad.kemper@gmail.com>, www-style list <www-style@w3.org>
Hi there,

On Thu, Nov 8, 2012 at 12:25 AM, Ryan Betts <rbetts@adobe.com> wrote:

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

People would also be able to use the Fullscreen spec to turn the site into
fullscreen (preferrable into the right orientation, like clicking on a
html5 video often goes to fullscreen while rotating into landscape). This
is not supported by any mobile device that I know of yet, but it probably
would make sense supporting this in the near future.


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

The question is whether the latter should actually support automatically
changing orientation at all. The site can show different content ("please
rotate") using media queries, and the Fullscreen spec can be used instead
to allow changing orientation automatically, In fullscreen there will also
not be able back/forward buttons, so no problem with navigation.


>
> 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> wrote:
>
> On Nov 7, 2012, at 9:52 AM, Ryan Betts <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.
>
>
>
>


-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit. <http://gmail.com>org

﹆﹆﹆
Received on Thursday, 8 November 2012 12:49:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:02 GMT