- From: Marcos Caceres <marcos@marcosc.com>
- Date: Mon, 18 May 2020 13:35:18 +1000
- To: public-webapps <public-webapps@w3.org>
- Cc: Matt Giuca <mgiuca@google.com>, Jay Harris <harrisjay@google.com>
Hi WebApps WG, I'm happy to announce that we have sufficient implementer interest (Google + Mozilla) to adopt the Badging API from the WICG into our Working Group. Spec: https://wicg.github.io/badging/ Detailed explainer, with lots of examples: https://github.com/WICG/badging/blob/master/explainer.md For those of you who don't know about this API: "This specification defines an API allowing web pages and web applications to set a badge on the document, or an application-wide badge, shown in an operating-system-specific place associated with the application (such as the shelf or home screen), for the purpose of notifying the user when the state of the page or application has changed (e.g., when new messages have arrived), without showing a more heavyweight notification." Additional information below, based on the "intent of migrate" template from the WICG... Huge thanks to Matt Giuca and Jay Harris for doing all the hard work over the last year incubating the specification and working with the rest of the community to get it this point. This API will be a valuable addition to the "Progressive Web App" set of capabilities. Hope to see it in many use agents soon! ### Working group decision to adopt In W3C WebApps Charter: https://www.w3.org/2019/05/webapps-charter.html#wicgspecs ### Proposal https://wicg.github.io/badging/ ### Summary An API allowing web applications to set an application-wide badge, shown in an operating-system-specific place associated with the application (such as the shelf or home screen), for the purpose of notifying the user when the state of the application has changed (e.g., when new messages have arrived), without showing a more heavyweight notification. ### Motivation and Use Cases Covered in the explainer: https://github.com/WICG/badging/blob/master/explainer.md. ### Compatibility Risk Limited. Badging serves as progressive enhancement. ### Ongoing technical constraints What technical constraints will be added to user agents implementing this feature? None. Will this feature be supported in all environments (desktop, mobile, tablets, TV, eBooks, automotive, etc.)? A detailed discussion of possible OS that could support this feature is discussed in the Explainer: https://github.com/WICG/badging/blob/master/explainer.md#specific-operating-system-treatment However, not all OS support badging. ### Link to implementation experience and demos If your proposal has implementation experience or demos, please provide links, including common patterns in deployed libraries. Otherwise, indicate if there are none. https://crbug.com/719176 ### Data What data do you have available that indicates that this enhancement will affect many users of the Web? Quantify the fraction of websites that are currently using something similar to this feature. Or, if a new feature, characterize the reason that you expect this to be far reaching. This would be a new feature for Web Applications. However, is convention across popular mobile and desktop OSs - particularly on iOS, MacOS, and some Linux distributions. It is conceivable that OS-integrated web applications could make use of these OS-provided badging capabilities. ### Security and Privacy A web application could (ab)use the badging API to attempt to display badge numbers, in order to trick user to unnecessarily open the application. By launching the application, the user could unintentionally expose private information. Bug: https://github.com/WICG/badging/issues/25 ### Accessibility Outline the implications of your proposal relative to access by everyone regardless of disability. Otherwise, indicate if there are none. None, as this is often left to the OS (which is hopefully accessible). However, if the browser is in the control of presenting the badge, it should be possible to define some accessibility guidelines. ### Internationalization Outline the implications of your proposal when used with different languages, scripts, and cultures. Otherwise, indicate if there are none. The API allows setting `unsigned long long` types. Presumedly, these would then be formatted appropriately based on the user's locale settings. Thanks! Marcos - on behalf of the WebApps WG Chairs and Team.
Received on Monday, 18 May 2020 03:35:42 UTC