Manifest & API Specification

[Anant Narayanan]

Hi all,

As we move towards standardizing our app manifest and the management APIs, we should be keeping track of the specification itself in a fairly formal manner. To this end, I've created an unofficial draft which you can find at: https://people.mozilla.com/~anarayanan/webapps.html

It's not fully complete (we still have to figure out the set of valid values for "required_features"), but it's close. Please send your feedback to the list!

Thanks,
-Anant

[Ian Bicking]

I think we talked about an "offline_enabled" property briefly (and it's
present in the Chrome app manifests), but I realize where it's actually
more important is as a "require_online" property. Specifically thinking
about an app that doesn't have an appcache – the experience is going to be
pretty bad. It'd be nice if we could override that or create our own
appcache fallback for that case, so the app doesn't just show connection
denied or some other error message, but actually shows a proper message.
The naming isn't so important (offline_enabled or require_online), but I
hadn't thought much about the actual use of it before. It would fit okay
in "required_features" I suppose (required feature: a network). I guess
they aren't exactly inverses either, as you can imagine an app that has an
appcache fallback of its own (and so at least fails gracefully), but can't
actually do anything useful when offline.

(There's also several mismatches between that document and the IDL/m-c
implementation, but we should probably do that review elsewhere; is the
document in source control somewhere?)

[Anant Narayanan]

On 3/23/2012 9:59 AM, Ian Bicking wrote:
> I think we talked about an "offline_enabled" property briefly (and it's
> present in the Chrome app manifests), but I realize where it's actually
> more important is as a "require_online" property. Specifically thinking
> about an app that doesn't have an appcache – the experience is going to
> be pretty bad. It'd be nice if we could override that or create our own
> appcache fallback for that case, so the app doesn't just show connection
> denied or some other error message, but actually shows a proper
> message. The naming isn't so important (offline_enabled or
> require_online), but I hadn't thought much about the actual use of it
> before. It would fit okay in "required_features" I suppose (required
> feature: a network). I guess they aren't exactly inverses either, as
> you can imagine an app that has an appcache fallback of its own (and so
> at least fails gracefully), but can't actually do anything useful when
> offline.

I think we should provide these features whether or not an app specifies
it in the manifest. If the network is unreachable or there was other
error in loading a page, we can show a default fallback or let the app
specify it via 404/401/etc. (there are some creative ones out there!)
which we then cache by default.

> (There's also several mismatches between that document and the IDL/m-c
> implementation, but we should probably do that review elsewhere; is the
> document in source control somewhere?)

Yup, I just added it: http://mozilla.github.com/openwebapps/ and source
is on the gh-pages branch:
https://github.com/mozilla/openwebapps/tree/gh-pages

Cheers,
-Anant

[JOSE MANUEL CANTERA FONSECA]

Hi,

In the Example (1.1) there is a mistake, the orientation property is
specified two times ...

best

El 23/03/12 17:45, "Anant Narayanan" <an...@mozilla.com> escribió:

>Hi all,

>
>As we move towards standardizing our app manifest and the management
>APIs, we should be keeping track of the specification itself in a fairly
>formal manner. To this end, I've created an unofficial draft which you
>can find at: https://people.mozilla.com/~anarayanan/webapps.html
>
>It's not fully complete (we still have to figure out the set of valid
>values for "required_features"), but it's close. Please send your
>feedback to the list!
>

>Thanks,
>-Anant
>
>_______________________________________________
>dev-webapps mailing list
>dev-w...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-webapps


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[JOSE MANUEL CANTERA FONSECA]

El 23/03/12 17:59, "Ian Bicking" <ia...@mozilla.com> escribió:

>I think we talked about an "offline_enabled" property briefly (and it's
>present in the Chrome app manifests), but I realize where it's actually
>more important is as a "require_online" property. Specifically thinking
>about an app that doesn't have an appcache ­ the experience is going to be
>pretty bad. It'd be nice if we could override that or create our own
>appcache fallback for that case, so the app doesn't just show connection
>denied or some other error message, but actually shows a proper message.
>The naming isn't so important (offline_enabled or require_online), but I
>hadn't thought much about the actual use of it before. It would fit okay
>in "required_features" I suppose (required feature: a network). I guess
>they aren't exactly inverses either, as you can imagine an app that has an
>appcache fallback of its own (and so at least fails gracefully), but can't
>actually do anything useful when offline.
>

