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:
> I believe, but I could be wrong, that if there isn't a manifest and no manifest url, the manifest processing algorithm does currently return a manifest with document url as start url, document_url without the filename or query as the scope, and document_url without fragments as the id.

OK, let's walk that through. For an implementation of the [processing the manifest](https://w3c.github.io/manifest/#processing) algorithm:
```typescript
function processManifest(
  documentURL: URL,
  manifestURL: URL
  bodyBytes: Uint8Array,
  client: EnvironmentSettingsObject | null
): ProcessedManifest {
 // Processing the manifest algorithm
}
```

If you tried to "install" the web page https://example.com/foo/bar.html without a manifest or manifest URL:

```typescript
const processedManifest: ProcessedManifest = processManifest(
  `https://example.com/foo/bar.html#baz',
  undefined,
  undefined,
  null
);
```

I would assume that any sensible implementation in a type safe language would immediately throw an exception because manifestURL and bodyBytes are not of the correct type. But let's say the implementation allows this and doesn't assume a manifest URL and body have been fetched from a `<link rel=manifest>` as defined in the HTML specification.

As far as I can tell `processedManifest` would look something like this:
```json
{
  "dir": "auto",
  "start_url": "https://example.com/foo/bar.html#baz",
  "id": "https://example.com/foo/bar.html",
  "scope": "https://example.com/foo/" // Technically the algorithm itself leaves the filename in place, but this is the effective scope
  "display": "browser",
  "icons": [],
  "shortcuts": []
}
```

So with a bit of hand waving about the inputs the algorithm assumes I think you're right, you do end up with a default manifest. But that manifest has no name, no icon and the default browser display mode. So you would essentially have a bookmark with no title or icon that just navigates to that page in the browser.

I doubt that's what the TAG mean when they say "installing websites must be easy", and isn't how existing browsers implement "add to home/add to dock/create shortcut" for a website.

If user agents want to implement a feature which creates an app from a website then that's fine, that's just not something the Web App Manifest specification currently standardises as "installable web apps", or was [originally intended](https://w3c-webmob.github.io/installable-webapps/#requirements) to specify. It's a different use case, and a different set of requirements which require different sources of metadata.

If that is a new requirement for this specification then it could potentially be satisfied by defining fallbacks for key manifest members taken from HTML metadata (`<meta name="application-name">`, `<title>`, `<link rel="icon">`, `<meta name="theme-color">`, `<html lang>`, `<html dir`> etc.) and potentially heuristics (or manual user override) to upgrade the display mode from browser. Alternatively it could be a separate specification that defines how to create an app from a website which isn't an installable web app.

In the meantime I maintain that the phrase "any website is an installable web application" is demonstrably untrue.

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

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