> For all the follow-on discussion, I think this is the last technical bone of contention:

>>> - After going around a while on this, we think the <meta> tag is an
>>> ok
>>> solution. We'd use a different name attribute. You'd just give a
>>> list of
>>> supported orientations.

>>> - For API, we propose that the meta tag be "live", in that if you
>>> want to
>>> restrict to portrait you set the value via JS and the orientation
>>> changes
>>> if necessary.

> Nested <iframe>s can go full screen.  IIUC, this <meta> proposal would prevent those nested iframes from explicitly setting an orientation while full screen.  That seems like an odd inconsistency.  The full screen API has done all the legwork of spec'ing this out, so we've been proposing here to ride on those coattails for orientation locking.

> I don't really see much reason to prefer a <meta> tag over a DOM API.  I see some reasons not to prefer it as relate to nested <iframe>s.  And I do agree with Robin that a <meta> tag would be harder to spec.  Not because of any particular abstract technical difficulty, just because it would require a lot more new work compared to drafting off of the full screen API (pun intended).

>>> - We originally proposed an event before orientation that could be
>>> cancelled, but now think this is a bad idea.

> Fwiw I 100% agree.

> Cheers,
> Chris

> On 22/01/2012, at 3:35 PM, Chris Jones wrote:

> > ----- Original Message -----
> >> From: "Paul Bakaus" <pbak...@zynga.com>
> >> To: "Dean Jackson" <d...@apple.com>, "Mounir Lamouri"
> >> <mou...@lamouri.fr>
> >> Cc: mozilla-dev-web...@lists.mozilla.org
> >> Sent: Thursday, January 19, 2012 1:32:03 AM
> >> Subject: Re: Screen orientation API proposal

> > For all the follow-on discussion, I think this is the last
> > technical bone of contention:

> >>> - After going around a while on this, we think the <meta> tag is
> >>> an
> >>> ok
> >>> solution. We'd use a different name attribute. You'd just give a
> >>> list of
> >>> supported orientations.

> >>> - For API, we propose that the meta tag be "live", in that if you
> >>> want to
> >>> restrict to portrait you set the value via JS and the orientation
> >>> changes
> >>> if necessary.

> > Nested <iframe>s can go full screen.  IIUC, this <meta> proposal
> > would prevent those nested iframes from explicitly setting an
> > orientation while full screen.  That seems like an odd
> > inconsistency.  The full screen API has done all the legwork of
> > spec'ing this out, so we've been proposing here to ride on those
> > coattails for orientation locking.

> > I don't really see much reason to prefer a <meta> tag over a DOM
> > API.  I see some reasons not to prefer it as relate to nested
> > <iframe>s.  And I do agree with Robin that a <meta> tag would be
> > harder to spec.  Not because of any particular abstract technical
> > difficulty, just because it would require a lot more new work
> > compared to drafting off of the full screen API (pun intended).

> Just a small point: a <meta> tag is a DOM API. In fact, you're
> proposing a non-DOM API :)

> >>> - We originally proposed an event before orientation that could
> >>> be
> >>> cancelled, but now think this is a bad idea.

> > Fwiw I 100% agree.

> > Cheers,
> > Chris

>> On 22/01/2012, at 3:35 PM, Chris Jones wrote:

>> > ----- Original Message -----
>> >> From: "Paul Bakaus" <pbak...@zynga.com>
>> >> To: "Dean Jackson" <d...@apple.com>, "Mounir Lamouri"
>> >> <mou...@lamouri.fr>
>> >> Cc: mozilla-dev-web...@lists.mozilla.org
>> >> Sent: Thursday, January 19, 2012 1:32:03 AM
>> >> Subject: Re: Screen orientation API proposal

>> > For all the follow-on discussion, I think this is the last
>> > technical bone of contention:

>> >>> - After going around a while on this, we think the <meta> tag is
>> >>> an
>> >>> ok
>> >>> solution. We'd use a different name attribute. You'd just give a
>> >>> list of
>> >>> supported orientations.

>> >>> - For API, we propose that the meta tag be "live", in that if you
>> >>> want to
>> >>> restrict to portrait you set the value via JS and the orientation
>> >>> changes
>> >>> if necessary.

