W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: Charter addition proposal: screen orientation lock

From: Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>
Date: Mon, 30 Jan 2012 15:57:30 +0100
Message-ID: <CAEC208vs0f2rwZBqqtYvAqwabiRhc1tj6Tca2hdp3C0V+3RUmg@mail.gmail.com>
To: Mounir Lamouri <mounir@lamouri.fr>
Cc: public-webapps@w3.org

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

> 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).


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 ﹆﹆﹆
Received on Monday, 30 January 2012 14:58:20 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC