Re: Charter addition proposal: screen orientation lock

On Monday, 30 January 2012 at 22:50, Kenneth Rohde Christiansen wrote:

> Hi there,
>  
> On Mon, Jan 30, 2012 at 1:22 PM, Robin Berjon <robin@berjon.com (mailto: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.

Kinda related… Native Webapps CG started working on this for widgets… but would be nice to have a universal "Web" solution:

http://dvcs.w3.org/hg/nativeapps/raw-file/tip/splashscreen/Overview.html

The use cases and requirements are the same.  
  
>  
>  
> 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 (tel:%2B45%204093%200598) / E-mail kenneth at webkit. (http://gmail.com)org
>  
> http://codeposts.blogspot.com ﹆﹆﹆

Received on Monday, 30 January 2012 13:18:25 UTC