>(There's also several mismatches between that document and the IDL/m-c
>implementation, but we should probably do that review elsewhere; is the
>document in source control somewhere?)

If an app developer specifies an offline cache manifest then he is
implicitly saying that the app can work offline ... So do we really need
these properties?

>
>
>On Fri, Mar 23, 2012 at 11:45 AM, Anant Narayanan <an...@mozilla.com>
>wrote:
>

>> As we move towards standardizing our app manifest and the management
>>APIs,
>> we should be keeping track of the specification itself in a fairly
>>formal
>> manner. To this end, I've created an unofficial draft which you can find
>> at: https://people.mozilla.com/~anarayanan/webapps.html
>>
>> It's not fully complete (we still have to figure out the set of valid
>> values for "required_features"), but it's close. Please send your
>>feedback
>> to the list!
>>
>>

[Harald Kirschner]

> If an app developer specifies an offline cache manifest then he is
> implicitly saying that the app can work offline ... So do we really need
> these properties?
>
>

I'd argue that the manifest does not imply an offline capability. Appcache is also used to aggressively caching resources on live (non-offline) sites by a few devs, even recommended by evangelists [1] or used in a similar fashion by wordpress (Turbo [2]) . Full offline support includes also data storage and some sync mechanism, and I don't know a lot of sites that go the whole way; I even have a hard time finding even a handful of apps that have full offline support.

"require_online" seems default "yes", as we deal with web apps. So I'd go with the chrome store property. Do they have feedback on the usefulness of that attribute, and if we should copy it?

[1] http://www.html5rocks.com/en/tutorials/speed/quick/#toc-appcache
[2] http://en.blog.wordpress.com/2008/07/02/gears/

---
Harald Kirschner | Mozillian Software Engineer | hkirs...@mozilla.com (mailto:hkirs...@mozilla.com)


On Monday, March 26, 2012 at 1:18 AM, JOSE MANUEL CANTERA FONSECA wrote:

>
>
> El 23/03/12 17:59, "Ian Bicking" <ia...@mozilla.com (mailto:ia...@mozilla.com)> escribió:

>
> > I think we talked about an "offline_enabled" property briefly (and it's
> > present in the Chrome app manifests), but I realize where it's actually
> > more important is as a "require_online" property. Specifically thinking
> > about an app that doesn't have an appcache ­ the experience is going to be
> > pretty bad. It'd be nice if we could override that or create our own
> > appcache fallback for that case, so the app doesn't just show connection
> > denied or some other error message, but actually shows a proper message.
> > The naming isn't so important (offline_enabled or require_online), but I
> > hadn't thought much about the actual use of it before. It would fit okay
> > in "required_features" I suppose (required feature: a network). I guess
> > they aren't exactly inverses either, as you can imagine an app that has an
> > appcache fallback of its own (and so at least fails gracefully), but can't
> > actually do anything useful when offline.
> >
> > (There's also several mismatches between that document and the IDL/m-c
> > implementation, but we should probably do that review elsewhere; is the
> > document in source control somewhere?)
> >
>
>
> If an app developer specifies an offline cache manifest then he is
> implicitly saying that the app can work offline ... So do we really need
> these properties?
>
> >
> >

> > On Fri, Mar 23, 2012 at 11:45 AM, Anant Narayanan <an...@mozilla.com (mailto:an...@mozilla.com)>

> > wrote:
> >
> > > As we move towards standardizing our app manifest and the management
> > > APIs,
> > > we should be keeping track of the specification itself in a fairly
> > > formal
> > > manner. To this end, I've created an unofficial draft which you can find
> > > at: https://people.mozilla.com/~anarayanan/webapps.html
> > >
> > > It's not fully complete (we still have to figure out the set of valid
> > > values for "required_features"), but it's close. Please send your
> > > feedback
> > > to the list!
> > >
> >
> > _______________________________________________
> > dev-webapps mailing list

> > dev-w...@lists.mozilla.org (mailto:dev-w...@lists.mozilla.org)

> > https://lists.mozilla.org/listinfo/dev-webapps
> >
>
>
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
> _______________________________________________
> dev-webapps mailing list

