Re: [w3c/manifest] Scope: Allow developer to have more fine-grained control of app scope. (#996)

When URLPattern was defined, we worked with @wanderview to ensure it would be usable in Web App Manifest eventually - that was always the plan. (That's why the URLPattern spec has a section about using it in JSON.)

Acknowledged the difficulty of communicating to the OS the exact scope, but I don't believe this should restrict the way app scope is defined, since the OS interaction (OS-level link capturing) is just a small part of its utility. I think of the scope as being much more about when you're inside the browser/webapp ecosystem, deciding whether a given link should open in the browser or webapp. For most purposes, scope can be fully implemented as a URLPattern.

When it comes to registering the URLPattern with the OS, you could define a subset of the syntax that's designed to work with OS link capturing, but let the full syntax be used for internal navigation. (Though there can't possibly be a guarantee about what URLs can be supported by all possible OSes; that is outside the jurisdiction of a web spec.)

Also note the (intentional) precedence here: in the Manifest Incubations spec we defined the tab mode home scope using URLPattern, with the intention that the main manifest scope would follow. A lot of the hard spec work (and implementation, in chromium) has already been done there and can be generalized. Albeit, tab mode home scope does not need to be registered with the OS.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/996#issuecomment-2431548793
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/996/2431548793@github.com>