Re: [webkit-dev] Request for position on Badging API

[Ryosuke Niwa]

On Wed, Feb 19, 2020 at 4:32 PM Matt Giuca  wrote:

>
> On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa  wrote:
>
>>
>> On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca  wrote:
>>
>>> On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa  wrote:
>>>

 On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca  wrote:

> Thanks for the replies. Folding both Dean and Ryosuke's emails into
> one.
>
> On Mon, 17 Feb 2020 at 03:03, Dean Jackson  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  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.
>>
>
> 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'

Re: [webkit-dev] Request for position on Badging API

[Matt Giuca]

There are two separate APIs, one for each use case (set/clearAppBadge and
set/clearClientBadge).

You could have a separate position on each. Firefox has indicated that they
would only implement ClientBadge to begin with, since they don't have
installed apps on desktop. Chrome is only implementing AppBadge to begin
with, since that is our most demanded use case.

On Thu, 20 Feb 2020 at 11:37, Maciej Stachowiak  wrote:

>
>
> On Feb 19, 2020, at 4:35 PM, Maciej Stachowiak  wrote:
>
>
>
> On Feb 19, 2020, at 4:31 PM, Matt Giuca  wrote:
>
>
>
> On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa  wrote:
>
>>
>> On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca  wrote:
>>
>>> On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa  wrote:
>>>

 On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca  wrote:

> Thanks for the replies. Folding both Dean and Ryosuke's emails into
> one.
>
> On Mon, 17 Feb 2020 at 03:03, Dean Jackson  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  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/28and
> 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 setClientBadg

Re: [webkit-dev] Request for position on Badging API

[Maciej Stachowiak]

> On Feb 19, 2020, at 4:35 PM, Maciej Stachowiak  wrote:
> 
> 
> 
>> On Feb 19, 2020, at 4:31 PM, Matt Giuca > > wrote:
>> 
>> 
>> 
>> On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa > > wrote:
>> 
>> On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca > > wrote:
>> On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa > > wrote:
>> 
>> On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca > > wrote:
>> Thanks for the replies. Folding both Dean and Ryosuke's emails into one.
>> 
>> On Mon, 17 Feb 2020 at 03:03, Dean Jackson > > 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 > > 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.
>> 
>> I just want to be clear about what setClientBadge is for. (And note that 
>> nobody has

Re: [webkit-dev] Request for position on Badging API

[Maciej Stachowiak]

> On Feb 19, 2020, at 4:31 PM, Matt Giuca  wrote:
> 
> 
> 
> On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa  > wrote:
> 
> On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca  > wrote:
> On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa  > wrote:
> 
> On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca  > wrote:
> Thanks for the replies. Folding both Dean and Ryosuke's emails into one.
> 
> On Mon, 17 Feb 2020 at 03:03, Dean Jackson  > 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  > 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.
> 
> 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 curr

Re: [webkit-dev] Request for position on Badging API

[Matt Giuca]

On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa  wrote:

>
> On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca  wrote:
>
>> On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa  wrote:
>>
>>>
>>> On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca  wrote:
>>>
 Thanks for the replies. Folding both Dean and Ryosuke's emails into one.

 On Mon, 17 Feb 2020 at 03:03, Dean Jackson  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  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.
>

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
This is something that sites can already do (by modifying the page's
favic

Re: [webkit-dev] Request for position on Badging API

[Ryosuke Niwa]

On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca  wrote:

> On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa  wrote:
>
>>
>> On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca  wrote:
>>
>>> Thanks for the replies. Folding both Dean and Ryosuke's emails into one.
>>>
>>> On Mon, 17 Feb 2020 at 03:03, Dean Jackson  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  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  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
>
>>>

Re: [webkit-dev] Request for position on Badging API

[Matt Giuca]

On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa  wrote:

>
> On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca  wrote:
>
>> Thanks for the replies. Folding both Dean and Ryosuke's emails into one.
>>
>> On Mon, 17 Feb 2020 at 03:03, Dean Jackson  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  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  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
>

Re: [webkit-dev] Request for position on Badging API

[Ryosuke Niwa]

On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca  wrote:

> Thanks for the replies. Folding both Dean and Ryosuke's emails into one.
>
> On Mon, 17 Feb 2020 at 03:03, Dean Jackson  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  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.

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

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

Re: [webkit-dev] Request for position on Badging API

[Matt Giuca]

Thanks for the replies. Folding both Dean and Ryosuke's emails into one.

On Mon, 17 Feb 2020 at 03:03, Dean Jackson  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  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.


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


>
> - R. Niwa
>
> On Sun, Jan 19, 2020 at 16:27 Matt Giuca  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

Re: [webkit-dev] Request for position on Badging API

[Ryosuke Niwa]

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.
 * We don’t want every website to start using this API to increase
“engagement”.

- R. Niwa

On Sun, Jan 19, 2020 at 16:27 Matt Giuca  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

Re: [webkit-dev] Request for position on Badging API

[Dean Jackson]

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?

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.

Dean

> On 19 Jan 2020, at 4:26 pm, Matt Giuca  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



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position on Badging API

[Matt Giuca]

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