On Tue, Jul 14, 2015 at 3:00 PM, <mar...@marcosc.com> 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 <meta> 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 <meta> 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 <meta> 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 <meta> 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 <meta> 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
