Re: [w3c/manifest] The new definition of "installable web application" is inconsistent with the normative text of the specification (Issue #1168)

benfrancis left a comment (w3c/manifest#1168)

@dmurph wrote:
> How might we square that with still wanting to specify how a given page without a manifest would be installed if the user agent wants to offer that?

Firstly, I don't think it should be possible to "install" a web page that has no application metadata to signal that the author of that page designed or intended it to behave like an application that can be used separately from a web browser. That's just a bookmark. We have no idea what navigation controls it might provide, what a reasonable navigation scope would be, or even what to call it.

But let's work it through with some examples in mind:
- A product listing on an online shop
- A news article
- A blog post
- An encyclopaedia article
- A product landing page
- A questionnaire
- A business listing in a business directory
- A contact us page on a business website
- Terms of Service or Privacy Policy

What would you pick as the name, icon, start URL, scope, display mode and manifest URL?
- `name` - If there is a [meta name="application-name"] tag, I think it would be reasonable to use that. But if not, what do you use? The page title? You would probably have to allow the user to edit or provide their own name.
- `icons` - If there are [link rel=icon] tags it will usually be reasonable to try to choose one of those based on size and type, since they are usually used as static site icons, but there are lots of quirks around how those icons are used like per-page icons or dynamic status indicators which could cause odd results with no obvious way for the user to fix.
- `start_url` - The default `start_url` is the document URL. So now you have a product listing or a news article as your start URL, so again you probably need to user to be able to edit that.
- `scope` - The default `scope` is the `start_url` with filename, query, and fragment removed. So again, if you try to "install" a news article or a privacy policy that page is now the whole web app and navigating outside of that page will kick you out the app. A more sensible default would be the root of the origin, but that was already ruled out after a years-long debate.
- `display` - The default display mode is `browser`, which raises the question of if you're "installing" a web page and it just opens that page in the browser with no difference in browser chrome or perceivable navigation scope, how is that any different to a bookmark anyway?
- manifest URL
  - No URL? How do you process all the members that take manifest URL as an input?
  - Default to the current document URL? Base resolution becomes circular, IDs becomes unstable, updates break, scope and navigation semantics get fuzzy, need I go on?

Defining a default manifest, especially one that uses the current document URL as if it were the manifest URL risks:
- Making "installed apps" exist for sites that never opted in, with unpredictable identify and scope
- Forcing a lot of special-case text into the spec around processing, fetching, CSP, service workers and updates
- Introducing interoperability risk because different UAs will make subtly different choices about how to synthesise missing metadata
- Weakening some of the existing privacy and security expectations, particular around start_url, shortcut URLs and the upgrade flow for security-sensitive members

Putting aside all the practical problems, whilst I understand the instinct of wanting to be able to install genuine web apps which don't provide a manifest, I think the long term impact of treating _any_ website as an installable web app will just be to dilute the perceived value of web apps compared with native apps, because most of them literally will be "just websites". I think that could be really harmful for the future of web apps.

---

> insert pipe dream of "origin.com/.well-known/manifest.webmanifest

Insert my pipe dream of id = manifest URL and default scope and start URL = root of origin. Manifest 2.0...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1168#issuecomment-6166181989
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1168/6166181989@github.com>