[webkit-dev] Request for position on Badging API

[Ryosuke Niwa]

On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca <mgiuca at chromium.org> wrote:

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

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 <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/20200219/0a2b9d23/attachment.htm>