Thanks for the replies. Folding both Dean and Ryosuke's emails into one.
Not speaking for all of WebKit, and definitely not all of Apple, but I think this seems like a good idea.
I'm not sure I get the distinction between app badges and document badges though. I'd also like to see some specification text describing how the browser should ignore multiple set/clear operations executed in rapid succession (e.g. to create a blinking badge) - maybe the limit is one badge operation per minute or something?
Also, given that the main use case for this would be alerting the user to a notification, it seems like it should be able to link it directly to that. This would provide the ability for a push notification to trigger the badge without ever firing up the page context.
I'm not sure what you mean by "link directly to that". We've deliberately specified this as separate to notifications (since you may or may not want the badge to be set without one). If you want to show a notification and a badge at the same time, you can use both APIs together. If you want to have a push notification set the badge when the service worker runs, you can do that (but as has been discussed at length:
https://github.com/WICG/badging/issues/28, you
can't currently set a badge without a notification from a push message).
For the record, we have two concerns raised internally at Apple:
* The integration of this API with push service worker would require running scripts in order to update the badge. This will pose a serious power consumption issue.
This is something we've given some thought to. We (Google) would like to eventually see it possible to set a badge in the background without a notification. But the power consumption and privacy issues are well known, and at this stage, it is not being proposed.
Because all background processes (including non-foreground tabs) are suspend on iOS, this makes this feature pretty much useless. If the user is currently seeing a website, then there is no need for updating the badge since the user is already there. On the other hand, if the user isn't currently seeing the website, then the website' scripts are never gonna run.
I see. So it sounds like this API would be useful but only once combined with a future proposal to let badges be set via push.
* We don’t want every website to start using this API to increase “engagement”.
Do you mean as a way of drawing additional attention to itself? Well, the setAppBadge API can only be used by installed applications, so that doesn't apply to every site the user might visit. And the user agent / OS can provide the user with UI to suppress badges on a per-app basis if an app is too spammy. The setClientBadge API could be used by any website to draw attention, but the user agent should make the badge sufficiently subtle that this is no more abusive than a favicon, which can already be used to show a pseudo-badge.
Since there is not a concept of installed web apps in Safari on macOS, this isn't going to work there.
The setClientBadge API still makes sense on Safari on macOS.
It doesn't because we don't have a concept of installed apps, and we don't want to let any website use this API as that may annoy users.
I just want to be clear about what setClientBadge is for. (And note that nobody has implemented this yet; it's just in the draft spec as proposed by Marcos Caceres from Firefox.)
This has nothing to do with installed apps. It's just about being able to badge the current document's tab, as seen in the first screenshot in the explainer:
This is something that sites can already do (by modifying the page's favicon), but the API gives sites a way to set the badge semantically, which is advantageous because it means the UA can provide a consistent look and feel across all sites, accessibility features can announce badge changes, etc.