> dev-w...@lists.mozilla.org (mailto:dev-w...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-webapps
>
>

[Mounir Lamouri]

On 03/23/2012 09:45 AM, Anant Narayanan wrote:
> Hi all,

>
> As we move towards standardizing our app manifest and the management APIs, we should be keeping track of the specification itself in a fairly formal manner. To this end, I've created an unofficial draft which you can find at: https://people.mozilla.com/~anarayanan/webapps.html
>
> It's not fully complete (we still have to figure out the set of valid values for "required_features"), but it's close. Please send your feedback to the list!

According to the document, 'orientation' allowed values are "landscape"
and "portrait" but we were speaking of other values like
"portrait-primary", "portrait-secondary", "landscape-primary" and
"landscape-secondary". Did you only forget about those values or you did
not add them on purpose?

Also, I've been proposing to add an "activities" entry to the OWA
manifest format being part of a Web Intent/Web Activities API. See
dev-webapi mailing-list.
It is only for information for the moment. I will get back to you when
the general plan will get enough approval.

--
Mounir

[Jim Straus]

I forgot to post this earlier, but can we call the orientations: portrait, portrait-upsidedown, landscape-right, and landscape-left (or landscape-clockwise and landscape-counterclockwise)? These describe what the actual direction is whereas primary and secondary are opaque, particularly with respect to landscape. Note that these are what iOS gives to apps. We could also go with a numeric value (0 = portrait, 90 = landscape left, -90 (or 270) = landscape right, 180 = upside down, which I believe is what Safari sets in window.orientation in iOS).
-Jim Straus

> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-webapps

[Lucas Adamski]

On 3/26/2012 9:42 AM, Harald Kirschner wrote:
>
> I'd argue that the manifest does not imply an offline capability. Appcache is also used to aggressively caching resources on live (non-offline) sites by a few devs, even recommended by evangelists [1] or used in a similar fashion by wordpress (Turbo [2]) . Full offline support includes also data storage and some sync mechanism, and I don't know a lot of sites that go the whole way; I even have a hard time finding even a handful of apps that have full offline support.
>
> "require_online" seems default "yes", as we deal with web apps. So I'd go with the chrome store property. Do they have feedback on the usefulness of that attribute, and if we should copy it?
>
> [1] http://www.html5rocks.com/en/tutorials/speed/quick/#toc-appcache
> [2] http://en.blog.wordpress.com/2008/07/02/gears/
>
> ---
> Harald Kirschner | Mozillian Software Engineer | hkirs...@mozilla.com (mailto:hkirs...@mozilla.com)
>

> ebapps

Most news / magazine / book reader apps for tablet and phone support full offline mode. WSJ, Zinio, Financial Times,
Economist, etc just to name a handful. I'm guessing most games also have an offline mode. Given the intended use cases
it seems inevitable that we should support that as a frequent use case. Also seems like its up to the app to figure out
its offline model.
Lucas.

[Shane Caraveo]

On 12-03-26 11:46 AM, Mounir Lamouri wrote:
> On 03/23/2012 09:45 AM, Anant Narayanan wrote:
>> Hi all,
>>
>> As we move towards standardizing our app manifest and the
>> management APIs, we should be keeping track of the specification
>> itself in a fairly formal manner. To this end, I've created an
>> unofficial draft which you can find at:
>> https://people.mozilla.com/~anarayanan/webapps.html

> Also, I've been proposing to add an "activities" entry to the OWA
> manifest format being part of a Web Intent/Web Activities API. See
> dev-webapi mailing-list. It is only for information for the moment. I
> will get back to you when the general plan will get enough approval.

We had that a while ago, though it was "experimental" at one point, then
"services". It was removed when I moved the activities module out to
it's own extension, but the intention is to still have the ability to
install activities via app manifests. As well, we need similar
functionality for another project. It could be worth having some kind
of extension section of the manifest:

{
extensions: {
activities: { ... }
someotherfeature: { ... }
}
}

With something like that, the system could do a notifyObservers call for
each extension namespace to see if any other feature addon wants the
data, or potentially just store it in the db to be retrieved via some api.

Shane

[Mounir Lamouri]

On 03/26/2012 12:40 PM, Jim Straus wrote:
> I forgot to post this earlier, but can we call the orientations: portrait, portrait-upsidedown, landscape-right, and landscape-left (or landscape-clockwise and landscape-counterclockwise)? These describe what the actual direction is whereas primary and secondary are opaque, particularly with respect to landscape. Note that these are what iOS gives to apps. We could also go with a numeric value (0 = portrait, 90 = landscape left, -90 (or 270) = landscape right, 180 = upside down, which I believe is what Safari sets in window.orientation in iOS).

We are not going to use Webkit's value and we can't actually use the
values you proposed for the same reasans: both values would make more or
less sense for a phone but as soon as you have a tablet, it will not
work as expected. For example, orientation=0 means landscape for a
tablet but portrait for a phone. The same way, portrait-upsidedown would
means nothing for a tablet given that it should be name portrait-right.

Given that, I think the naming we have is probably the simplest.

--
Mounir

[Ian Bicking]

On Mon, Mar 26, 2012 at 4:51 PM, Shane Caraveo <scar...@mozilla.com> wrote:

> On 12-03-26 11:46 AM, Mounir Lamouri wrote:
>
>> On 03/23/2012 09:45 AM, Anant Narayanan wrote:
>>
>>> Hi all,
>>>
>>> As we move towards standardizing our app manifest and the
>>> management APIs, we should be keeping track of the specification
>>> itself in a fairly formal manner. To this end, I've created an
>>> unofficial draft which you can find at:

>>> https://people.mozilla.com/~**anarayanan/webapps.html<https://people.mozilla.com/%7Eanarayanan/webapps.html>

>>>
>>
>
> Also, I've been proposing to add an "activities" entry to the OWA
>> manifest format being part of a Web Intent/Web Activities API. See
>> dev-webapi mailing-list. It is only for information for the moment. I
>> will get back to you when the general plan will get enough approval.
>>
>
>
> We had that a while ago, though it was "experimental" at one point, then
> "services". It was removed when I moved the activities module out to it's
> own extension, but the intention is to still have the ability to install
> activities via app manifests. As well, we need similar functionality for
> another project.

Is there another way to register Activities that doesn't depend on Apps?
If so, it would seem preferable if the app manifest could point to that;
similar to point to an app cache manifest, rather than trying to inline
such a cache manifest into the app manifest. The Web Intents registration
seems rather tied to HTML, so I'm not sure how that would work.

Ian

[Shane Caraveo]

On 12-03-26 4:00 PM, Ian Bicking wrote:
> On Mon, Mar 26, 2012 at 4:51 PM, Shane Caraveo <scar...@mozilla.com
> <mailto:scar...@mozilla.com>> wrote:
>
> On 12-03-26 11:46 AM, Mounir Lamouri wrote:
>
> On 03/23/2012 09:45 AM, Anant Narayanan wrote:
>
> Hi all,
>
> As we move towards standardizing our app manifest and the
> management APIs, we should be keeping track of the specification
> itself in a fairly formal manner. To this end, I've created an
> unofficial draft which you can find at:

> https://people.mozilla.com/~__anarayanan/webapps.html

> <https://people.mozilla.com/%7Eanarayanan/webapps.html>
>
>
>
> Also, I've been proposing to add an "activities" entry to the OWA
> manifest format being part of a Web Intent/Web Activities API. See
> dev-webapi mailing-list. It is only for information for the
> moment. I
> will get back to you when the general plan will get enough approval.
>
>
>
> We had that a while ago, though it was "experimental" at one point,
> then "services". It was removed when I moved the activities module
> out to it's own extension, but the intention is to still have the
> ability to install activities via app manifests. As well, we need
> similar functionality for another project.
>
>
> Is there another way to register Activities that doesn't depend on
> Apps? If so, it would seem preferable if the app manifest could point
> to that; similar to point to an app cache manifest, rather than trying
> to inline such a cache manifest into the app manifest. The Web Intents
> registration seems rather tied to HTML, so I'm not sure how that would
> work.

That could work fine. It is an open question (to me) whether the tie-in
to apps is desirable or not. It is nice to have an explicit install
rather than bugging the user whenever an activity is found. To limit
that I've depended on frecency and login manager to indicate the
importance of a site, but that has its own issues as well.

Shane

[Mounir Lamouri]

On 03/26/2012 04:00 PM, Ian Bicking wrote:
> Is there another way to register Activities that doesn't depend on Apps?
> If so, it would seem preferable if the app manifest could point to that;
> similar to point to an app cache manifest, rather than trying to inline
> such a cache manifest into the app manifest. The Web Intents registration
> seems rather tied to HTML, so I'm not sure how that would work.

An application that handles an activity should be able to handle the
activity just after installation. Parsing the source code to see if
there is an <intent> [1], <meta> or <link> would be a bit silly. Using
the manifest seems like the best way to solve this IMO.

I think Google didn't think much about OWA in their proposal.

[1] Using <intent> would be a very bad idea actually...

--
Mounir

[Benjamin Smedberg]

On 3/26/2012 7:08 PM, Mounir Lamouri wrote:
> On 03/26/2012 04:00 PM, Ian Bicking wrote:
>> Is there another way to register Activities that doesn't depend on Apps?
>> If so, it would seem preferable if the app manifest could point to that;
>> similar to point to an app cache manifest, rather than trying to inline
>> such a cache manifest into the app manifest. The Web Intents registration
>> seems rather tied to HTML, so I'm not sure how that would work.
> An application that handles an activity should be able to handle the
> activity just after installation. Parsing the source code to see if
> there is an<intent> [1],<meta> or<link> would be a bit silly.

Why? Presumably the user agent is going to fetch the application when it
is installed *anyway*, so that it can immediately cache offline
resources? Shouldn't that just be part of the installation process? I
share the concern that the webapp manifest is reinventing solution to a
bunch of problems which are already specced or solved for websites, and
that we're going to end up creating this huge dichotomy between websites
installed-as-apps and websites run in-browser, which at least to me
would be a disservice to the web.

--BDS

[Shane Caraveo]

I'm curious what you see as being reinvented/already specced/solved.
It's just broad statement, having specifics would help me understand
what you are thinking.

Shane

[Anant Narayanan]

On 03/26/2012 11:46 AM, Mounir Lamouri wrote:
> On 03/23/2012 09:45 AM, Anant Narayanan wrote:
>> Hi all,
>>

>> As we move towards standardizing our app manifest and the management APIs, we should be keeping track of the specification itself in a fairly formal manner. To this end, I've created an unofficial draft which you can find at: https://people.mozilla.com/~anarayanan/webapps.html
>>
>> It's not fully complete (we still have to figure out the set of valid values for "required_features"), but it's close. Please send your feedback to the list!
>
> According to the document, 'orientation' allowed values are "landscape"
> and "portrait" but we were speaking of other values like
> "portrait-primary", "portrait-secondary", "landscape-primary" and
> "landscape-secondary". Did you only forget about those values or you did
> not add them on purpose?

It wasn't on purpose, I just wanted to get an initial draft out there.
No doubt we will be refining the spec a lot in the coming weeks! :)

