- From: Matt Giuca <notifications@github.com>
- Date: Sun, 02 Aug 2020 23:50:02 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/586/667838183@github.com>
Yes that's what we've been thinking of. > unique-per-origin ID that a manifest can set I think the best way (i.e., most consistent with how other manifest keys like this work) to express this is that the ID is a URL that must be same-origin as scope*. This URL is resolved against the manifest URL, like every other URL in the spec. This URL is never requested, it's just used as an identifier. Making it a URL like this and requiring same origin gives it a natural uniqueness per origin. This means if your manifest is on a different origin to your start/scope, you must specify the ID as an absolute URL (same as all the other URLs). And it means if your id is path-relative, moving your manifest would change the ID, so you have to be careful to keep the ID stable when moving the manifest. We would recommend always specifying the ID as path-absolute (e.g., "/my-id"). Another approach is to make it relative to the origin of the scope, so you can just specify the ID as a string and it will do as expected. That would create less confusion for developers, at a cost of being different to how all the other URLs resolve. That's a trade-off we could make. \* Note: I said "same-origin as scope" here, not "within scope" which is more typical. That's to prevent sites from accidentally being locked in and unable to change their scope. For example, if ID was "/foo" and scope was "/", they would be unable to change scope to "/bar" without breaking the ID. Since there is no technical reason for the ID to be within scope (since we never actually navigate to that URL), it can just be same origin. > could match either start_url or manifest url to prevent breaking on one system or another (someone is going to break). Ideally, the default would be scope. Scope is the best identifier of an app at the moment; it's the least likely to change over time and it's usually a containing URL for both start and manifest. That would break both desktop and mobile Chrome's current representation, but since we're going to cause breakage, maybe we should just do it globally? If not scope, I don't have a strong opinion about whether start_url or manifest URL is the best default. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/manifest/issues/586#issuecomment-667838183
Received on Monday, 3 August 2020 06:50:15 UTC