Intent to Implement: Badging API

224 views
Skip to first unread message

Matt Giuca

unread,
Jul 25, 2018, 12:49:58 AM7/25/18
to blink-dev, Ben Wells, estev...@chromium.org

Contact emails

mgi...@chromium.org, benw...@chromium.org


Explainer

Link to explainer. (Note: I have requested to move this explainer repo into WICG.)


Design doc/Spec

None yet.


Summary

Allows web applications (as defined by the Web App Manifest standard) to set an application-wide badge, shown in an operating-system-specific place associated with the application (such as the shelf or home screen). The badge can show a positive integer or a single character over the top of the application icon.


Motivation

Showing a badge for something like a simple status or unread count is a standard feature of desktop and mobile app platforms, which represents missing functionality when developers choose to build an installable web app (PWA) over a native app.


“What are web developers are forced to do without it?”


There is no way to modify the shelf icon in an installed PWA (note: modifying the window’s favicon generally doesn’t affect the shelf icon, which is based on the static icon from the manifest). Developers are forced to build Electron apps instead of PWAs to get this functionality (and we see Electron apps like Slack and Hangouts Chat which could be PWAs if this and other APIs were available on the web).


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.


Potential interoperability improvement, if Microsoft is on board, because currently PWAs accessed through Edge can only achieve this capability using the Windows.UI.Notifications.BadgeNotification API.


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

Firefox: No signals

Safari: No signals

Web developers: Initial positive signals [1] [2] [3]


We’ll be reaching out to other vendors shortly.


Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

Yes, Notifications. An app will often want to send a notification at the same time as a badge, to indicate that new content is available in the app. However, this is separate from Notifications, as it’s also possible for an app to show a badge without a notification (which is like a more subtle type of notification).


Could the default usage of this API make it hard for Chrome to maintain good performance?

No; it will be used infrequently by sites and will have no performance overhead when not being used.


Activation

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

No, it’s simple and easy to hook up to existing apps.


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?

Outreach would help. Polyfills won’t be able to fill the gap because the functionality cannot be achieved without this API being implemented in the browser. It’s unlikely that further abstraction is required. The proposed API is very simple.


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

Yes, eventually. However, it requires individual implementation on each platform, so we would have to move slowly and not launch all at once. See explainer for details on how it would be implemented on each platform.


Link to entry on the feature dashboard

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


Requesting approval to ship?

No.

patrick...@gmail.com

unread,
Jul 25, 2018, 6:18:54 PM7/25/18
to blink-dev, benw...@chromium.org, estev...@chromium.org
small quibble/clarification

though note that equivalent proprietary API already web-exposed

Windows.UI.Notifications.BadgeNotification is only exposed inside of apps using a edge webview (which is how installed PWAs work), they are not exposed on the web as a whole


+1 in general - thanks for writing it up matt!

On Wednesday, July 25, 2018 at 12:49:58 AM UTC-4, Matt Giuca wrote:

Matt Giuca

unread,
Jul 25, 2018, 10:49:42 PM7/25/18
to patrick...@gmail.com, blink-dev, Ben Wells, estev...@chromium.org
On Thu, 26 Jul 2018 at 08:18, <patrick...@gmail.com> wrote:
small quibble/clarification

though note that equivalent proprietary API already web-exposed

Windows.UI.Notifications.BadgeNotification is only exposed inside of apps using a edge webview (which is how installed PWAs work), they are not exposed on the web as a whole

Ah OK, so it is still exposed to pages hosted on the web, but only when both the site and user have opted in via the Microsoft Store.

+1 in general - thanks for writing it up matt!

Thanks! I was told (re WICG) that we should be working with another browser vendor on this spec. I've posted a message to WICG Discourse. Would you be willing to partner with us on working on the standards side, Patrick?
 
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1b0b97d3-ff74-4b88-b350-1aa2381265e9%40chromium.org.

Matt Giuca

unread,
Jul 26, 2018, 7:57:22 PM7/26/18
to patrick...@gmail.com, blink-dev, Ben Wells, estev...@chromium.org
Update: The GitHub repo has been transferred to https://github.com/WICG/badging. (The repo linked above is now my personal fork for pull requests; please file issues under the WICG repo.)

Reply all
Reply to author
Forward
0 new messages