Separate API for tab badging vs app badging

[mgiuca]

In the new explainer, we outline a combined API that sets badges at different URL scopes and is expected to appear on either or both the app icon or the tab icon, at the user agent's discretion.

Having drilled down on this, we're now starting to question why these are the same API, because their usage is very different.

Required reading: A Case for Separation section.

Summary:

• We need feature detection specifically for the tab badging capability (i.e., the site needs to know not just if the Badge API is supported, but whether it will show the badge on the document's tab; see Feature Detection). If there was a separate tab badging API, we wouldn't need a special feature detector for this capability.
• Scoping is especially complicated when it's applied to document badging, because of nested scopes, the inadequate string prefix matching, etc. If the tab badge was set dynamically per document, scoping would only apply to app badging. It would still be necessary, but it would be significantly simpler because you only have to think about which apps it applies to, not which pages.

@raymeskhoury @fallaciousreasoning @marcoscaceres

[mgiuca]

@marcoscaceres (from #48)

No strong opinions about separation. I still personally have reservations regarding scope, but will discuss internally. I'm also a bit on the fence about the default scope being the origin. I'd feel more comfortable if scope was just the current document, and then scope could be expanded via options.

If we separated, then scope would only apply to the app (or "handle") badging cases, not individual pages. So it wouldn't make sense for it to apply to the current document, since you would almost never want to badge just one document, but an entire app (which is almost always an entire origin).

I'm very against the default scope being the current document, because then it's easy to accidentally get it wrong: you test the badge API on your main page and it works. But then you have a bug that when you call Badge.set() from any other page in the site, it does nothing.

I'm not entirely sold on .canBadgeDocument(). I think if the Badge API is there, canBadgeDocument is implied... otherwise, the UA shouldn't include the API.

That's true if we separate the APIs out: then the presence of the badge-this-document API implies that the document will be badged. If we keep a single API as currently described in the explainer, then we need a feature detector for the specific case of "will use of the Badge API cause the badge to show up on my document's tab, on or near the favicon" (so that I know whether to fall back to injecting the badge into the favicon image itself).

[alice]

I think it might be more productive to think of this as document-level vs scope-level, which has tab vs app badging as a consequence.

The section in the explainer which outlines examples for document-level badging does a good job of motivating document-level badging in general; once you accept that, you are then in a position where having both document-level and scope-level badging available on the same document with the same UI surface is going to cause conflicts, and document-level badging makes more sense for things which are acting as documents.

Then it's straightforward to argue that you can get scope-like behaviour from document-level badging, since if you have a document open in a desktop browser context it is likely to be updating the actual document, even if you have multiple views on the same server state (e.g. two tabs open to the same Gmail inbox or Slack team).

Conversely, for an installed app or bookmark, there won't necessarily be a document open to badge, or there may be more than one document open but only one UI surface to show a badge on (the dock or homescreen icon), so a scope-level API makes more sense there.

[fallaciousreasoning]

I think we're fairly settled on this approach. Once the changes proposed in #55 land we should be able to close this.

[mgiuca]

Changes landed. The explainer now presents two separate APIs.