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

This was discussed in a call yesterday with @marcoscaceres and @dmurph. The main idea of being able to process a manifest without a document is generally agreed as something we'd like to do, with good use cases behind it. But it's a little messy.

There was disagreement on what to do if there's no `start_url`. @marcoscaceres still likes the idea of it defaulting to the document URL, if there is one. I would prefer if we could move away from considering those apps without a `start_url` to be apps at all.

I think a reasonable compromise is to let the existing behaviour stand, but require `start_url` for new functionality. Concretely, let's continue to allow apps without a `start_url` to be installed from a document, but disallow them from being installed using the new "non-document-based" mechanism. In other words, you either need a document URL or a `start_url`, which means we don't need to answer the question "what if you don't have either a `start_url` or a document URL?".

Before we get to that, we need to refactor the algorithm so it takes URLs instead of HTML objects, so that it's at least theoretically callable without a document URL. That part is uncontroversial so I will get started on it now.

@benfrancis :

> [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.

That's right. I think that, given the "`start_url` defaults to document URL", this is the right call: manifests that are missing a `start_url` essentially generate a different app for every page that you could install it from, therefore each of those apps should have a different ID.

> 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.

I agree that it's created a bunch of unnecessary complexity. If I was designing it from scratch, I'd have made `scope` mandatory (or default to '/' on the same origin as the manifest URL), and make both `start_url` and `id` default to `scope`, and have nothing depend on document URL other than verifying that it's same-origin as `scope`. But for historical reasons, everything is based on `start_url` and that's OK. For developers, it's simple if you just supply an explicit `start_url`, `scope` and `id` - no need to worry what the defaults are if you explicitly supply everything.

> 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

I don't think it's worth breaking backwards compat over this. It's a minor historical quirk that we can work around.

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

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