> On Feb 19, 2020, at 4:31 PM, Matt Giuca <mgi...@chromium.org> wrote: > > > > On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa <rn...@webkit.org > <mailto:rn...@webkit.org>> wrote: > > On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca <mgi...@chromium.org > <mailto:mgi...@chromium.org>> wrote: > On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa <rn...@webkit.org > <mailto:rn...@webkit.org>> wrote: > > On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca <mgi...@chromium.org > <mailto: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 > <mailto: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 > <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 > <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 > <mailto: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 > <https://github.com/WICG/badging/issues/28>and > https://github.com/WICG/badging/blob/master/explainer.md#background-updates > <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. > > 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#overview > <https://github.com/WICG/badging/blob/master/explainer.md#overview> > 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.
Does this mean it’s specifically not intended for app icon badging at all? Would that need a whole different API, then, or can this API scale to that use case? - Maciej > > > - R. Niwa > > On Sun, Jan 19, 2020 at 16:27 Matt Giuca <mgi...@chromium.org > <mailto:mgi...@chromium.org>> wrote: > Hi WebKit team, > > I have previously proposed the Badging API (https://github.com/WICG/badging > <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 > > <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 <mailto:webkit-dev@lists.webkit.org> > https://lists.webkit.org/mailman/listinfo/webkit-dev > <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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
