Re: [w3c/manifest] [Breaking] "scope" member now defaults to parent of "start_url" (#647)

mgiuca commented on this pull request.



>        </p>
+      <div class="note" data-link-for="WebAppManifest">
+        <p>
+          If the <a>scope</a> member is not present in the manifest, it
+          defaults to the parent path of the <a>start_url</a> member. For
+          example, if <a>start_url</a> is <code>/pages/welcome.html</code>, and
+          <a>scope</a> is missing, the navigation scope will be
+          <code>/pages/</code> on the same origin. If <a>start_url</a> is
+          <code>/pages/</code> (the trailing slash is important!), the
+          navigation scope will be <code>/pages/</code>.

> So basically something like a base path or so. Isn't this defined somewhere?

Yes, in the [URL standard](https://url.spec.whatwg.org/#url-parsing). This section is a non-normative explanation with examples, for readers who want to understand practically what the default scope will be, without going into the URL parsing algorithm (which is practically unreadable).

The real (normative) text is in the ["scope" member](https://pr-preview.s3.amazonaws.com/mgiuca/manifest/pull/647.html#scope-member) section, where the default is defined as "a new URL using "." as input and *start URL* as the *base URL*". That invokes the [URL parser](https://url.spec.whatwg.org/#url-parsing) which then uses the standard resolution algorithm, the same as if you had `<a href=".">` to link to the containing directory of the current page. I did that because I don't think duplicating the resolution algorithm is a good idea, but it's a little arcane, hence the non-normative note.

If you want to explicitly define the logic here, instead of using the existing URL resolution algorithm, you need to:

1. Drop the query and fragment.
2. Drop everything after the last slash in the path.

The algorithm needs to operate on a URL object (not a string), so the path is represented as a list of segments, implicitly slash-separated. You need to be careful that the path ends with a blank segment, to represent a trailing slash. The algorithm would be this:

> 1. Let default be a new URL.
> 2. Set default’s username to start URL's username, default’s password to start URL's password, default’s host to start URL's host, default’s port to start URL's port, default’s path to a copy of start URL's path.
> 3. Remove default’s path’s last item, if any.
> 4. Append the empty string to default's path.

(This is basically a specialization of the URL Parser with *input* hard-coded as ".").

But I would rather not duplicate the existing logic.

(Aside: One of my main gripes about the URL standard is that almost the entire thing is a monolithic token-consume parser for the entire URL, rather than being broken into distinct concepts that you can easily point to, like a "resolve" algorithm which is what we need here. Formally, there is no such thing as a "relative URL" and there is no such thing as "resolution"; it's all just built-in functionality of the URL parser, which makes it hard to reference from outside, as we need to do here.)

-- 
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/647#discussion_r165220612