Intent to Ship: Badging API (M81)

Matt Giuca

unread,

Jan 9, 2020, 11:54:25 PM1/9/20

to blink-dev, Jay Harris

Contact emails

mgi...@chromium.org, harr...@chromium.org

Explainer

https://github.com/WICG/badging/blob/master/explainer.md

Spec

https://wicg.github.io/badging

TAG review: https://github.com/w3ctag/design-reviews/issues/387

Proposing to ship the API to general availability in Chrome 81.

Summary

Allows websites to set a badge applying to the corresponding installed web application (as defined by the Web App Manifest standard) on the operating system shelf. The badge can optionally show a positive integer over the top of the application icon.

We have not yet implemented the "setClientBadge" part of the spec which sets a badge on the tab strip.

Link to “Intent to Prototype” blink-dev discussion

Most recent Intent to Experiment thread:

https://groups.google.com/a/chromium.org/g/blink-dev/c/TGe5hYfJZU4/m/62pk7vKSBwAJ

Link to Origin Trial feedback summary

https://docs.google.com/document/d/1h8kaA7VwlUijQJUcUdizXhAMymQJk2HNC3NDdEqxksA/edit

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No, because it has to be individually implemented on each host platform, and some do not support badging.

Initially will launch on Windows and macOS.

Linux is not being initially supported. There is no general API (that I know of) for all Linux window managers. Ubuntu has one specifically for its window managers, which we could support in the future.
Android has no API for setting a badge. The Badge UI seen on Android is automatic when an app sends a notification, and is not individually controllable by apps.
Currently having product discussions about whether Chrome OS should support the API or whether it should tie badges to notifications like Android.

Demo link

https://killer-marmot.appspot.com/web/ ("Badging" heading; if available, allows you to set the badge to any value or clear it).

Risks

Interoperability and Compatibility

The usual risk that it fails to become an interoperable part of the web platform if other browsers do not implement it. Risk somewhat mitigated by the fact that the API is trivially feature-detectable and graceful degradation is easy (the badge simply doesn’t appear on platforms where the API is not supported). Not having this API can’t break any functionality that would have been possible without this API.

Edge: No signals (though note that equivalent proprietary API already web-exposed)