>> > Nested <iframe>s can go full screen.  IIUC, this <meta> proposal
>> > would prevent those nested iframes from explicitly setting an
>> > orientation while full screen.  That seems like an odd
>> > inconsistency.  The full screen API has done all the legwork of
>> > spec'ing this out, so we've been proposing here to ride on those
>> > coattails for orientation locking.

>> > I don't really see much reason to prefer a <meta> tag over a DOM
>> > API.  I see some reasons not to prefer it as relate to nested
>> > <iframe>s.  And I do agree with Robin that a <meta> tag would be
>> > harder to spec.  Not because of any particular abstract technical
>> > difficulty, just because it would require a lot more new work
>> > compared to drafting off of the full screen API (pun intended).

>> Just a small point: a <meta> tag is a DOM API. In fact, you're
>> proposing a non-DOM API :)

>window.screen is part of "DOM level 0", and so is a "DOM API", but I
>agree the terminology here is not particularly helpful.  Not worth
>hanging up on.

>> One of the reasons we like this to be in markup is that we can
>> process the file externally, and thus know in advance what the
>> launch orientation of the page should be. For example, if the HTML
>> is stored in the app cache. We'd prefer to not have to fire up a
>> complete parsing and JS execution for that.

>We're proposing to have installable apps declare requested orientation in
>their manifests.  See [1] for a WIP example.  The syntax is JSON, so much
>easier to parse, and manifests themselves should be much smaller than the
>apps they describe.  Manifests allow us to solve this problem and other
>similar ones quite easily.

>Cheers,
>Chris

>[1]
>https://github.com/andreasgal/gaia/blob/master/apps/browser/manifest....
>p

>> Dean

>> >>> - We originally proposed an event before orientation that could
>> >>> be
>> >>> cancelled, but now think this is a bad idea.

>> > Fwiw I 100% agree.

>> > Cheers,
>> > Chris

> I agree with both of you. This should definitely be easily parsable,
> and I
> agree with Chris that app manifests are a much much better idea (for
> all
> kinds of reasons) than the meta tag madness. But this is probably
> content
> for a much broader discussion.

>> I agree with both of you. This should definitely be easily parsable,
>> and I
>> agree with Chris that app manifests are a much much better idea (for
>> all
>> kinds of reasons) than the meta tag madness. But this is probably
>> content
>> for a much broader discussion.

> I think to move the screen orientation proposal forward, we should have at least part of that broader discussion.

> Dean, has Apple been following the "web apps" efforts underway at Google and Mozilla?

> It goes without saying but implementations of that API will be
> allowed
> to disallow locking following their own rules: an error event will be
> fired on the request object if locking isn't allowed per platform
> conventions.

> interface ScreenLockRequest {
>     readonly attribute DOMString readyState; // "processing" or
>     "done"
>     readonly attribute DOMError? error;
>     attribute EventListener      onsuccess;
>     attribute EventListener      onerror;
>     attribute ScreenLock?        result;
> }

> interface ScreenLock {
>    void unlock();
> }

> On 25/01/2012, at 3:10 PM, Chris Jones wrote:

> > ----- Original Message -----
> >> From: "Paul Bakaus" <pbak...@zynga.com>
> >> To: "Chris Jones" <cjo...@mozilla.com>, "Dean Jackson"
> >> <d...@apple.com>
> >> Cc: mozilla-dev-web...@lists.mozilla.org, "Mounir Lamouri"
> >> <mou...@lamouri.fr>
> >> Sent: Tuesday, January 24, 2012 12:46:54 AM
> >> Subject: Re: Screen orientation API proposal

> >> I agree with both of you. This should definitely be easily
> >> parsable,
> >> and I
> >> agree with Chris that app manifests are a much much better idea
> >> (for
> >> all
> >> kinds of reasons) than the meta tag madness. But this is probably
> >> content
> >> for a much broader discussion.

> > I think to move the screen orientation proposal forward, we should
> > have at least part of that broader discussion.

> > Dean, has Apple been following the "web apps" efforts underway at
> > Google and Mozilla?

> I'm not sure exactly what you're referring to, sorry. Do you mean the
> W3C Web Apps WG?