On the specific issue of orientation, is there a use case for
portrait-secondary? I don't think there is one for landscape-secondary
either, and I'm not a fan of adding values that would go unused just for
consistency's sake. I would imagine that the UA would automatically
rotate the view if the user happened to be holding the phone
"upside-down" in either orientation.

I think orientation is mainly about the app telling the runtime about
whether it wants width>height or vice-versa. I don't think we can make
any assumptions about where hardware buttons are located on devices, so
defining primary & secondary might be hard (some android tablets have
buttons on top).

If there are concrete use-cases for primary/secondary, I'm happy to get
them added to the spec but I haven't come across any convincing ones so far.

Cheers,
-Anant

[Anant Narayanan]

On 03/26/2012 01:07 AM, JOSE MANUEL CANTERA FONSECA wrote:
> In the Example (1.1) there is a mistake, the orientation property is
> specified two times ...

Thank you, fixed!

As a reminder, the spec is hosted in the 'gh-pages' branch of the
openwebapps repository:
https://github.com/mozilla/openwebapps/tree/gh-pages from which github
automatically publishes http://mozilla.github.com/openwebapps/

Everyone is encouraged to send in pull requests!

Regards,
-Anant

[Benjamin Smedberg]

On 3/27/2012 2:05 PM, Shane Caraveo wrote:
>
> I'm curious what you see as being reinvented/already specced/solved.
> It's just broad statement, having specifics would help me understand
> what you are thinking.

