Re: [w3ctag/design-reviews] Badging API (#387)

We're working on integrating this into the explainer, but in the meantime to address some of your specific concerns:

> In particular, was a declarative solution considered?

Yes. However, as badges may be shared across multiple documents, it was decided that this could be kind of confusing (e.g. there is a `<link rel="shortcut icon badge" href="/favicon.ico" badge="99">` in the head of a document, but it is being badged with `7` because another page was loaded afterwards). There is some discussion of this [here](https://github.com/WICG/badging/blob/a622e8b328bea6e9df36aafad1250221ef11ceac/explainer.md#couldnt-this-be-a-declarative-api-so-it-would-work-without-javascript) and [here](https://github.com/WICG/badging/issues/1#issuecomment-485635068).

> We weren't clear on why this proposal only addressed OS-level application badges and not the common pattern of decorating the favicon and/or title to display the same information in a browser tab label.

@mgiuca, @marcoscaceres and I came up with the following direction forward for having an integrated solution for tabs/app badging. We are integrating this into the spec:

1. All badges have a [scope](https://www.w3.org/TR/appmanifest/#navigation-scope).
2. Pages are badged with the most specific badge matching their scope.
3. By default `Badge.set(...)` will be scoped to the current origin.
4. The scope for a badge can be explicitly specified `Badge.set(..., { scope: '/scope/to/badge/' })`.
5. For installed apps, the badge with the most specific scope which encompasses the app's [navigation scope](https://www.w3.org/TR/appmanifest/#navigation-scope) is applied to the the app's OS specific context.

This idea is being discussed  (in more detail, and with examples) [here](https://github.com/WICG/badging/issues/1#issuecomment-511292840). Does this seem like a good direction to you?

> In a mobile app scenario, code may not be guaranteed to run unless the user is actively using the app. How does this API fit in to a mobile PWA use case?

In future, we intend the API to be available from the service worker (e.g. when a push notification occurs). However, there are still some details around privacy and security that need to be fleshed out. There is an (admittedly brief) [section](https://github.com/WICG/badging/blob/master/explainer.md#why-isnt-this-api-available-from-a-service-worker) in the FAQ.

> Given that this is ostensibly "per-app", it seems like having the Badge object hanging off Window might be misleading - it might be better suited to Navigator or Notifications.

As above, the API is now more general and not specific to apps. Also, there was a [poll](https://github.com/WICG/badging/issues/14#issuecomment-445548190) and developers seem to prefer their APIs being accessible off window.
Maybe you can add details to the note about the declarative API?
(I think this way they will have enough context to more forward with the review in their meeting)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/387#issuecomment-511662961