[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:37:53
Message-ID: 3A0034E1-2A4F-4332-AFE5-67239FF25F51 () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Feb 19, 2020, at 4:35 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>
>
> > On Feb 19, 2020, at 4:31 PM, Matt Giuca <mgiuca@chromium.org \
> > <mailto: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?
I should have read the link. It looks like it's intended for both use \
cases. We were probably only thinking of app icon badging (macOS dock, iOS \
home screen, etc when reviewing the spec).
- Maciej
> - 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 <mailto:webkit-dev@lists.webkit.org>
> > https://lists.webkit.org/mailman/listinfo/webkit-dev \
> > <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> _______________________________________________
> 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>
[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:35 PM, Maciej Stachowiak <<a \
href="mailto:mjs@apple.com" class="">mjs@apple.com</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><div 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=""><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" class="" \
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;"><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 \
class=""><br class=""></div><div class="">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></div></blockquote><div><br class=""></div>I should have \
read the link. It looks like it's intended for both use cases. We were \
probably only thinking of app icon badging (macOS dock, iOS home screen, \
etc when reviewing the spec).</div><div><br class=""></div><div> - \
Maciej<br class=""><div><br class=""></div><br class=""><blockquote \
type="cite" class=""><div class=""><div 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=""> - Maciej</div><br class=""><blockquote \
type="cite" class=""><div class=""><div dir="ltr" class="" \
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;"><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 \
_______________________________________________
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