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

Another edge case that changes with this PR: `start_url` is invalid but `scope` is valid and encloses the document URL.

For example, say that you are in a document at `https://example.com/foo/index.html`, with the following valid manifest:

```json
{
  "scope": "https://example.com/"
}
```

**Current spec**:

1. `start_url` defaults to `https://example.com/foo/index.html`.
2. Since `start_url` is within `scope`, `scope` remains as `https://example.com/`.

**Proposed spec**:

1. `start_url` remains undefined.
2. Since `start_url` is invalid, it isn't within scope, so `scope` is undefined.
3. At the top level algorithm, the user agent MAY set `start_url` to `https://example.com/foo/index.html`, and `scope` to `https://example.com/foo/`.

So the new scheme would be changing `scope` where the old scheme allows it to remain as defined. Again, this is probably a good thing, since the old scheme allows `scope` to remain valid or be invalidated, conditional on the document URL, which is what we're trying to fix. But it potentially makes a minor difference to sites that have a `scope` but no `start_url`. In my experience, sites tend not to have `scope` if they have no `start_url` either, so this shouldn't be much of a problem.

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