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:
> Can we change the spec to not require a manifest_url?

The presence of a manifest URL is currently quite a fundamental assumption in the specification. It acts as:
1. A base URL for resolving relative members
2. The anchor for navigation scope
3. Part of the cross-origin/trust model (e.g. later processing the manifest without a document, and CSP for image resources)
4. An assumed behaviour for extensions hooking into the processing extension-point

Making it optional would require:
1. Special case resolution of `start_url`, `scope`, `icons[].src`, shortcuts[].src, icons_localized
2. Deciding on what replaces the manifestURL if it is not present. document URL? origin root? about:blank? - meaning the same JSON could be interpreted differently depending on whether it came from a "real" manifest or the "default" manifest.
3. Defining how CORS works, and bi-directional relationship between two origins
4. Special cases for CSP and service workers
5. What extension specs should do if they previously assumed a manifest is a resource with a URL and a MIME type

I'm sure some browser vendors already have answers to these questions because they already support some version of "installing" without a manifest, but the problem is they all do it differently.

Meanwhile, in the [`navigator.install()` API](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebInstall/explainer.md) proposal Microsoft want the _document URL_ to be optional and for relative URLs to be resolved against the manifest URL instead (which causes [another set of problems](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1420)).

Both can't be optional!

@marcoscaceres wrote:
> I guess my mental model has always been that any website is an installable web application.

Yes, you have been very consistent over the last decade+ in that view :) Which I understand is why you pushed for _all_ manifest members to be optional. But to be honest over the years I think that desire has led to a great deal of unnecessary complexity, e.g.
- The convoluted way in which all URLs are resolved
- If id is missing, use start_url
- If start_url is missing, use document URL
- If scope is missing, use start_url
- The difficulties in ensuring a stable identifier for apps and knowing whether one app is the same as another app
- A default browser display mode that essentially renders the rest of the manifest meaningless
- Localised and/or non-localised strings, or none at all
- Complexities in handling updates if some members are missing, or now present, or vice-versa

The optional-everything approach keeps the bar low for authors and backwards compatibility high, but it forces implementations to be relentlessly defensive because anything could be missing, rather than just saying "this is not a valid manifest".

I think at some point in order for manifests to be useable, _something_ has to be mandatory.

---

It actually seems that Apple, Google and (maybe?) Mozilla - but maybe not all other browser vendors - agree with the basic idea that all websites should be "installable" in some way. If that is the consensus then does anyone have a concrete proposal for what a "default manifest" could look like and how that would work? Because that seems to be the missing piece. Given some vendors have already implemented this (Safari on macOS, ChromeOS? Googlebook OS?) I'm assuming you figured out a set of defaults that worked for you.

(Meanwhile, if anyone wants to have a serious chat about what a clean slate Manifest 2.0 could look like based on lessons learnt from 1.0, I would be interested in participating in that discussion! I outlined the key parts of my wishlist above.)

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

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