Firefox: Public support (albeit for the setClientBadge part of the spec, rather than the app badge, which they have said they won't implement just yet because they don't have PWAs on Desktop and Android doesn't support badging).

Safari: No signals (though Tess from Apple okayed the API design at TPAC, pending certain changes which we made; see https://github.com/WICG/badging/issues/55).

Web / Framework developers: Positive signals (see Origin Trial feedback)

Ergonomics

Will be used alongside manifest / app installation (doesn't work in Chrome unless the app is installed).

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

No, it's quite simple to use, just one method call to set and another to clear.

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

We don't think any libraries are necessary. There are already public blog posts (https://web.dev/badging-api/) which will be updated as we get closer to shipping.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://crbug.com/976146 (plan to migrate from Chromium tests to WPT)

Entry on the feature dashboard

https://www.chromestatus.com/features/6068482055602176

Yoav Weiss

unread,

Jan 10, 2020, 2:55:22 AM1/10/20

to Matt Giuca, blink-dev, Jay Harris

LGTM1

On Fri, Jan 10, 2020 at 5:54 AM Matt Giuca <mgi...@chromium.org> wrote:

Contact emails
mgi...@chromium.org, harr...@chromium.org

Explainer
https://github.com/WICG/badging/blob/master/explainer.md

Spec
https://wicg.github.io/badging

TAG review: https://github.com/w3ctag/design-reviews/issues/387

Proposing to ship the API to general availability in Chrome 81.

Summary
Allows websites to set a badge applying to the corresponding installed web application (as defined by the Web App Manifest standard) on the operating system shelf. The badge can optionally show a positive integer over the top of the application icon.

We have not yet implemented the "setClientBadge" part of the spec which sets a badge on the tab strip.

Link to “Intent to Prototype” blink-dev discussion
Most recent Intent to Experiment thread:
https://groups.google.com/a/chromium.org/g/blink-dev/c/TGe5hYfJZU4/m/62pk7vKSBwAJ

Link to Origin Trial feedback summary
https://docs.google.com/document/d/1h8kaA7VwlUijQJUcUdizXhAMymQJk2HNC3NDdEqxksA/edit

Great feedback document, thanks! :)

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No, because it has to be individually implemented on each host platform, and some do not support badging.

Initially will launch on Windows and macOS.
Linux is not being initially supported. There is no general API (that I know of) for all Linux window managers. Ubuntu has one specifically for its window managers, which we could support in the future.
Android has no API for setting a badge. The Badge UI seen on Android is automatic when an app sends a notification, and is not individually controllable by apps.
Currently having product discussions about whether Chrome OS should support the API or whether it should tie badges to notifications like Android.
Demo link
https://killer-marmot.appspot.com/web/ ("Badging" heading; if available, allows you to set the badge to any value or clear it).

Risks
Interoperability and Compatibility
The usual risk that it fails to become an interoperable part of the web platform if other browsers do not implement it. Risk somewhat mitigated by the fact that the API is trivially feature-detectable and graceful degradation is easy (the badge simply doesn’t appear on platforms where the API is not supported). Not having this API can’t break any functionality that would have been possible without this API.

Edge: No signals (though note that equivalent proprietary API already web-exposed)
Firefox: Public support (albeit for the setClientBadge part of the spec, rather than the app badge, which they have said they won't implement just yet because they don't have PWAs on Desktop and Android doesn't support badging).

Is this the signal you're referring to? It is indeed encouraging to see their support.

Safari: No signals (though Tess from Apple okayed the API design at TPAC, pending certain changes which we made; see https://github.com/WICG/badging/issues/55).

Have we reached out?

Web / Framework developers: Positive signals (see Origin Trial feedback)

Ergonomics
Will be used alongside manifest / app installation (doesn't work in Chrome unless the app is installed).

Activation
Will it be challenging for developers to take advantage of this feature immediately, as-is?
No, it's quite simple to use, just one method call to set and another to clear.
Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?
We don't think any libraries are necessary. There are already public blog posts (https://web.dev/badging-api/) which will be updated as we get closer to shipping.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
https://crbug.com/976146 (plan to migrate from Chromium tests to WPT)

Are you planning to migrate before shipping?

Entry on the feature dashboard
https://www.chromestatus.com/features/6068482055602176

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHqYdcYoeBJwMmUoCUmOi%3Dt%3Dp7KZh4t7-3HdRpn6mgdEnG6SAw%40mail.gmail.com.

Manuel Rego Casasnovas

unread,

Jan 10, 2020, 8:31:58 AM1/10/20

to Matt Giuca, blink-dev, Jay Harris

On 10/01/2020 05:54, Matt Giuca wrote:
> https://wicg.github.io/badging

Any plans to move this out from WICG and make a pull request for HTML spec?

> TAG review: https://github.com/w3ctag/design-reviews/issues/387

Could you explain why it is closed and marked as "Resolution: withdrawn"?
Should we reactive this design review somehow?

Thanks,
Rego

Matt Giuca

unread,

Jan 19, 2020, 7:08:44 PM1/19/20

to Manuel Rego Casasnovas, blink-dev, Jay Harris

Sorry for the late reply,

On Fri, 10 Jan 2020 at 18:55, Yoav Weiss <yo...@yoav.ws> wrote:

LGTM1

Firefox: Public support (albeit for the setClientBadge part of the spec, rather than the app badge, which they have said they won't implement just yet because they don't have PWAs on Desktop and Android doesn't support badging).

Is this the signal you're referring to? It is indeed encouraging to see their support.

Oh, no I had forgotten that discussion. That's a good show of support :)

I was referring to the general fact that Marcos Caceres was working with us on the badging spec.

Safari: No signals (though Tess from Apple okayed the API design at TPAC, pending certain changes which we made; see https://github.com/WICG/badging/issues/55).

Have we reached out?

Web / Framework developers: Positive signals (see Origin Trial feedback)

Ergonomics
Will be used alongside manifest / app installation (doesn't work in Chrome unless the app is installed).

Activation
Will it be challenging for developers to take advantage of this feature immediately, as-is?
No, it's quite simple to use, just one method call to set and another to clear.
Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?
We don't think any libraries are necessary. There are already public blog posts (https://web.dev/badging-api/) which will be updated as we get closer to shipping.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
https://crbug.com/976146 (plan to migrate from Chromium tests to WPT)

Are you planning to migrate before shipping?

It's on my TODO list but I wasn't planning to block on it. It's a fairly big job, since the API includes operating system components that need to be mocked out with WebDriver or some way to allow the test to inspect the state of the badge in the mocked OS UI.

Entry on the feature dashboard
https://www.chromestatus.com/features/6068482055602176

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHqYdcYoeBJwMmUoCUmOi%3Dt%3Dp7KZh4t7-3HdRpn6mgdEnG6SAw%40mail.gmail.com.

On Sat, 11 Jan 2020 at 00:31, Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 10/01/2020 05:54, Matt Giuca wrote:
> https://wicg.github.io/badging

Any plans to move this out from WICG and make a pull request for HTML spec?

I haven't discussed migration plans with anyone. Is HTML the right place for it? It could also belong to its own spec within Web Apps WG.

It's also probably premature to migrate to a standards track, since there is currently only one implementation.

> TAG review: https://github.com/w3ctag/design-reviews/issues/387

Could you explain why it is closed and marked as "Resolution: withdrawn"?
Should we reactive this design review somehow?

It has been reopened. Thanks for prompting.

Thanks,
Rego

Matt Giuca

unread,

Jan 19, 2020, 7:18:35 PM1/19/20

to Manuel Rego Casasnovas, blink-dev, Jay Harris

On Mon, 20 Jan 2020 at 11:08, Matt Giuca <mgi...@chromium.org> wrote:

Sorry for the late reply,

On Fri, 10 Jan 2020 at 18:55, Yoav Weiss <yo...@yoav.ws> wrote:
LGTM1

Firefox: Public support (albeit for the setClientBadge part of the spec, rather than the app badge, which they have said they won't implement just yet because they don't have PWAs on Desktop and Android doesn't support badging).

Is this the signal you're referring to? It is indeed encouraging to see their support.

Oh, no I had forgotten that discussion. That's a good show of support :)

I was referring to the general fact that Marcos Caceres was working with us on the badging spec.

Safari: No signals (though Tess from Apple okayed the API design at TPAC, pending certain changes which we made; see https://github.com/WICG/badging/issues/55).

Have we reached out?

I just sent a mail to webkit-dev about it, which should appear in this list soon:

https://lists.webkit.org/pipermail/webkit-dev/2020-January/date.html

Yoav Weiss

unread,

Jan 20, 2020, 2:33:20 AM1/20/20

to Matt Giuca, Manuel Rego Casasnovas, blink-dev, Jay Harris

On Mon, Jan 20, 2020 at 1:08 AM Matt Giuca <mgi...@chromium.org> wrote:

Sorry for the late reply,

On Fri, 10 Jan 2020 at 18:55, Yoav Weiss <yo...@yoav.ws> wrote:
LGTM1

Firefox: Public support (albeit for the setClientBadge part of the spec, rather than the app badge, which they have said they won't implement just yet because they don't have PWAs on Desktop and Android doesn't support badging).

Is this the signal you're referring to? It is indeed encouraging to see their support.

Oh, no I had forgotten that discussion. That's a good show of support :)

I was referring to the general fact that Marcos Caceres was working with us on the badging spec.

That is not a signal for "public support", unfortunately. Luckily, we also have the official (favorable) position.

Safari: No signals (though Tess from Apple okayed the API design at TPAC, pending certain changes which we made; see https://github.com/WICG/badging/issues/55).

Have we reached out?

Web / Framework developers: Positive signals (see Origin Trial feedback)

Ergonomics
Will be used alongside manifest / app installation (doesn't work in Chrome unless the app is installed).

Activation
Will it be challenging for developers to take advantage of this feature immediately, as-is?
No, it's quite simple to use, just one method call to set and another to clear.
Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?
We don't think any libraries are necessary. There are already public blog posts (https://web.dev/badging-api/) which will be updated as we get closer to shipping.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
https://crbug.com/976146 (plan to migrate from Chromium tests to WPT)

Are you planning to migrate before shipping?

It's on my TODO list but I wasn't planning to block on it. It's a fairly big job, since the API includes operating system components that need to be mocked out with WebDriver or some way to allow the test to inspect the state of the badge in the mocked OS UI.

Can you provide timelines under which this will happen? I agree that blocking on tests is not fun, but I'd like to see true commitment to making those tests available to other implementers before moving forward.

Entry on the feature dashboard
https://www.chromestatus.com/features/6068482055602176

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHqYdcYoeBJwMmUoCUmOi%3Dt%3Dp7KZh4t7-3HdRpn6mgdEnG6SAw%40mail.gmail.com.

On Sat, 11 Jan 2020 at 00:31, Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 10/01/2020 05:54, Matt Giuca wrote:
> https://wicg.github.io/badging

Any plans to move this out from WICG and make a pull request for HTML spec?

I haven't discussed migration plans with anyone. Is HTML the right place for it? It could also belong to its own spec within Web Apps WG.

Agree that HTML is not the immediate candidate here, and WebApps may be interested.

It's also probably premature to migrate to a standards track, since there is currently only one implementation.

That's not necessarily true. As long as the WG is interested in a spec, nothing prevents migration to it.

Might be worthwhile to bring it up with them and see what they say. (But I don't think this should be a blocker here)

> TAG review: https://github.com/w3ctag/design-reviews/issues/387

Could you explain why it is closed and marked as "Resolution: withdrawn"?
Should we reactive this design review somehow?

It has been reopened. Thanks for prompting.

Thanks,
Rego

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHqYdcZeQh%2BSaEekvvtgKgYcD2uaA%2Be_HV_QjQeFhSEK8GqduQ%40mail.gmail.com.

Matt Giuca

unread,

Jan 23, 2020, 1:28:39 AM1/23/20

to Yoav Weiss, Manuel Rego Casasnovas, blink-dev, Jay Harris

I am very unsure of exactly what needs to happen here. (I just sent off an email asking about it, CCing you.) It would be easy to write a manual test like I've done in the past, but it might be now possible to automate it, so I'm trying to find out what needs to be done.

I will try to provide a timeline after I figure out how much work will be involved, and who is going to do it.

Matt Giuca

unread,

Jan 31, 2020, 1:00:46 AM1/31/20

to Yoav Weiss, Manuel Rego Casasnovas, blink-dev, Jay Harris

Hi Yoav and Blink folks,

We had a separate thread to figure out the testing strategy.

The resolution we've come to is that for the time being, we will just test the observable behaviour from the pure web platform; i.e., the presence of the methods, the fact that they fail with expected error types when used incorrectly, and that nothing catastrophic happens when called correctly. But we won't test that a badge is actually shown in the OS because that behaviour is not specified (and in fact a valid implementation may do nothing).

In the future, we may go down the WebDriver route of setting up a mocking framework.

I think a reasonable time frame to move to Web Platform Tests is within the next milestone (6 weeks).

Thanks

Matt

Yoav Weiss

unread,

Feb 4, 2020, 9:27:07 PM2/4/20

to Matt Giuca, Manuel Rego Casasnovas, blink-dev, Jay Harris

SGTM, thanks!

Chris Harrelson

unread,

Feb 4, 2020, 9:27:51 PM2/4/20

to Yoav Weiss, Matt Giuca, Manuel Rego Casasnovas, blink-dev, Jay Harris

Given that, LGTM2!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjp03fp8KV%2BpqkWJ5quNYMhdeEPoN1z_AHn2M%2BXFWQgOQ%40mail.gmail.com.

Rick Byers

unread,

Feb 5, 2020, 5:46:46 PM2/5/20

to Chris Harrelson, Yoav Weiss, Matt Giuca, Manuel Rego Casasnovas, blink-dev, Jay Harris

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8qoqu%2BvjBOTQ5K4WRjmHqQyBectKXkwgeo2zQzQOqb0A%40mail.gmail.com.

Matt Giuca

unread,

Feb 5, 2020, 6:12:12 PM2/5/20

to Rick Byers, Chris Harrelson, Yoav Weiss, Manuel Rego Casasnovas, blink-dev, Jay Harris

Thanks reviewers!

Jay Harris

unread,

Feb 5, 2020, 6:32:02 PM2/5/20

to blink-dev, rby...@chromium.org, chri...@chromium.org, yo...@yoav.ws, re...@igalia.com, harr...@chromium.org

Thanks everyone!

Thanks reviewers!

LGTM3

Given that, LGTM2!

SGTM, thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHqYdcYoeBJwMmUoCUmOi%3Dt%3Dp7KZh4t7-3HdRpn6mgdEnG6SAw%40mail.gmail.com.

On Sat, 11 Jan 2020 at 00:31, Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 10/01/2020 05:54, Matt Giuca wrote:
> https://wicg.github.io/badging

Any plans to move this out from WICG and make a pull request for HTML spec?

I haven't discussed migration plans with anyone. Is HTML the right place for it? It could also belong to its own spec within Web Apps WG.

Agree that HTML is not the immediate candidate here, and WebApps may be interested.

It's also probably premature to migrate to a standards track, since there is currently only one implementation.

That's not necessarily true. As long as the WG is interested in a spec, nothing prevents migration to it.
Might be worthwhile to bring it up with them and see what they say. (But I don't think this should be a blocker here)

> TAG review: https://github.com/w3ctag/design-reviews/issues/387

Could you explain why it is closed and marked as "Resolution: withdrawn"?
Should we reactive this design review somehow?

It has been reopened. Thanks for prompting.

Thanks,
Rego

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHqYdcZeQh%2BSaEekvvtgKgYcD2uaA%2Be_HV_QjQeFhSEK8GqduQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjp03fp8KV%2BpqkWJ5quNYMhdeEPoN1z_AHn2M%2BXFWQgOQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Reply all

Reply to author

Forward