Separate API for tab badging vs app badging

[mgiuca]

Separate API for tab badging vs app badging

[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.

[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).

[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.