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, <mar...@marcosc.com> 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 <meta> 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
