On 14 July 2015 at 23:00, <mar...@marcosc.com> 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 <meta> 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 <head> 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 have started discussions with the Firefox Product and UX teams (on desktop and on mobile) to discuss this very topic, and we have some ideas about how this could work. The W3C manifest spec forms a key part of what a group of people from across Mozilla (Firefox OS, Firefox, Marketplace, Content/BizDev) are working on as a proposal for a Mozilla-wide strategy for more webby web apps. You can read some notes on that here [3]. I am excited that we finally have a draft standard for web apps that multiple browser vendors agree on, has already been implemented by Chrome and Opera and is well underway being implemented for Firefox OS and Firefox. I think this, Service Workers and some other emerging web standards together form a compelling vision for how the web can become truly competitive with native app platforms, without losing what makes the web so unique in the first place. I see growing industry momentum [4] around this shared vision and I hope that we can continue to move forward in that direction, with your support. All the Best Ben 0. https://wiki.mozilla.org/FirefoxOS/Pin_the_Web 1. https://wiki.mozilla.org/FirefoxOS/Pin_the_Web/Optimising_Content 2. https://docs.google.com/document/d/1fOsQWOOVuKyqO7cXZoKmxZGQ9FLgLMwmCRw3OEqIKrQ/edit?usp=sharing 3. https://etherpad.mozilla.org/web-app-discovery 4. 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
