- From: Matt Giuca <notifications@github.com>
- Date: Thu, 01 Jul 2021 19:08:54 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/986@github.com>
Spinning up an issue based on these two comments of mine on a PR: [1](https://github.com/WICG/manifest-incubations/pull/10#discussion_r659507885) and [2](https://github.com/WICG/manifest-incubations/pull/10#discussion_r659508929). Context: we copy+pasted these two bits of code from the shortcut handling code for `new_note`, and more specs are doing the same. @phoglenix FYI **Parse an in-scope URL** The following four lines appear in "[process a shortcut](https://www.w3.org/TR/appmanifest/#dfn-process-a-shortcut)": 1. If the type of _urlstring_ is not string, return failure. 2. Let _url_ be the result of [parsing](https://url.spec.whatwg.org/#concept-url-parser) _urlstring_ with _manifest URL_ as the base URL. 3. If _url_ is failure, return failure. 4. If _url_ is not [within scope](https://www.w3.org/TR/appmanifest/#dfn-within-scope-0) of _manifest URL_, return failure. These lines only appear once in the Manifest spec itself. But lots of other draft specs use the exact same logic, for basically every other must-be-in-scope URL in the manifest: share target, file handlers, protocol handlers, new note, etc. Many new features are being proposed that want this concept, so it would be good not to have to copy-paste these four lines into all of those new algorithms. So can this be abstracted out into a function called "parse an in-scope URL"? **Launch a URL** The following two lines appear in "[launching a shortcut](https://www.w3.org/TR/appmanifest/#launching-a-shortcut)": 1. Let _browsing context_ be the result of creating a new [top-level browsing context](https://html.spec.whatwg.org/multipage/browsers.html#top-level-browsing-context). 2. [Navigate](https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate) _browsing context_ to _url_. Again, this only appears once in the spec, but lots of other proposed features (in fact, pretty much the same list as above) want to do the exact same thing. This code is maybe simple enough that it doesn't need to be abstracted. But I suspect that link capturing is going to want to add complexity to the concept of launching a URL, so we should abstract it into an algorithm called "launch a URL" so that we can have a single point of control for that logic. -- 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/986
Received on Friday, 2 July 2021 02:09:06 UTC