[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Request for position on Badging API
From: Matt Giuca <mgiuca () chromium ! org>
Date: 2020-02-19 0:02:03
Message-ID: CAHqYdcajpY2qvARRYDU0OO7QmxgJ5bgbY38qbvLzQH5d3-FC8Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks for the replies. Folding both Dean and Ryosuke's emails into one.
On Mon, 17 Feb 2020 at 03:03, Dean Jackson <dino@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@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.
> * 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 <mgiuca@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
>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr">Thanks for the replies. Folding both Dean and \
Ryosuke's emails into one.</div><div dir="ltr"><br></div><div dir="ltr"><div \
dir="ltr" class="gmail_attr">On Mon, 17 Feb 2020 at 03:03, Dean Jackson <<a \
href="mailto:dino@apple.com">dino@apple.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Not \
speaking for all of WebKit, and definitely not all of Apple, but I think this seems \
like a good idea.<div><br></div><div>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?</div></div></blockquote><div><br></div><div>Good \
suggestion. Filed an issue: <a \
href="https://github.com/WICG/badging/issues/68">https://github.com/WICG/badging/issues/68</a></div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>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.<br></div></div></blockquote><div><br></div><div>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: <a \
href="https://github.com/WICG/badging/issues/28">https://github.com/WICG/badging/issues/28</a>, \
you <i>can't</i> currently set a badge without a notification from a push \
message).</div></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Mon, 17 Feb 2020 at 03:49, Ryosuke Niwa <<a \
href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><div><div dir="auto">For the record, we have \
two concerns raised internally at Apple:</div></div><div dir="auto"> * 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.</div></div></blockquote><div><br></div><div>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 <a \
href="https://github.com/WICG/badging/issues/28">https://github.com/WICG/badging/issues/28</a> \
and <a href="https://github.com/WICG/badging/blob/master/explainer.md#background-upda \
tes">https://github.com/WICG/badging/blob/master/explainer.md#background-updates</a>.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div \
dir="auto"> * We don't want every website to start using this API to increase \
"engagement".</div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div \
dir="auto"><br></div><div dir="auto">- R. Niwa</div></div><div><div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 19, 2020 at 16:27 \
Matt Giuca <<a href="mailto:mgiuca@chromium.org" \
target="_blank">mgiuca@chromium.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi WebKit team,<br><br>I have \
previously proposed the Badging API (<a href="https://github.com/WICG/badging" \
target="_blank">https://github.com/WICG/badging</a>) 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.<br><br>Would WebKit / Safari be interested in implementing the API now or in \
the future?<br><br>We are planning to ship in Chromium soon:<br><a \
href="https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ" \
target="_blank">https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ</a><br><br>Regards</div><div \
dir="ltr"><br><br>Matt Giuca<br></div> \
_______________________________________________<br> webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" \
target="_blank">webkit-dev@lists.webkit.org</a><br> <a \
href="https://lists.webkit.org/mailman/listinfo/webkit-dev" rel="noreferrer" \
target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br> \
</blockquote></div></div> </div>-- <br><div dir="ltr">- R. Niwa</div>
</blockquote></div></div>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic