Re: Enabling a Web app to override auto rotation?

Device-level orientation lock deals with different use-cases than the ones
we are discussing here. It let's the user force the device into either of
portrait or landscape mode whatever the physical orientation of the device
actually is.

The main reason for this need is that orientation of the device is
relative to the Earth's gravitational field and not to the physical
position of the user. That's typically annoying when you want to read
while lying down on your side. If the device's orientation was obtained
relative to the user's face (e.g. by means of a camera doing facial
recognition) the need for a device-level orientation-lock might not even
exist.

Document-level orientation lock is different. It isn't so much about
enabling applications to change orientation as it is about signaling to
the UA that UI only exists in one of portrait or landscape mode.

A good analogy is to think of photos or movies. The device's orientation
(or the dimensions of the screen) on which they are displayed won't
suddenly modify their characteristics. A picture in portrait mode is a
picture in portrait mode. Rotating it sideways won't suddenly turn it
(hah!) into a picture in landscape mode. How the device decides to display
it (cropping it, surrounding is with black bars, asking the user to rotate
the device) is an orthogonal issue.

Of course there are a number of points of friction (e.g. how do you handle
document-level and system-level oreientation-locks conflict, what happens
when you browse through a series of documents which have different
document-level orientation-locks, etc.), but these are best discussed as
part of the WG's work rather than in a preamble to decide whether or not
this is worth adding to the charter.

--tobie

On 2/10/12 6:28 AM, "timeless" <timeless@gmail.com> wrote:

>Personally I consider this a QoI issue for UAs.
>
>There will be lots of web pages that won't support / use this
>auto-rotation suppressor. UAs will need and want to let their users
>deal with this.
>
>The BlackBerry PlayBook for instance has an item for it: swipe in from
>top right corner, tap the orientation widget, select lock orientation,
>tap the application  content area, move on with life.
>
>I'm not saying it's perfect, and I've been planning to write out more
>detailed proposals for more advanced things, but sometimes adding a
>web-API doesn't really help the user. This isn't a web page problem,
>it's a system problem, and the user will benefit from having a
>*single* and *consistent* method for addressing it across all
>applications, native, web, and web written by other people who decide
>to put buttons and widgets in places the user won't expect.
>
>Disclaimer: while my employer isn't endorsing my opinion, I'm happy to
>use its products.
>
>On 2/8/12, Tobie Langel <tobie@fb.com> wrote:
>> The general use case is any UI that's been designed exclusively for
>> portrait or landscape mode because displaying it in the other mode
>>either
>> doesn't make any sense (e.g. most platform games), requires some
>>artifice
>> that the designer wanted to avoid (e.g. to function in landscape mode,
>> e-readers rely on the book metaphor), or isn't cost effective (i.e. it
>> requires designing two radically different UIs instead of one).
>>
>> --tobie
>>
>> On 2/8/12 9:16 AM, "Marcos Caceres" <w3c@marcosc.com> wrote:
>>
>>>
>>>
>>>
>>>On Wednesday, 8 February 2012 at 07:39, Charles Pritchard wrote:
>>>
>>>> In case it's needed; use case:
>>>>
>>>> User is drawing a sketch on their mobile phone and their rotation is
>>>>intentional as if they are working with a physical piece of paper.
>>>or a car game where the driving is controlled by how much the device is
>>>rotated (you want the orientation locked, probably to landscape)© There
>>>are other games, like Rolando [1], that make use of both portrait,
>>>landscape, and a kind of "fixed mode"© where the orientation is "fixed"
>>>no matter what way you rotate the screen (think of rotating a video
>>>camera© the world in the view finder stays "fixed")
>>>
>>>[1] http://rolando.ngmoco.com/
>>
>>
>>
>
>-- 
>Sent from my mobile device
>

Received on Friday, 10 February 2012 09:10:45 UTC