Re: Charter addition proposal: screen orientation lock

Hi there,

On Mon, Jan 30, 2012 at 1:22 PM, Robin Berjon <robin@berjon.com> wrote:

> Hi,
>
> On Jan 30, 2012, at 12:43 , Kenneth Rohde Christiansen wrote:
> > Orientation lock is already part of the CSS Device Adaption spec as part
> of the viewport meta tag
>
> Sorry, I should indeed have mentioned that as part of the background. The
> problem with specifying orientation as part of the viewport at rule is that
> it leads to circular dependencies (you can set an orientation inside a
> media query that changes the viewport and triggers and endless loop). The
> spec tries (meekly) to defend against that, but I find it difficult not to
> get the impression that this leads to a tangled mess and that it will
> confuse developers (it certainly confuses me when I try to make sense of
> the circularity avoidance recommendations made in the specification
> itself). This could be solved if it were only to appear in meta elements,
> but right now that's not the case and the section on meta elements in CSS
> DA isn't normative.
>

I see that that is a problem yes, but I guess that can be a problem with
the CSS DA in other cases?

My understanding has therefore been that orientation might get dropped from
> CSS DA. If that's not the case and if people are confident that it can be
> better addressed there (perhaps by being only a meta element solution) then
> I'm fine with it. My sole concern is that this be solved *somewhere* (and
> preferably not in a manner that makes it possible to construct a GOTO
> instruction in CSS).
>

I think we have some additional use cases for web apps on mobile devices.

On mobile phones it is common that apps take a little while to start and
thus people often show screenshots of the actual app while loading and then
fades the screenshot out and fades the actual app in. That gives a pretty
nice user experience.

In order to do something like this for web apps, it would be needed to
first show the app when the web app actually asks to, and thus be able to
execute media queries, javascripts before so. This would also make it
possible for the app to do something like requestFullscreen(HORIZONTAL)
before the app becomes visible. It would be possible to do it so that if
requestFullscreen is called before the app is visible when run as
standalone, then no user permission is needed.

This would mean that we can do without the meta tag. For a web browser it
would be quite bad usability to respect a orientation meta tag, because it
can lead to cases where you click on a link and suddently your whole
browser chrome rotates, and it can even do so when pressing the
forward/back button or selecting an page from the browser history. This is
why I said that this makes most sense for either stand-alone web apps, or
for apps entering fullscreen (pending on some user action, user permission
granting).

> , though this is only going to be optional and should be ignored for
> normal web browsing due to the effect on usability (think about navigating
> session history). It is thus mostly useful for fullscreen applications and
> stand alone web apps.
>
> I can certainly see how this would be ignored in a number of contexts, but
> I wouldn't restrict it to "stand alone" web apps. Web apps in the browser
> ought to be able to use it, though it might require them to be identified
> as apps (using whatever heuristics).
>

They can, they just need to go fullscreen first, which I think is a pretty
ok requirement.

>From our user testing on the Nokia N9, we had many confused users because
pages could turn off scaling of the web page (pinch zoom etc) by setting
the minimum-scale and maximum-scale of the viewport meta tag. If users see
the web browser chrome and the browser suddently doesn't want to change
orientation (which normally works) they become confused. They simply don't
associate pinch zoom and orientation change with the exact web page, they
associate it with the browser chrome.

> On the other hand, I think it would be nice to have a hint to the
> fullscreen api requestFullscreen where you could define a preferred
> orientation (which it would then lock to), something like
> requestFullscreen(HORIZONTAL). It would even be nice if the UA could tell
> whether it was possible to enter horizontal fullscreen mode or not, so that
> there can be some kind of fallback. Having it this way, it would be
> possible to click/tap on some element and animate the transition (scale +
> rotation) into the final state.
>
> I think that this makes sense. I guess that feedback should make its way
> to the HTML WG.
>

I am new to how W3C etc works, so how do we bring the feedback there?

Cheers,
Kenneth

-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit. <http://gmail.com>org

http://codeposts.blogspot.com ﹆﹆﹆