Well I understand that the various specs are in flux, but the one
existing/deployed spec for this kind of activity/intent mechanism is
.registerProtocolHandler. There is nothing about this which is specific
to an installed application, although it's likely that we would make it
easier or automatic for applications to register these sorts of
behaviors (with less security prompting or whatever). As I read the
intents spec, it is also something which is available to any webpage,
and not just apps.

And once you've got a feature available to web pages in an interoperable
manner, I don't think it's good engineering practice to have a
*different* way of registering the same thing within an app manifest: it
just increases the number of things you have to engineer and test.

--BDS

[Mounir Lamouri]

On 03/28/2012 08:00 AM, Benjamin Smedberg wrote:
> Well I understand that the various specs are in flux, but the one
> existing/deployed spec for this kind of activity/intent mechanism is
> .registerProtocolHandler. There is nothing about this which is specific
> to an installed application, although it's likely that we would make it
> easier or automatic for applications to register these sorts of
> behaviors (with less security prompting or whatever). As I read the
> intents spec, it is also something which is available to any webpage,
> and not just apps.
>
> And once you've got a feature available to web pages in an interoperable
> manner, I don't think it's good engineering practice to have a
> *different* way of registering the same thing within an app manifest: it
> just increases the number of things you have to engineer and test.

I'm speaking of Web Activities, not Web Intents. Those are two different
things so it's not useful to come and say "Web Intents does that so Web
Activities could do that that way".

