On Feb 19, 2020, at 4:35 PM, Maciej Stachowiak <mjs@apple.com> = wrote:

On Feb 19, 2020, at 4:31 PM, = Matt Giuca <mgiuca@chromium.org> wrote:

On Thu, 20 = Feb 2020 at 11:18, Ryosuke Niwa <rniwa@webkit.org> wrote:

On Wed, Feb = 19, 2020 at 3:29 PM Matt Giuca <mgiuca@chromium.org> wrote:
On Wed, 19 Feb 2020 = at 18:14, Ryosuke Niwa <rniwa@webkit.org> wrote:

On Tue, Feb = 18, 2020 at 4:02 PM Matt Giuca <mgiuca@chromium.org> wrote:
Thanks for the = replies. Folding both Dean and Ryosuke's emails into one.

On Mon, 17 Feb 2020 at = 03:03, Dean Jackson <dino@apple.com> wrote:
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?

Good suggestion. Filed an = issue: https://github.com/WICG/badging/issues/68

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

On Mon, 17 = Feb 2020 at 03:49, Ryosuke Niwa <rniwa@webkit.org> wrote:
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.

That isn't a feature of the current proposal. The spec = doesn't give service worker push any new capabilities that it didn't = already have (in particular, if the browser requires the push message to = show a notification, that is still true; you simply cannot set a badge = from a push message without showing a notification). See https://github.com/WICG/badging/issues/28and https://github.com/WICG/badging/blob/master/explainer.md#backgr= ound-updates.

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=E2=80=99t want = every website to start using this API to increase = =E2=80=9Cengagement=E2=80=9D.

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:
https://github.com/WICG/badging/blob/master/explainer.md#overvi= ew
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.