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

I had a chat with @hober and we agreed on several points about this design:
- The explainer has some good detail, but could also do with:
  - Some more fleshed out use cases - there are some good general cases, but it would be nice to see more specific examples beyond "unread count".
  - Some more worked through code examples - there are some very minimal code examples showing the (minimal) API, but _when_ would that code run?
  - A ["Considered alternatives"](https://github.com/w3ctag/w3ctag.github.io/blob/master/explainers.md#considered-alternatives) section - this gives us a better idea of what the design process was to create this API
    - In particular, was a declarative solution considered?
- 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. 
  - [Issue #1](https://github.com/WICG/badging/issues/1) does discuss this, but we weren't clear on when the distinction between *per-app* and *per-instance* would apply (isn't an installed PWA just a single instance of an app?).
  - In particular, we weren't satisfied by the "make a JS library" advice - we are suffering from a proliferation of JS libraries and it seems like virtually every PWA would want to cover both cases since, after all, by definition a PWA must work both in a browsing context and a standalone context.
-  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?
- 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`.

-- 
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-507895584