This said, we could probably have the app store scanning all the pages
of an installed application to check for <meta> elements (or whatever we
would use for activity registering) defining activity handlers. That
would indeed prevent to have a way of registering specific to installed
apps and another specific to web apps. However, this is assuming we end
up with a declarative way to register activity handlers.

Cheers,
--
Mounir

[Mounir Lamouri]

On 03/28/2012 01:21 AM, Anant Narayanan wrote:
> On the specific issue of orientation, is there a use case for
> portrait-secondary? I don't think there is one for landscape-secondary
> either, and I'm not a fan of adding values that would go unused just for
> consistency's sake.

So basically you want to forbid applications to have a
portrait-secondary or landscape-secondary orientations just because you
believe there is no use case for that? That seem quite a bit extreme...

> I think orientation is mainly about the app telling the runtime about
> whether it wants width>height or vice-versa. I don't think we can make
> any assumptions about where hardware buttons are located on devices, so
> defining primary & secondary might be hard (some android tablets have
> buttons on top).

On Android and iOS, there is a way to differentiate the two kind of
portrait and landscape because some apps will want one and not the other
or switch from one to the other. So, this difference makes sense.

> If there are concrete use-cases for primary/secondary, I'm happy to get
> them added to the spec but I haven't come across any convincing ones so
> far.

There is one. I will not discuss that here because it has been discussed
in dev-webapi a few times already.

--
Mounir

[Anant Narayanan]

On Mar 28, 2012, at 7:16 PM, Mounir Lamouri wrote:
> On 03/28/2012 01:21 AM, Anant Narayanan wrote:
>> On the specific issue of orientation, is there a use case for
>> portrait-secondary? I don't think there is one for landscape-secondary
>> either, and I'm not a fan of adding values that would go unused just for
>> consistency's sake.
>
> So basically you want to forbid applications to have a
> portrait-secondary or landscape-secondary orientations just because you

> believe there is no use case for that? That seem quite a bit extreme…

No, I said we won't add it until a use-case for it is presented to the list. This approach has been adopted for all other fields in the manifest as well.

>> I think orientation is mainly about the app telling the runtime about
>> whether it wants width>height or vice-versa. I don't think we can make
>> any assumptions about where hardware buttons are located on devices, so
>> defining primary & secondary might be hard (some android tablets have
>> buttons on top).
>
> On Android and iOS, there is a way to differentiate the two kind of
> portrait and landscape because some apps will want one and not the other
> or switch from one to the other. So, this difference makes sense.

Exposing whatever options the underlying OS offers makes sense to me.

>> If there are concrete use-cases for primary/secondary, I'm happy to get
>> them added to the spec but I haven't come across any convincing ones so
>> far.
>
> There is one. I will not discuss that here because it has been discussed
> in dev-webapi a few times already.

I tried to find the specific use-case in the list archives and failed (could you send a link to the message to the list?). However, I did find an email where you stated that everybody agreed on the need for all 4 values, and there were no objections. Your earlier email seemed to imply that there isn't a use-case for landscape-secondary and that it was added as an option only to stay consistent with primary-secondary, which is what I objected to.

I went ahead and added the primary/secondary options to the specification. If anyone has objections to this please let us know!

-Anant

[Mounir Lamouri]

On 03/28/2012 12:03 PM, Anant Narayanan wrote:
>>> If there are concrete use-cases for primary/secondary, I'm happy to get
>>> them added to the spec but I haven't come across any convincing ones so
>>> far.
>>
>> There is one. I will not discuss that here because it has been discussed
>> in dev-webapi a few times already.
>
> I tried to find the specific use-case in the list archives and failed (could you send a link to the message to the list?). However, I did find an email where you stated that everybody agreed on the need for all 4 values, and there were no objections. Your earlier email seemed to imply that there isn't a use-case for landscape-secondary and that it was added as an option only to stay consistent with primary-secondary, which is what I objected to.

