Re: [w3c/manifest] Processing the manifest is no longer a function of document URL (#834)

Doing a last-minute re-read. There's a bit of a complication (as usual, because of the unfixable awkwardness that `scope` is based on `start_url` and not the other way around):

1. This PR introduces the possibility that `start_url` of a processed manifest is undefined. (Previously, this was impossible; a missing or invalid `start_url` would default to the document URL. Note that fixing this is the whole point: since there are cases where you don't _have_ a document URL, this was unimplementable.)
2. The "processing the `scope` member" is unchanged by this PR. It assumes _start URL_ is a valid URL.
3. If _start URL_ is missing from these steps, Step 1: _default_ will be **failure** (it is illegal to URL-parse "." without a base).
4. Step 5: "within scope" isn't defined when the URL is undefined. We'll assume it returns false in this case.
5. Any attempt to return _default_ will mean that `scope` of a processed manifest is **failure**.

So if `start_url` is omitted, the manifest processing kinda explodes. The simplest fix for this would be to simply say "if _start URL_ is undefined, `scope` is undefined". That raises a follow-on possibility of what things will do when `scope` is undefined. (For example, "within scope of a manifest" is meaningless when `scope` is undefined due to `start_url` being undefined, though that one's easy to fix by simply making it always false.)

Need to think a bit more about this before landing.

-- 
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/pull/834#issuecomment-652201560