Re: [w3c/manifest] Add scope conflict section about same-origin and nested scopes (PR #1034)

@marcoscaceres commented on this pull request.



> +        <p>
+          It is possible for two web apps to be installed where there are
+          conflicts between the scope. These conflicts come with disadvantages
+          outlined below and they are generally not recommended.
+        </p>

```suggestion
        <p>
          Because scopes are based on URL matching, it is possible for a developer to create
          multiple web applications the same, overlapping, or nested scopes. Doing so creates
          several issues (detailed below), and is thus considered bad practice.
        </p>
```

> +          Nested scopes are strongly not recommended. They have the above
+          complications of same-origin scope, along with the following UX and
+          API problems or inconsistencies among other possible consistencies:

```suggestion
          Further, overlapping, nested, or duplicate scopes can have the following UX and
          API problems or inconsistencies among other possible consistencies:
```

> +          that will affect all apps installed under that origin. Settings like:
+        </p>
+        <ul>
+          <li>Permissions
+          </li>
+          <li>Storage and storage quota
+          </li>
+          <li>User settings (e.g. font size)
+          </li>
+        </ul>
+        <p>
+          Nested scopes are strongly not recommended. They have the above
+          complications of same-origin scope, along with the following UX and
+          API problems or inconsistencies among other possible consistencies:
+        </p>
+        <ul>

I think this is getting into user agent behaviour... and that might be a good thing for us to specify.

The simplest model might be last installed and/or most specific wins. 

> +          <li>Badging API calls will not be able to consistently update the
+          correct web app badge.
+          </li>

This is overly specific (not all UAs) support badging... should be generalised that API calls might fail. 


> +          complications of same-origin scope, along with the following UX and
+          API problems or inconsistencies among other possible consistencies:
+        </p>
+        <ul>
+          <li>Installation prompting may not work for the nested app if the
+          outer app is installed.
+          </li>
+          <li>User-agent UX around launching an app for a browsing context may
+          be inconsistent or not appear.
+          </li>
+          <li>Badging API calls will not be able to consistently update the
+          correct web app badge.
+          </li>
+          <li>Notifications may have incorrect attribution or not appear.
+          </li>
+          <li>Future APIs may not work at all in this configuration.

Hmm... so yeah... we might need to deal with the reality that that overlapping scopes can happen and specify what the AU should actually do. The focus here needs to be on user expectation that things should work. 

In theory, it should be possible to go from most specific scope to least specific.... we might need to look at what Service Workers did here, as, in theory, they have the same problem. 


> @@ -2434,6 +2434,59 @@ <h3>
           </p>
         </aside>
       </section>
+      <section class="informative">
+        <h3>
+          Web Apps with scope conflicts
+        </h3>
+        <p>
+          It is possible for two web apps to be installed where there are
+          conflicts between the scope. These conflicts come with disadvantages
+          outlined below and they are generally not recommended.
+        </p>
+        <ul>
+          <li>The scopes of the two web apps can be on the same origin. Not

We should avoid RFC2119 language in non-normative sections. 

Instead, we should be clear on what the implications are. 

I think this list can go as it's covered by the paragraph suggested above. 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1034#pullrequestreview-970183460
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1034/review/970183460@github.com>