Update Spec to Match Explainer

[fallaciousreasoning]

The explainer is being updated with our feedback from TAG in #39. The spec should be updated in a separate PR:

When this is done
#1 can be closed (now all badges must specify scope).
#5 can be closed (same reason)
#12 can be closed (badging of installed apps is implicit, based on scope).
#35 can be closed (same as above).

[marcoscaceres]

For tabs, I'd still like to see if we can do this without scope.

[mgiuca]

For tabs, I'd still like to see if we can do this without scope.

Well you can do a badge without a scope (and that sets the scope to some reasonable default).

The default could be the current page, which means every page needs to set the badge individually, and app badging won't work by default unless the current page is the app scope. However, I think that creates more "surprising" situations (e.g., Badge.set() without scope works as expected, except when you're not on the root page of the site). I think origin is the more sensible default because sites are more likely to want to set a site-wide badge than a per-page badge, and that would be setting both the per-app and per-tab badges in a single API call.

Either way, tab badging will work automatically without having to explicitly pass a scope.

[marcoscaceres]

Well you can do a badge without a scope (and that sets the scope to some reasonable default).

Understood, but that's from a developers perspective.

The default could be the current page, which means every page needs to set the badge individually, and app badging won't work by default unless the current page is the app scope. However, I think that creates more "surprising" situations.

If they are analogous to a favicon, then I don't think it would be surprising. Each page has to set its own favicon - there is no expectation that a favicon is persisted when the user navigates.

(e.g., Badge.set() without scope works as expected, except when you're not on the root page of the site). I think origin is the more sensible default because sites are more likely to want to set a site-wide badge than a per-page badge, and that would be setting both the per-app and per-tab badges in a single API call.

I could be sold on applying badges on a per-origin basis (without individual scopes): That could tie nicely into the origin permission model (with an implicit grant), and then a user could easily turn off badging for a whole origin if it got too annoying.

[fallaciousreasoning]

If they are analogous to a favicon, then I don't think it would be surprising. Each page has to set its own favicon - there is no expectation that a favicon is persisted when the user navigates.

I think the difference here is that we want to be able to apply badges to a set of pages (as in the case of an app). In the current system, if we defaulted to a 'page' scope, calling Badge.set() on /page would affect /page/1 and /page/2 while Badge.set() on /page/3 would only affect that page. This seems less predictable to me than badging / by default.

A purely per-document model doesn't solve our app badging problem. I think there was some similar discussion in this thread.

I could be sold on applying badges on a per-origin basis (without individual scopes): That could tie nicely into the origin permission model (with an implicit grant), and then a user could easily turn off badging for a whole origin if it got too annoying.

I agree this would be nice, but the app manifest spec explicitly allows multiple apps to exist on a single origin. As the spec allows this I think we should make sure that the API (whatever it ends up looking like) supports this use case.

Related threads:

• Scope of badging #5
• Talk a bit more about app vs. tab? #1