Re: [w3ctag/design-reviews] Note Taking: New Note URL field (#648)

The API actually serves two (closely-related) purposes: it provides a way for an app to be launched to take a note, and it provides a way for an app to declare its capability as a note-taking app. I don't think an event covers either of these two cases quite as well, or it would need to be paired with a manifest field anyway to declare these capabilities (which seems more complex and error-prone).

Launching:
Opening a URL is a natural way to launch a web app from outside the app (the UA or OS), especially as the app may not be running. An event would need to first launch the app (to the Start URL?), or perhaps find an existing app window, then fire the event at it. What if the app wants to customise this behaviour? This sounds like an entire new spec, and indeed it is: [Declarative Link Capturing](https://web.dev/declarative-link-capturing/). I believe an app could use Declarative Link Capturing (specifically "existing-client-event" mode) to achieve the behaviour you mention (and multiple other variations) without complicating this spec.

Declaring Capabilities:
Unlike an event registration, the New Note URL is known as soon as the manifest is parsed, and relatively fixed, so it is clear to the UA when a given app is / isn't self-identifying as a note-taking app.
If new functionality is added to the New Note URL in the future, these could be added with explicit parameters or another URL declared in the manifest, which again acts as a declaration of capabilities. By contrast, an event could be very flexible with a dictionary of parameters passed in, but unless a different event listener is registered, the UA cannot know whether particular parameters are handled (which could be important, eg. take a note with text - you really don't want the extra text parameter to just be dropped).

So I believe the URL declared in the manifest is a better approach. If that sounds reasonable to you I'll update the explainer to mention these points.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/648#issuecomment-900774495