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 <[email protected] > (mailto:[email protected])> 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 ﹆﹆﹆
