On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa <rn...@webkit.org> wrote: > > On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca <mgi...@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 <d...@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 <rn...@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/28 and >> https://github.com/WICG/badging/blob/master/explainer.md#background-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’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. As such, this feature isn't going to work on either platform as currently > proposed. > > - R. Niwa > > On Sun, Jan 19, 2020 at 16:27 Matt Giuca <mgi...@chromium.org> wrote: >>> >>>> Hi WebKit team, >>>> >>>> I have previously proposed the Badging API ( >>>> https://github.com/WICG/badging) to provide websites with a mechanism >>>> to set a badge (a small dot or number) on the current document's tab, or >>>> for installed applications, on the app icon in the system shelf or home >>>> screen. >>>> >>>> Would WebKit / Safari be interested in implementing the API now or in >>>> the future? >>>> >>>> We are planning to ship in Chromium soon: >>>> >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ >>>> >>>> Regards >>>> >>>> >>>> Matt Giuca >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>> >>> -- >>> - R. Niwa >>> >>
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
