Re: [w3c/manifest] Manifest processing should not be a function of document URL (#668)

I'm pleased to see this reopened because this is still my biggest gripe with the Manifest specification. Not being able to install a web app directly from a manifest URL rules out lots of really interesting use cases (e.g. app stores, digital signage, mobile device management) where implementers have no choice but to either go against the specification or jump through strange hoops like generating fake documents or fetching and parsing an HTML document just to find a manifest URL.

To be honest I had thought that the [`id`](https://github.com/w3c/manifest/issues/586) feature landing was the final nail in the coffin for separating manifest processing from document URL. [As I understand it](https://github.com/w3c/manifest/issues/1038#issuecomment-1137051363), the document URL is used in the default value for `id` if no `start_url` is provided.

I hope that you can untangle this in Chromium, because being backwards compatible with Chromium desktop historically using `start_url` as an identifier (and in turn document URL being the default value for `start_url`) has resulted in a huge amount of (IMO) unnecessary complexity in the specification.

If this can't be achieved, I wonder if it's worth considering a version 2.0 of Manifest which breaks backwards compatibility and allows the installation of web apps directly from a manifest URL (e.g. by using manifest URL as a default identifier rather than `start_url`, and possibly even requiring manifest URLs to be same-origin with `start_url`). This could drastically simplify the installation and update mechanisms and open up a lot of additional use cases.

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

Message ID: <w3c/manifest/issues/668/1396846707@github.com>