Re: Charter addition proposal: screen orientation lock

Hello,

On Mon, Jan 30, 2012 at 3:36 PM, Mounir Lamouri <mounir@lamouri.fr> wrote:

> On 01/30/2012 12:43 PM, Kenneth Rohde Christiansen wrote:
> > Hi there,
> >
> > Orientation lock is already part of the CSS Device Adaption spec as part
> > of the viewport meta tag, 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.
>
> Actually, I was thinking of asking this to be removed from CSS DA.
> A JS API seems more useful than an CSS property. For example, CSS DA
>

I agree with that and I am ok with removing it from CSS DA. I was just
pointing out that it was there right now.


> doesn't seem to allow you to read screen orientation value. It also
> doesn't allow you to know when the screen orientation changes. In
> addition, doing dynamic changes to the current screen orientation is
> pretty annoying (doable with CSSOM I believe).
> In the other hand, a JS API would allow you to do all of that and
> locking the orientation very easily. The only drawback is that you can't
> declare the screen orientation of your application in the header of the
> HTML file. However, at Mozilla we believe that could be set in the
> application manifest (see the link to the conversion Robin gave for more
> details).
>

That would be a good idea


> Also, I do not think the specifications should restrain the conditions
> in which the screen orientation lock can happen. At least not at the
>

It doesn't have to do that, but it could point out that UAs might want to
restrict the orientation lock to certain situations. But I think we might
end up with most browsers acting differently and causing fragmentation,
thus some recommendation should be fine and can be ignored if the UA seems
fit.


> beginning (so implementors can easily experiment) and that should not be
> a hard requirement (not a MUST). If a UA wants to allow content to lock
> the screen orientation in any situation, that should be doable. UA
> should take care of their own user experiences. Some UA might require
> fullscreen to be set before (that seems sensible), some might just allow
> this for pre-installed content (without requiring fullscreen).
>
> > 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.
>
> Linking screen orientation and fullscreen like that seems a bad idea.
> Basically, you can only lock and never reads. In addition, how do you
> handle an iframe requesting fullscreen?
>

We need this to be tied together in some way, so that it is possible to
click on say, a video element and have to animate entering fullscreen and
rotating at the same time. Doing these two transitions separately, would
look pretty bad (at least animated).

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 ﹆﹆﹆