Re: Intent to implement W3C Manifest for web application
On 16 July 2015 at 14:36, Ehsan Akhgari wrote: > As far as I can tell, neither of the above are things that another UA can > hook into. Am I correct in my understanding here? > I asked about that for Chrome Custom Tabs, a Googler told me there's an API so that other browsers can create the equivalent if they want to. I'm not sure if that's something we'd want to do with Fennec. But the important point is that it will keep users in the context of native apps and has the potential to reduce mindshare of the concept of the "browser" altogether. App Links and App Indexing bypass browsers altogether, install banners are something we could implement. > If the above assertion is true, then you need to replace "the web" with > Chrome and Safari on their respective OSes. > Given the market share of those browsers on their respective operating systems I'd argue that amounts to the same thing. But yes, Firefox is its own island. With the new Android and iOS features I described that island is increasingly cut off from users. > How does supporting W3C manifest or lack thereof help or hurt this? > Couldn't we detect these "web apps" by looking at the meta tags inside > pages? It seems like manifests are not technically needed for this. > Sure. Web apps are just web sites with extra metadata. A manifest linked from a web page using a manifest link relation is a way for a page to associate itself with that metadata, for the purpose of discovery. The fact that it's JSON rather than HTML is largely a practical implementation detail, because adding 12+ meta tags to the of every web page doesn't scale very well. As I said, for the simple use case of defining an application-name and icon meta tags work fine, and we will support that. > How are we planning to hook into the OS through Firefox? It seems like a > lot of the "web" integration coming to Android and iOS is essentially > integration with the browser developed by the OS vendor. > I'm trying to find that out, I'd be interested to see some experimentation of how possible it is to create a standalone display mode for Firefox on various operating systems, accessible by launchers added from the browser, treated as a separate "app" by the OS, but using the same Gecko instance and profile as Firefox. Like Chrome does on Android. > > 3. Promoting re-engagement with web content through icons in >> launchers, >> offline and push notifications >> > > Again, how does supporting W3C manifest or lack thereof help or hurt > this? It seems like we can pick up the icons/application-name through the > meta tag as well. An icon and name is not enough metadata to describe modern web apps, as I said above using a manifest file is just a practicality, like having CSS and JavaScript in separate files to HTML. > And given that the manifest format helps people link to the native app > offerings, it seems like supporting it will slightly hurt this goal! > We don't have to implement that feature and we should argue to have it removed from the spec. I don't think this is a good enough reason to give up on the standardisation altogether. > > 4. Guiding users to the best of the web through a crowd-sourced, >> community curated guide >> > > I'm not sure how W3C manifest helps here either. > W3C manifests allow web apps to be crawled by search engines and discovered by users through their user agent without needing them to be submitted to a central app store by the developer. They provide the metadata needed to describe a web app, and provide a built-in discovery mechanism. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On 2015-07-16 8:17 AM, Benjamin Francis wrote: Exactly. We can no longer talk about "merging the web and native" as some potential future thing that may or may not happen. It is already happening: 1. Android's Chrome Custom Tabs will keep users in native apps when following external hyperlinks https://developer.chrome.com/multidevice/android/customtabs 2. Android's App Links will let native apps register to handle a particular web URL scope and remove the choice of the user to choose to open in the browser instead https://developer.android.com/preview/features/app-linking.html 3. App install banners in Chrome may prompt users to install a web app or a native app, and the user may not even be able to tell the difference https://developers.google.com/web/updates/2015/03/increasing-engagement-with-app-install-banners-in-chrome-for-android?hl=en http://www.w3.org/TR/appmanifest/#related_applications-member 4. Android's App Indexing will surface content from inside Android apps in Google results https://developers.google.com/app-indexing/ 5. iOS's "Universal Links", "Smart App Banners" and new search API will do much of the same on iOS https://developer.apple.com/videos/wwdc/2015/?id=509 As far as I can tell, neither of the above are things that another UA can hook into. Am I correct in my understanding here? This all points towards a future where the web and proprietary app platforms are so intertwined that users may not even know the difference. If the above assertion is true, then you need to replace "the web" with Chrome and Safari on their respective OSes. The question is how we respond to that. On Firefox OS we have the freedom to define the entire experience, but on the other operating systems we touch we need to accept the reality of the environment that we find ourselves in. My personal conclusion is that we should react to all of the above by pushing back in the other direction by: 1. Helping users discover a web app before they discover its native equivalent, whilst browsing and searching the web How does supporting W3C manifest or lack thereof help or hurt this? Couldn't we detect these "web apps" by looking at the meta tags inside pages? It seems like manifests are not technically needed for this. 2. Making web content a first class citizen on every OS Firefox touches, with a standalone display mode for Firefox How are we planning to hook into the OS through Firefox? It seems like a lot of the "web" integration coming to Android and iOS is essentially integration with the browser developed by the OS vendor. 3. Promoting re-engagement with web content through icons in launchers, offline and push notifications Again, how does supporting W3C manifest or lack thereof help or hurt this? It seems like we can pick up the icons/application-name through the meta tag as well. And given that the manifest format helps people link to the native app offerings, it seems like supporting it will slightly hurt this goal! 4. Guiding users to the best of the web through a crowd-sourced, community curated guide I'm not sure how W3C manifest helps here either. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On 16 July 2015 at 01:44, Robert O'Callahan wrote: > As long as platforms exist with homescreens and other inventories of > "installed apps", of which the browser is one, it seems worthwhile to me to > support adding Web apps to those inventories so they're peers of native > apps instead of having to go through a level of indirection by launching a > browser, making them second-class. > > We can argue that such platforms shouldn't exist, but we also have to work > with the reality that they do. Exactly. We can no longer talk about "merging the web and native" as some potential future thing that may or may not happen. It is already happening: 1. Android's Chrome Custom Tabs will keep users in native apps when following external hyperlinks https://developer.chrome.com/multidevice/android/customtabs 2. Android's App Links will let native apps register to handle a particular web URL scope and remove the choice of the user to choose to open in the browser instead https://developer.android.com/preview/features/app-linking.html 3. App install banners in Chrome may prompt users to install a web app or a native app, and the user may not even be able to tell the difference https://developers.google.com/web/updates/2015/03/increasing-engagement-with-app-install-banners-in-chrome-for-android?hl=en http://www.w3.org/TR/appmanifest/#related_applications-member 4. Android's App Indexing will surface content from inside Android apps in Google results https://developers.google.com/app-indexing/ 5. iOS's "Universal Links", "Smart App Banners" and new search API will do much of the same on iOS https://developer.apple.com/videos/wwdc/2015/?id=509 This all points towards a future where the web and proprietary app platforms are so intertwined that users may not even know the difference. The question is how we respond to that. On Firefox OS we have the freedom to define the entire experience, but on the other operating systems we touch we need to accept the reality of the environment that we find ourselves in. My personal conclusion is that we should react to all of the above by pushing back in the other direction by: 1. Helping users discover a web app before they discover its native equivalent, whilst browsing and searching the web 2. Making web content a first class citizen on every OS Firefox touches, with a standalone display mode for Firefox 3. Promoting re-engagement with web content through icons in launchers, offline and push notifications 4. Guiding users to the best of the web through a crowd-sourced, community curated guide The web has some unique advantages over other platforms, but those advantages are being eroded. It's up to us to prove that the web can still compete. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On Thu, Jul 16, 2015 at 4:54 AM, Martin Thomson wrote: > On Wed, Jul 15, 2015 at 4:12 AM, wrote: > > some people believe that web applications should be "installable" > > I don't subscribe to that theory. The web is comprised of pages, not > apps. (I mostly agree with Alex, but not regarding the perceived need > for "app discoverability"; I hear Google has a way to solve that > problem.) > As long as platforms exist with homescreens and other inventories of "installed apps", of which the browser is one, it seems worthwhile to me to support adding Web apps to those inventories so they're peers of native apps instead of having to go through a level of indirection by launching a browser, making them second-class. We can argue that such platforms shouldn't exist, but we also have to work with the reality that they do. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On Wed, Jul 15, 2015 at 4:12 AM, wrote: > some people believe that web applications should be "installable" I don't subscribe to that theory. The web is comprised of pages, not apps. (I mostly agree with Alex, but not regarding the perceived need for "app discoverability"; I hear Google has a way to solve that problem.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On Wed, Jul 15, 2015 at 1:12 PM, wrote: > Do we even agree on the above? I agree with some of it... But, I don't really see the point of trying to merge web and native (other than turning the browser into the OS). And I really don't see the point of trying to play by native's rules when doing so. As long as you talk about web and native as side-by-side, the web will lose since native is controlled by a single vendor. The way we compete is by making the web work better and playing to the strengths of the web. Playing to the strengths of native seems like a losing proposition. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On Wednesday, July 15, 2015 at 3:34:42 PM UTC+10, Anne van Kesteren wrote: > On Wed, Jul 15, 2015 at 12:00 AM, wrote: > > * It's not clear what problems manifest solves > > This is by far the biggest problem. I think we ended up with manifests > because packages have manifests and iOS/Android use packages for > applications, but none of that translates well to the web. Forgot to address this one - why we ended up with manifests is not important if we are starting from scratch. Before we get to "what problems manifest solves", let's go back to vision and where some people, but maybe not all people here, want to take the Web: some people believe that web applications should be "installable"; That it should be possible to install them to the homescreen of a device; that they should integrate with OS permissions and services; that they should be managed in an indistinguishable manner to native applications. And there is a belief that users want this too, presumably because of the popularity of apps stores and apps downloaded from them. This doesn't necessarily mean installing a web application from an applications store - but rather from the URL from where the application is accessed. Do we even agree on the above? Be good to know 'cause I honestly don't know what people want or what vision they have for the Web anymore here. Maybe we should go to just focusing on browser tabs - or building a better webview component? I dunno. Lack of shared vision and agreement makes this and extremely difficult problem to solve in any collaborative manner. Now, Web manifest doesn't solve all "installability" aspects [1]. Its role is in providing the metadata needed to do the following (i.e., "what problems manifest solves" are these): * to help put an icon on the homescreen, and provide a bit more power than . * start up parameters: it tells the runtime what orientation to launch in and lock to before anything is displayed (to avoid a crap experience of changing orientation after the application starts). * display mode: start the app in fullscreen, or with some chrome. * app scope: the URL space to which the manifest applies. * Splash screens: self explanatory. [1] https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On 15 July 2015 at 10:42, Jonas Sicking wrote: > I also think that "display-mode" and "orientation" (and maybe > "theme_color") properties seem to make much less sense given the > current model of manifests. That seems like information that we'd want > to apply during normal browsing too, which means that it's not really > appropriate for the manifest but rather for a tag. > We already have a way for an individual web page to set orientation and theme-color while browsing with page metadata and a JavaScript API. I think the value of having these properties in the manifest is that they can be applied to the URL scope of a whole site rather than just an individual page by applying the manifest to a browsing context to create what the spec calls an "application context", which just means that it already has default metadata applied for a group of web pages. Otherwise you have to wait for each individual page to download to know what display properties to use. This is bad for UX. I don't think the display property is relevant whilst browsing because you are, by definition, in the "browser" display mode. > > I also can't think of a really good use of the "scope" property. I > know it's something we're planning on using in the FirefoxOS pinning > feature, but I'm not convinced that the resulting UI will be > understandable to users. User testing will show. > Yes we are using this for Pin the Web in Firefox OS, and we are putting that UI through user testing, I agree it needs testing. FWIW I think the scope and display properties could be even more important for an implementation in Firefox (on mobile and on desktop), if that was to go ahead. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On 15 July 2015 at 10:42, Jonas Sicking wrote: > But it'd be *really* nice to get rid of features that are there > specifically to migrate users away from the web and to native Android > and iOS apps. If google/apple wants to implement that then that's fine > with me, it's their browsers. I just don't see why that needs to be > sanctioned by a web specification. It'd be nice if the spec took as > hard of a line against native app stores as it did against web app > stores. > I strongly agree with this. I think the related_applications [1] and prefer_related_applications [2] properties have no place in a W3C specification and are potentially very harmful to the web. 1. http://w3c.github.io/manifest/#related_applications-member 2. http://w3c.github.io/manifest/#prefer_related_applications-member ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On Tue, Jul 14, 2015 at 3:00 PM, wrote: > > Some of the things raised: > > * It's not clear what problems manifest solves: do we really want to > replicate "native app" installation behavior on the Web? We don't have a good > history of making this work in various products. > * Extra HTTP request could yield a performance penalty (even if > deprioritized)... though probably not a concern in a HTTP2 world. > * Can't we just use meta tags (application-name, etc.)? > * App-scope is as bad, or worst, than scope in service workers (i.e., you > only get one directory in a domain, or the whole domain). > * How would Desktop firefox make use of display modes? (i.e., how would they > work with tab browsing) The work on manifests started because Alex Russell from Google reached out to me and said that Google was looking at building a "web app" implementation and asked if I had ideas where to start. However the way that manifests ended up getting specified and implemented they aren't really a suitable base for "web apps". I.e. it's not at all the thing that was envisioned when I started talking with Google about manifests. Which is actually totally fine since we in FirefoxOS no longer are working on creating a "web apps" platform. I agree that the manifest spec as it ended up being defined is very equivalent to just a bunch of tags. Which I also pointed out during the spec development [1][2]. However I still feel like the separate manifest file might hold some value. Don't Repeat Yourself still seems valuable. Allowing developers to link to a separate file from everywhere seems likely to lead to less out-of-date information in different files on the website. And avoiding to transfer the metadata when it's not needed by avoiding to download the manifest during normal browsing also seems like a minor win. However with icons being duplicated in both tags and in the manifest, in order to show beautiful icons in the browser tab UI, then we're actually causing developers to have to repeat themselves more, not less. I also think that "display-mode" and "orientation" (and maybe "theme_color") properties seem to make much less sense given the current model of manifests. That seems like information that we'd want to apply during normal browsing too, which means that it's not really appropriate for the manifest but rather for a tag. I also can't think of a really good use of the "scope" property. I know it's something we're planning on using in the FirefoxOS pinning feature, but I'm not convinced that the resulting UI will be understandable to users. User testing will show. All in all I can't say that I'm passionate either way here. The manifest seems pretty equivalent to a bunch of tags to me. And as long as we don't end up having to download it during normal navigation, then it doesn't seem any significantly worse. I.e. I have a hard time rallying for using given that it seems pretty much the same. But it'd be *really* nice to get rid of features that are there specifically to migrate users away from the web and to native Android and iOS apps. If google/apple wants to implement that then that's fine with me, it's their browsers. I just don't see why that needs to be sanctioned by a web specification. It'd be nice if the spec took as hard of a line against native app stores as it did against web app stores. [1] https://github.com/w3c/manifest/issues/272#issuecomment-87495930 [2] https://github.com/w3c/manifest/issues/272#issuecomment-89411351 / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On 14 July 2015 at 23:00, wrote: > A few people have reached out to me with concerns about implementing web > manifest in Gecko and have asked me to restart this thread (given that no > one objected the first time around). There are concerns about the utility > of Web manifests, the overall vision of "appifying" the Web, and their > purpose given that the essentially replicate functionality in > well-established and widely used elements. > I'm disappointed that this feedback is coming now when the web manifest spec forms a key part of our product roadmap [0], rather than a year ago when its implementation was proposed. But happy to discuss. I do understand these concerns and all of the issues raised have been discussed at length before. I'd like to address the individual points raised, as well as the general vision for "appifying the web" which I don't think is necessarily what people might think. > Some of the things raised: > > * It's not clear what problems manifest solves: do we really want to > replicate "native app" installation behavior on the Web? We don't have a > good history of making this work in various products. > This might be what "Open Web Apps" ended up doing, but I don't believe it's what the current W3C manifest for web application spec does. I think we learned a lot about how not to do apps on the web through that process. The W3C spec doesn't support a model where apps can be submitted to and installed from a central app store. It supports a fundamentally more web-like model which puts the browser back at the centre of web app discovery, making web apps something you discover simply by browsing and searching the web, something which works instantly just by navigating to it in any browser, and something which can optionally be bookmarked. Some key differences from what we've had before: * The manifest link relation which associates a web page with a web manifest, making web app metadata crawlable and discoverable by search engines and user agents * The absence of an installation API of any kind * The absence of packages, with all web apps having linkable URLs on the web > * Extra HTTP request could yield a performance penalty (even if > deprioritized)... though probably not a concern in a HTTP2 world. > As Marcos says, I don't see how this is different to any other resource like CSS and JavaScript which are shared between multiple pages and cached in the HTTP cache. Re-downloading the same metadata multiple times in different pages seems less efficient. > * Can't we just use meta tags (application-name, etc.)? > Yes we could, but whilst cramming 12+ more meta tags into the of every page is one solution, it isn't necessarily the best solution. The manifest is shared between multiple pages, can can contain structured data like a map of icons, and is extensible. I think a centrally linked JSON file is a good technical solution to this problem. I would actually recommend that for simple site/app metadata like an application name and icon web developers should use the existing application-name meta tag and icon link relation (we will support this). But for more complex, structured metadata a JSON manifest is a good solution. I would make the same argument for page metadata too. In fact I've started to document this [1] as part of guidance for developers wanting to make the most of features coming in Firefox OS 2.5. > * App-scope is as bad, or worst, than scope in service workers (i.e., you > only get one directory in a domain, or the whole domain). > I would like to understand what is bad about scope in Service Workers, but perhaps that is a separate discussion. We know that the currently defined single scope URL prefix has limitations, and there are multiple research-backed [2] proposals for how to make it more flexible (and complex) if that turns out to be necessary. But scope is absolutely needed and is the source of some of the most frustrating and long standing technical and UX problems in Firefox OS today. It's why you can get stranded on a web page without a back button, it's why the window manager behaves unpredictably when launching content from icons, it's why you can end up with a completely different experience of the same content depending on how you got there. You can clearly see this feedback being surfaced in the foxfood feedback channels, and people are creating hacky solutions to get around it. Scope is essential to register the URL scope to which app metadata applies with the user agent, and to divide a single origin into multiple sites/apps (e.g. google.com/maps vs. google.com/calendar). Without a clearly defined scope it's impossible to tell for any given URL which app name/display mode/orientation/theme-color etc. should apply until the page has been fully downloaded and parsed. This creates all sorts of technical and UX problems. > * How would Desktop firefox make use of display modes? (i.e., how would > they work with tab browsing) > I
Re: Intent to implement W3C Manifest for web application
On Wed, Jul 15, 2015 at 8:15 AM, wrote: > 1. Enhance browser tiles: many sites have nice logos/icons, and they have an > application-name. I want to show the application-name and icon or logo them > in tiles in the new tab page. This seems possible using + . > 2. Page previews suck today: they are mostly broken, don't show the right > content, they are badly zoomed, and don't lead me to the right place. Be nice > if developers could provide a link to a page I can render in a tile + a > "preferred start URL". As a developer, I want this tile to get updated using > a push notification and I want it to work offline. I'm not sure what feature this is, but as Martin said this can probably be easily extracted and retrofitted as and/or features. Similar to Apple's recent proposal. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On Wednesday, July 15, 2015 at 3:34:42 PM UTC+10, Anne van Kesteren wrote: > On Wed, Jul 15, 2015 at 12:00 AM, wrote: > > * It's not clear what problems manifest solves > > This is by far the biggest problem. I think we ended up with manifests > because packages have manifests and iOS/Android use packages for > applications, but none of that translates well to the web. > > > * Extra HTTP request could yield a performance penalty (even if > > deprioritized)... though probably not a concern in a HTTP2 world. > > It's still a concern. You'll still need to duplicate all the metadata > that the client needs immediately in the HTML. We were careful to not have any immediately required metadata in the manifest. The stuff in the manifest is only applied after the web application is installed to a user's device and the application is run from the home screen (see Chrome's implementation). > One reason that was mentioned in favor of manifests was "don't repeat > yourself". The way the web has dealt with that for two decades is > server-side templating. You might be forgetting, you know, and
Re: Intent to implement W3C Manifest for web application
On Wed, Jul 15, 2015 at 12:00 AM, wrote: > * It's not clear what problems manifest solves This is by far the biggest problem. I think we ended up with manifests because packages have manifests and iOS/Android use packages for applications, but none of that translates well to the web. > * Extra HTTP request could yield a performance penalty (even if > deprioritized)... though probably not a concern in a HTTP2 world. It's still a concern. You'll still need to duplicate all the metadata that the client needs immediately in the HTML. One reason that was mentioned in favor of manifests was "don't repeat yourself". The way the web has dealt with that for two decades is server-side templating. If this was really the core concern we should figure out client-side templating for HTML, since this does not just affect document metadata. I agree with Martin that focusing on concrete problems to solve is a more worthwhile endeavor. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
I'd rather see us solve the individual problems that manifests aim to solve using some combination of meta tags, link relations and plain-ol' DOM/JS APIs. The manifest is no better than the former two. It already replicates features that these provide when it comes to icons. In particular, the idea of identifying an "app" in the sense that app-scope implies is a poor fit for the web. There are likely some valuable use cases that can be extracted from this: for instance, I can see the benefit in being able to bookmark "gmail" without identifying whatever message or folder is current visible at the time; or a new site without the title forever reflecting the headline of the day. But again, those are things that can be done without manifests. On Tue, Jul 14, 2015 at 3:00 PM, wrote: > (Please kindly cc me if you want my attention in this thread. I don't > subscribe to mailing lists.) > > On Friday, April 18, 2014 at 7:22:56 AM UTC+10, Marcos Caceres wrote: >> Summary: >> JSON-based manifest, which provides developers with a centralized place to >> put metadata associated with a web application. This includes, but is not >> limited to, the web application's name, links to icons, as well as the >> preferred URL to open when the user launches the web application. The >> manifest also allows developers to declare a default orientation for their >> web application, as well as how the application is to be displayed by the >> user agent (e.g., in fullscreen). >> >> Bug: >> https://bugzilla.mozilla.org/show_bug.cgi?id=997779 >> >> Link: >> http://w3c.github.io/manifest/ >> >> Platform coverage: >> All. >> >> Estimated or target release: >> Q3 or Q4, 2014 > > A few people have reached out to me with concerns about implementing web > manifest in Gecko and have asked me to restart this thread (given that no one > objected the first time around). There are concerns about the utility of Web > manifests, the overall vision of "appifying" the Web, and their purpose given > that the essentially replicate functionality in well-established and widely > used elements. > > Some of the things raised: > > * It's not clear what problems manifest solves: do we really want to > replicate "native app" installation behavior on the Web? We don't have a good > history of making this work in various products. > * Extra HTTP request could yield a performance penalty (even if > deprioritized)... though probably not a concern in a HTTP2 world. > * Can't we just use meta tags (application-name, etc.)? > * App-scope is as bad, or worst, than scope in service workers (i.e., you > only get one directory in a domain, or the whole domain). > * How would Desktop firefox make use of display modes? (i.e., how would they > work with tab browsing) > > Discuss! But please cc me, or else I might not read it :) > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
(Please kindly cc me if you want my attention in this thread. I don't subscribe to mailing lists.) On Friday, April 18, 2014 at 7:22:56 AM UTC+10, Marcos Caceres wrote: > Summary: > JSON-based manifest, which provides developers with a centralized place to > put metadata associated with a web application. This includes, but is not > limited to, the web application's name, links to icons, as well as the > preferred URL to open when the user launches the web application. The > manifest also allows developers to declare a default orientation for their > web application, as well as how the application is to be displayed by the > user agent (e.g., in fullscreen). > > Bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=997779 > > Link: > http://w3c.github.io/manifest/ > > Platform coverage: > All. > > Estimated or target release: > Q3 or Q4, 2014 A few people have reached out to me with concerns about implementing web manifest in Gecko and have asked me to restart this thread (given that no one objected the first time around). There are concerns about the utility of Web manifests, the overall vision of "appifying" the Web, and their purpose given that the essentially replicate functionality in well-established and widely used elements. Some of the things raised: * It's not clear what problems manifest solves: do we really want to replicate "native app" installation behavior on the Web? We don't have a good history of making this work in various products. * Extra HTTP request could yield a performance penalty (even if deprioritized)... though probably not a concern in a HTTP2 world. * Can't we just use meta tags (application-name, etc.)? * App-scope is as bad, or worst, than scope in service workers (i.e., you only get one directory in a domain, or the whole domain). * How would Desktop firefox make use of display modes? (i.e., how would they work with tab browsing) Discuss! But please cc me, or else I might not read it :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement W3C Manifest for web application
Summary: JSON-based manifest, which provides developers with a centralized place to put metadata associated with a web application. This includes, but is not limited to, the web application's name, links to icons, as well as the preferred URL to open when the user launches the web application. The manifest also allows developers to declare a default orientation for their web application, as well as how the application is to be displayed by the user agent (e.g., in fullscreen). Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=997779 Link: http://w3c.github.io/manifest/ Platform coverage: All. Estimated or target release: Q3 or Q4, 2014 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
