On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca <mgi...@chromium.org> wrote:
> 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. > 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. - 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