> Yes, I believe so - pointers appreciated. Any formal involvement by
> Apple (i.e. if it meant joining a standards group) is not my
> decision, but I'm definitely interested.

>> interface ScreenLockRequest {
>>     readonly attribute DOMString readyState; // "processing" or
>>     "done"
>>     readonly attribute DOMError? error;
>>     attribute EventListener      onsuccess;
>>     attribute EventListener      onerror;
>>     attribute ScreenLock?        result;
>> }

>> interface ScreenLock {
>>    void unlock();
>> }

> Is there any reason for these to be separate interfaces?  I would find it more convenient to have unlock() on the request object, and just ignore the unlock() if the request failed or the lock had already been released.

> The spec *should* mention that any/all orientation locks can be dropped, at any time.  I don't know if a notification of this is absolutely needed, but if we find a use case it would be pretty easy to fire an "onerror" callback to a lock object, or something else.

> On 01/26/2012 08:30 AM, Chris Jones wrote:
> > ----- Original Message -----
> >> From: "Mounir Lamouri" <mou...@lamouri.fr>
> >> To: dev-web...@lists.mozilla.org
> >> Cc: pbak...@zynga.com, "Chris Pearce" <cpea...@mozilla.com>,
> >> "Boris Zbarsky" <bzbar...@MIT.EDU>, d...@apple.com
> >> Sent: Wednesday, January 25, 2012 3:56:35 PM
> >> Subject: Re: Screen orientation API proposal

> >> interface ScreenLockRequest {
> >>     readonly attribute DOMString readyState; // "processing" or
> >>     "done"
> >>     readonly attribute DOMError? error;
> >>     attribute EventListener      onsuccess;
> >>     attribute EventListener      onerror;
> >>     attribute ScreenLock?        result;
> >> }

> >> interface ScreenLock {
> >>    void unlock();
> >> }

> > Is there any reason for these to be separate interfaces?  I would
> > find it more convenient to have unlock() on the request object,
> > and just ignore the unlock() if the request failed or the lock had
> > already been released.

> That would break the purpose of Request objects and result attribute.

> > The spec *should* mention that any/all orientation locks can be
> > dropped, at any time.  I don't know if a notification of this is
> > absolutely needed, but if we find a use case it would be pretty
> > easy to fire an "onerror" callback to a lock object, or something
> > else.

> Sending an error event to the Request object wouldn't be doable.
> Request
> objects receive one event (success or error) and at that point, their
> state shouldn't change. At least, not being reverted.
> I think we might need something to let the author know the lock has
> been
> removed mostly because removing the lock is going to be UA specific
> neither specs nor authors can predict when UA are going to do that.

> --
> Mounir

> After discussing this API with Chris, I believe we might have find a
> consensus. If no-one comes with strong reasons to block this, I will
> implement the API and try to have the proposal move to a WG or a TF.

> Regarding UX, we think locking should be allowed when the content is
> in fullscreen or more generally when the webapp use the entire screen
> (for example, any webapp installed on a phone/tablet). We are going to
> punt to the UX team to decide if and how we should allow regular
> content to lock the screen.

> On 26/01/2012 00:56, Mounir Lamouri wrote:
> > Hi,

> > After discussing this API with Chris, I believe we might have find
> > a
> > consensus. If no-one comes with strong reasons to block this, I
> > will
> > implement the API and try to have the proposal move to a WG or a
> > TF.

> > Regarding UX, we think locking should be allowed when the content
> > is
> > in fullscreen or more generally when the webapp use the entire
> > screen
> > (for example, any webapp installed on a phone/tablet). We are going
> > to
> > punt to the UX team to decide if and how we should allow regular
> > content to lock the screen.

> In Gaia the homescreen, which is also a webapp, contains all the
> other
> window. Webapps are not fullscreen but contained into an iframe that
> is
> smaller than the height of the screen. So except the homescreen,
> nothing
> is fullscreen. (There will be an API to make an app fullscreen but
> that's an other question).

> Also what if a webapps lock the screen in portrait and then the
> virtual
> keyboard pop-up (the application window is resized). Does it means
> the
> lock will be cancelled?