[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 \
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 \
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: \
_______________________________________________
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