[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: Maciej Stachowiak <mjs () apple ! com>
Date: 2020-02-20 0:35:01
Message-ID: 934D8F9E-3810-419B-9C13-5808CAE76D40 () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Feb 19, 2020, at 4:31 PM, Matt Giuca <mgiuca@chromium.org> wrote:
>
>
>
> On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa <rniwa@webkit.org \
> <mailto:rniwa@webkit.org>> wrote:
> On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca <mgiuca@chromium.org \
> <mailto:mgiuca@chromium.org>> wrote: On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa \
> <rniwa@webkit.org <mailto:rniwa@webkit.org>> wrote:
> On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca <mgiuca@chromium.org \
> <mailto:mgiuca@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@apple.com <mailto: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 \
> <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 \
> <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 \
> <mailto: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 \
> <https://github.com/WICG/badging/issues/28>and \
> https://github.com/WICG/badging/blob/master/explainer.md#background-updates \
> <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 \
> <https://github.com/WICG/badging/blob/master/explainer.md#overview> This is \
> something that sites can already do (by modifying the page's favicon), but the API \
> gives sites a way to set the badge semantically, which is advantageous because it \
> means the UA can provide a consistent look and feel across all sites, accessibility \
> features can announce badge changes, etc.
Does this mean it's specifically not intended for app icon badging at all? Would that \
need a whole different API, then, or can this API scale to that use case?
- Maciej
>
>
> - R. Niwa
>
> On Sun, Jan 19, 2020 at 16:27 Matt Giuca <mgiuca@chromium.org \
> <mailto:mgiuca@chromium.org>> wrote: Hi WebKit team,
>
> I have previously proposed the Badging API (https://github.com/WICG/badging \
> <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 \
> <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 <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev \
> <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
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On Feb 19, 2020, at 4:31 PM, Matt Giuca <<a \
href="mailto:mgiuca@chromium.org" class="">mgiuca@chromium.org</a>> \
wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" \
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; \
font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: \
normal; text-align: start; text-indent: 0px; text-transform: none; white-space: \
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" \
class=""><br class="Apple-interchange-newline"><br class=""><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 20 Feb 2020 at 11:18, \
Ryosuke Niwa <<a href="mailto:rniwa@webkit.org" class="">rniwa@webkit.org</a>> \
wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px \
0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, \
204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div dir="ltr" class=""><br \
class=""></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb \
19, 2020 at 3:29 PM Matt Giuca <<a href="mailto:mgiuca@chromium.org" \
target="_blank" class="">mgiuca@chromium.org</a>> wrote:<br \
class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, \
204); padding-left: 1ex;"><div dir="ltr" class=""><div dir="ltr" class="">On Wed, 19 \
Feb 2020 at 18:14, Ryosuke Niwa <<a href="mailto:rniwa@webkit.org" target="_blank" \
class="">rniwa@webkit.org</a>> wrote:<br class=""></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, \
204); padding-left: 1ex;"><div dir="ltr" class=""><div dir="ltr" class=""><br \
class=""></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb \
18, 2020 at 4:02 PM Matt Giuca <<a href="mailto:mgiuca@chromium.org" \
target="_blank" class="">mgiuca@chromium.org</a>> wrote:<br \
class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, \
204); padding-left: 1ex;"><div dir="ltr" class=""><div dir="ltr" class="">Thanks for \
the replies. Folding both Dean and Ryosuke's emails into one.</div><div dir="ltr" \
class=""><br class=""></div><div dir="ltr" class=""><div dir="ltr" \
class="gmail_attr">On Mon, 17 Feb 2020 at 03:03, Dean Jackson <<a \
href="mailto:dino@apple.com" target="_blank" class="">dino@apple.com</a>> \
wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px \
0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, \
204, 204); padding-left: 1ex;"><div class="">Not speaking for all of WebKit, and \
definitely not all of Apple, but I think this seems like a good idea.<div \
class=""><br class=""></div><div class="">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 class=""><br \
class=""></div><div class="">Good suggestion. Filed an issue: <a \
href="https://github.com/WICG/badging/issues/68" target="_blank" \
class="">https://github.com/WICG/badging/issues/68</a></div><div class=""><br \
class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, \
204); padding-left: 1ex;"><div class=""><div class="">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 \
class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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" target="_blank" \
class="">https://github.com/WICG/badging/issues/28</a>, you<span \
class="Apple-converted-space"> </span><i class="">can't</i> currently set a \
badge without a notification from a push message).</div></div><br class=""><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" target="_blank" \
class="">rniwa@webkit.org</a>> wrote:<br class=""></div><blockquote \
class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; \
border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: \
1ex;"><div class=""><div class=""><div dir="auto" class="">For the record, we have \
two concerns raised internally at Apple:</div></div><div dir="auto" class=""> * \
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 class=""><br class=""></div><div class="">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" target="_blank" \
class="">https://github.com/WICG/badging/issues/28</a>and <a \
href="https://github.com/WICG/badging/blob/master/explainer.md#background-updates" \
target="_blank" class="">https://github.com/WICG/badging/blob/master/explainer.md#background-updates</a>.</div><div \
class=""><br class=""></div><div class="">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><div class=""><br class=""></div><div \
class="">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.</div></div></div></blockquote><div class=""><br \
class=""></div><div class="">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.</div><div \
class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px \
0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, \
204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_quote"><div \
class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px \
0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: \
rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, \
204); padding-left: 1ex;"><div class=""><div dir="auto" class=""> * We don't \
want every website to start using this API to increase \
"engagement".</div></div></blockquote><div class=""><br class=""></div><div \
class="">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><div \
class=""><br class=""></div><div class="">Since there is not a concept of installed \
web apps in Safari on macOS, this isn't going to work \
there.</div></div></div></blockquote><div class=""><br class=""></div><div \
class="">The setClientBadge API still makes sense on Safari on \
macOS.</div></div></div></blockquote><div class=""><br class=""></div><div \
class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">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.)</div><div class=""><br class=""></div><div class="">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:</div><div \
class=""><a href="https://github.com/WICG/badging/blob/master/explainer.md#overview" \
class="">https://github.com/WICG/badging/blob/master/explainer.md#overview</a><br \
class=""></div><div class="">This is something that sites can already do (by \
modifying the page's favicon), but the API gives sites a way to set the badge \
semantically, which is advantageous because it means the UA can provide a consistent \
look and feel across all sites, accessibility features can announce badge changes, \
etc.</div></div></div></div></blockquote><div><br class=""></div><div>Does this mean \
it's specifically not intended for app icon badging at all? Would that need a whole \
different API, then, or can this API scale to that use case?</div><div><br \
class=""></div><div> - Maciej</div><br class=""><blockquote type="cite" \
class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: \
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; \
font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; \
text-transform: none; white-space: normal; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div \
class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" \
style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; \
border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" \
class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">- R. \
Niwa</div><div class=""><br class=""></div><blockquote class="gmail_quote" \
style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; \
border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" \
class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px \
0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: \
rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, \
204); padding-left: 1ex;"><div dir="ltr" class=""><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; \
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, \
204); padding-left: 1ex;"><div class=""><div class=""><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" \
class="">mgiuca@chromium.org</a>> wrote:<br class=""></div><blockquote \
class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; \
border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: \
1ex;"><div dir="ltr" class="">Hi WebKit team,<br class=""><br class="">I have \
previously proposed the Badging API (<a href="https://github.com/WICG/badging" \
target="_blank" class="">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 class=""><br class="">Would WebKit / Safari be interested in implementing \
the API now or in the future?<br class=""><br class="">We are planning to ship in \
Chromium soon:<br class=""><a \
href="https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ" \
target="_blank" class="">https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ</a><br \
class=""><br class="">Regards</div><div dir="ltr" class=""><br class=""><br \
class="">Matt Giuca<br \
class=""></div>_______________________________________________<br class="">webkit-dev \
mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" target="_blank" \
class="">webkit-dev@lists.webkit.org</a><br class=""><a \
href="https://lists.webkit.org/mailman/listinfo/webkit-dev" rel="noreferrer" \
target="_blank" class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br \
class=""></blockquote></div></div></div>--<span \
class="Apple-converted-space"> </span><br class=""><div dir="ltr" class="">- R. \
Niwa</div></blockquote></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div><span \
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; \
font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: \
normal; text-align: start; text-indent: 0px; text-transform: none; white-space: \
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; \
float: none; display: inline !important;" \
class="">_______________________________________________</span><br \
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; \
font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: \
normal; text-align: start; text-indent: 0px; text-transform: none; white-space: \
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" \
class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: \
12px; font-style: normal; font-variant-caps: normal; font-weight: normal; \
letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; \
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; \
text-decoration: none; float: none; display: inline !important;" class="">webkit-dev \
mailing list</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; \
font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; \
letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; \
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; \
text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: \
_______________________________________________
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