Ok. I thought we talked about that in the mailing list. My bad.
Anyhow, the Screen Orientation API needs those different orientations
because an app might want to use all 4 orientations. For example, a game
might want to use two opposite orientations to have two players face to
face. This is only an example, there might be a lot of use cases.

If you are speaking of use cases to have orientations by default set to
*-secondary, it's probably harder. Though, I don't think we should limit
applications just because we don't see any obvious reasons. In addition,
given that Screen Orientation API is going to have 4 orientations, it
seems better, for consistency, to keep those 4 ones even if 2 of them
might be less used. (note: it's 4/2 without counting 'portrait' and
'landscape')

--
Mounir

[Jonas Sicking]

On Mon, Mar 26, 2012 at 12:40 PM, Jim Straus <jst...@mozilla.com> wrote:
> I forgot to post this earlier, but can we call the orientations: portrait, portrait-upsidedown, landscape-right, and landscape-left (or landscape-clockwise and landscape-counterclockwise)?  These describe what the actual direction is whereas primary and secondary are opaque, particularly with respect to landscape.  Note that these are what iOS gives to apps.  We could also go with a numeric value (0 = portrait, 90 = landscape left, -90 (or 270) = landscape right, 180 = upside down, which I believe is what Safari sets in window.orientation in iOS).

This doesn't work well on devices where landscape is the primary mode
of operation, such as most tablets. There you'd want something like
landscape, landscape-upsidedown, portrait-left and portrait-right.

Since we want the same set of properties on all devices I think the
set Mounir has suggested is the best option.

/ Jonas

[Jonas Sicking]

On Wed, Mar 28, 2012 at 12:03 PM, Anant Narayanan <an...@mozilla.com> wrote:
> On Mar 28, 2012, at 7:16 PM, Mounir Lamouri wrote:
>> On 03/28/2012 01:21 AM, Anant Narayanan wrote:
>>> On the specific issue of orientation, is there a use case for
>>> portrait-secondary? I don't think there is one for landscape-secondary
>>> either, and I'm not a fan of adding values that would go unused just for
>>> consistency's sake.
>>
>> So basically you want to forbid applications to have a
>> portrait-secondary or landscape-secondary orientations just because you
>> believe there is no use case for that? That seem quite a bit extreme…
>
> No, I said we won't add it until a use-case for it is presented to the list. This approach has been adopted for all other fields in the manifest as well.

I agree, this is the approach we tend to take with web features in
general. To add more details to the use-cases Mounir mentioned:

The use-cases for "portrait" and "landscape" should hopefully be
pretty obvious. They would both allow "either" portrait/landscape
directions. I.e. if you flip your phone/tablet upside down, the screen
would flip around and you'd see things right-side-up again.

However for a game where you are waving your device around a lot, for
example a racing game where you turn the car by turning your device,
you don't want the screen to flip automatically if you turn your car
hard enough. So for these cases we need to support "portrait-primary"
and "landscape-primary" as well.

That leaves "portrait-secondary" and "landscape-secondary". As Mounir
pointed out, these could be useful in a game where two players facing
each other take turns while having the device laying in between them
on a table. I'm less sure there are use-cases for putting these as
static orientations in the manifest file.

However it seems like a benefit to be consistent rather than just
excluding 2 out of 6 orientations. So I think we should support all
orientations in the manifest. And who knows, maybe someone will
develop a absolutely hilarious browser which renders the web
upside-down :)

/ Jonas

[Anant Narayanan]

As an update, the spec now lives at http://mozilla.github.com/webapps-spec/

(and the repository is at https://github.com/mozilla/webapps-spec so
feel free to send in your pull requests!)

Cheers,
-Anant

On 3/23/12 9:45 AM, Anant Narayanan wrote:
> Hi all,
>
> As we move towards standardizing our app manifest and the management APIs, we should be keeping track of the specification itself in a fairly formal manner. To this end, I've created an unofficial draft which you can find at: https://people.mozilla.com/~anarayanan/webapps.html
>
> It's not fully complete (we still have to figure out the set of valid values for "required_features"), but it's close. Please send your feedback to the list!
>

> Thanks,
> -Anant