web-platform-dx/web-features

Fine-grained notifications support

Opened this issue · 2 comments

foolip commented

#960 revealed that support for notifications is complicated:

web-features/feature-group-definitions/notifications.yml

Lines 5 to 29 in 85a63e8

# Notifications support is complicated and this entry is unusual. It represents
# some kind of notification support available to web pages. More fine-grained
# features could be added to represent specific things that work.
#
# https://caniuse.com/notifications marks iOS support as partial with this note:
# "Requires website to first be added to the Home Screen."
#
# BCD doesn't use partial_implementation for safari_ios, but has this note:
# "Notifications are supported in web apps saved to the home screen."
#
# We do not have the concept of partial support or notes:
# https://github.com/web-platform-dx/web-features/issues/915
#
# Another complication is the two entry points to this API:
# - new Notification() for non-persistent notifications.
# - showNotification() in service workers for persistent notifications.
#
# Finally, BCD and caniuse.com disagree about whether it was Safari 6 or 7 that
# first supported notifications, and BCD originally agreed with caniuse.com:
# https://github.com/mdn/browser-compat-data/pull/7949
#
# Due to this complexity, manually combine these 3 data points:
# https://developer.mozilla.org/en-US/docs/Web/API/Notification/Notification#browser_compatibility
# https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/showNotification#browser_compatibility
# https://caniuse.com/notifications (excluding partial support on iOS)

Let's sort that out. Perhaps we should define persistent notifications and non-persistent notifications as separate features, but that seems unlikely to be enough.

autonome commented

Some thoughts on feature composition for this:

  • MDN has Chrome Android as "partial" and Safari iOS as "full", with no baseline banner
  • CIU has the reverse, but gives baseline low
  • Neither treat SW as separate from the core Notifications feature

We could break out SW into separate feature as suggested above. But that makes Notifications baseline false, then in conflict w/ CIU and seems like that's against the spirit of Baseline's theory of availability.

Additionally, the bookmark-to-homescreen constraint on Safari iOS seems far more restrictive to availability than Chrome Android's constraint of ServiceWorker.

Given a goal of communicating general availability to developers, I recommend:

  • Keep this as one feature
  • Compute baseline from api.ServiceWorkerRegistration.showNotification to get a value of low

This results in an outcome that is consistent with both MDN and CIU, and aligns with the goal of communicating availability to developers in a reasonable way: The feature is available but may have platform-specific constraints.

Platform variation/constraints likely need a more consistent + programmatically-detectable way of being communicated, perhaps as change in BCD.

ddbeck commented

This one is really gnarly—it took me a while to get my head around it.

Summary

The way this feature is reported on caniuse—using two very different entry points to qualify support for the Notifications API—it's very, very difficult to compute a status that aligns with caniuse, even if we do some reasonable changes in BCD.

I think option 2 (or 1+2), described below, is the way to go—drop caniuse: notifications, define more distinct notifications features, then ask Alexis to consider aligning to one of our features—though I'd feel better about if we talked to Alexis first.

Detailed discussion follows.

The status quo

The status quo is this:

  • notifications has no compat keys. We set a status manually, to match caniuse.
  • The BCD entries conflict with caniuse in ways that make reconciling caniuse and a status computed from compat data impossible:
    • caniuse reports "support" for Notifications through two distinct APIs, depending on the browser: the Notification() (e.g., from desktop Chrome 22) and showNotification() (e.g., for Chrome for Android). But they did not ship together and have rather distinct support histories (e.g., desktop Chrome didn't ship showNotification() until version 42).
    • BCD and caniuse disagree about whether Notification is partially supported on Safari for iOS, due to that OS's requirement for the page to be saved to the home screen. It's also unclear what this even means, in practice. Does Safari not expose Notification on non-saved pages? Throw an error? Silently do nothing?
    • BCD and caniuse disagree about whether it was Safari 6 or 7 that first supported Notification.

Ways to fix this

The way I see it, there are several plausible routes forward.

  1. Break from caniuse. Define Notification-related features (e.g. service worker and non-service worker), disregarding caniuse's version. The downside of this is that we don't get to have a Baseline status on the caniuse feature.

  2. Ask Alexis to change the way he's reporting support for this feature in general, to hinge on the availability of one and only one entry point (e.g., it's all based on the service worker or all based on Notification(), but not both). An alternate version of this is to do option 1, then ask Alexis to align to us. This would probably be in web developers' interest, but change long-standing reportage on caniuse.

  3. Allow a slippage with caniuse. Compute the status as proposed in #1678. If we let that computation stand, we'd report that it is widely available while caniuse's own data says it is partially implemented on iOS. We'd have to either:

    1. Change the BCD so that Notification is partially supported on Safari for iOS, to produce a not Baseline, limited availability status.

    2. Get sign off for reporting a widely available state on something that caniuse clearly shows is not. We'd probably need to talk to Alexis and maybe even the WebDX crew generally before going this route, to make sure this in the spirit of the effort.

  4. Add the keys as proposed in #1678, but override the status. This would block on #1690, since the per-key statuses would create a lot of confusion.

  5. "Yes, and…" with respect to caniuse. Define Notification-related features (e.g., via service workers versus the Notification() constructor), in addition to caniuse's version and don't change the existing feature (at least not until #1173 and #1690 are resolved).