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)

Following on from the discussion at TPAC today about what would be needed to make the phrase "any website is an installable web application" actually true...

I would suggest this would require fallbacks in the [Processing the manifest](https://w3c.github.io/manifest/#dfn-processing-a-manifest) algorithm for:
1. Manifest URL - [PR #1255](https://github.com/w3c/manifest/pull/1255) proposes using document URL as manifest URL if there isn't one. It also proposes using "an empty byte sequence as `bodyBytes`, and its relevant settings object as client" which makes it possible to execute the algorithm.
3. `display` member - Currently it would default to `browser` which would just open the current page in a browser tab, but [PR #1255](https://github.com/w3c/manifest/pull/1255) suggests the UA could override this display mode to choose something more app-like. I think this part is important, otherwise "installing" a website is basically just a bookmark that opens in a browser tab.
4. `name` member
    1. @marcoscaceres pointed out there is actually already text in [section 4.1](https://w3c.github.io/manifest/#application-s-name) which says that a user agent may fall back to the Document to find suitable replacements for `name` and `short_name` and gives the [`<meta name="application-name">`](https://html.spec.whatwg.org/multipage/semantics.html#meta-application-name) HTML element as an example (which is also localisable via a `lang` attribute BTW). It also suggests that the UA should use a default name like "Untitled" if no name is provided. Should this text be hooked into the [Processing the manifest](https://w3c.github.io/manifest/#processing) algorithm when parsing `name` and `short_name` so that it's not missed?
    2. Should `<title>` also be a potential fallback here, or is it better to use "Untitled" given `<title>` is likely to be specific to an individual page rather than a name for the website as a whole?
4. `icons` - I've noticed that the non-normative sections [1.1.2](https://w3c.github.io/manifest/#using-a-link-element-to-link-to-a-manifest) and [D](https://w3c.github.io/manifest/#relationship-to-html-s-link-and-meta-elements) already allude to the idea that `<link rel="icon">` elements in the Document can be used as fallbacks for icons. Should this be made more formal and hooked into the algorithm for [processing the icons member](https://w3c.github.io/manifest/#dfn-icons)?
5. `scope` - Currently this would default to the current document URL with the fragment and filename removed. That's probably OK, but arguably the root of the origin is a better default because if a user tries to "install" a website from an individual page like a news article or product listing, that page is going to end up being the entire app. This is more of a problem than when there is a `start_url` to fall back on.
6. `id` - This would currently default to the document URL. That would obviously result in a different ID depending on which page of a website the website is installed from, but that is also true of web apps with a manifest but no `start_url`. There is a theoretical edge case where both a website without a manifest and a web app with a manifest could end up with the same `id`, but that's probably unlikely.

I think those are the most important ones, but other potential fallbacks could include:
- `theme_color` -> `<meta name="theme-color">`
- `lang` -> `<html lang>`
- `dir` -> `<html dir>`

Other open questions:
- Localisation - Some of the above fallbacks support localisation, others do not. Should localised versions be used as fallbacks for `*_localized` members if available?
- Should the specification assert which of the above members should be editable by the user?
- Updates - [section D](https://w3c.github.io/manifest/#relationship-to-html-s-link-and-meta-elements) points out why trying to update all the above metadata from meta tags in a document is a bad idea, but if a manifest is not provided should UAs try to periodically check for updates from the document? Usually the trigger for checking for an update is coming across a manifest link relation, so if there isn't one do updates just never happen? Or do they happen every time you visit the document URL you "installed" the website from?
- Are there any additional privacy and security considerations which need to be highlighted when installing a website without a manifest?

Finally, this may just be considered out of scope for now, but it might be worth considering if any of the above breaks if `navigator.install()` initiates a web app installation with a manifest URL but no document URL.

---

This is actually not _quite_ as difficult as I feared because there is already some text in the specification regarding some of the proposed fallbacks, it's just scattered around non-normative sections rather than normatively hooked into the main processing algorithm. There are quite a few normative changes proposed above, and some open questions, but I don't think it's impossible.

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

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