[webkit-dev] Request for position on Badging API

[Matt Giuca]

On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa <rniwa at webkit.org> wrote:

>
> On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca <mgiuca at 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 at 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 at 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 <mgiuca at 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 at lists.webkit.org
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>
>>> --
>>> - R. Niwa
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200220/96008d37/attachment.htm>