Fine-grained notifications support

[foolip]

#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]

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]

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 Add Notifications API #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 Add Notifications API #1678, but override the status. This would block on Override individual BCD keys #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 Allow overlapping BCD keys without creating ambiguity #1173 and Override individual BCD keys #1690 are resolved).

[captainbrosset]

Notifications are very limited right now. Between them not working outside of a service worker on Chrome Android, not working on iOS without first installing the app, and knowing that not all parameters (such as icon) can be used in Safari, it's a very limited feature set that's currently offered to developers.

I think we have a responsibility to tell developers that, yes, notifications is a baseline feature, but (and that's a big one), they only work within specific constraints. We can communicate this by using the feature's name and description for example. But we should also communicate this by adding another, more general, feature that's not baseline.

So, I agree with going for option 1 above, which means defining multiple notification features in this repo, ignoring caniuse.

My 2 cents:

• I believe BCD's way of showing Safari iOS as fully supported is a mistake, so I filed Mark iOS Safari's implementation of Notification partial because it requires the site to be saved to the home screen mdn/browser-compat-data#24705.
  If, in order to get notifications, a user must know how to install an app, and then must actually go through the steps, then notifications aren't really supported in the strict sense of the term.
  In other words, notifications are not fully supported in Safari iOS, they're fully supported in Safari iOS-when-app-is-installed.

• Trying to match caniuse doesn't feel like the right thing to do, but having a baseline feature about notifications in our repo seems logical seeing how long developers have been able to use the API for.

So, I would create multiple features for notifications in web-features:

1. One called something like "Notifications from service workers and installed apps", which would be baseline (low, I think).

   This one would likely need to be manually set to chrome 20, chrome android 42, edge 14, firefox 22, safari 7, safari ios 16.4.
   We'd set it manually because of the partial implementation notes in BCD.
   This one would have a lengthy description that explains that the entry point is in the service worker, and that, on iOS, the site must be installed first.
   Cons: one obvious problem with the hard-coded status is that we need to manually maintain it should anything change. It would be good to have some tooling around this. For example, a GH action which alerts us when any of the data for the BCD keys in that feature change, reminded us to check the hard-coded status.

2. Another, more general, feature that corresponds to notifications as a whole.

   This one would encompass the full desktop and mobile usage of notifications, whether they're triggered from a service worker, or from the app's main thread.
   This feature would therefore not be baseline, which is the reality of things now.
   Over time (probably a very long time), the hope is that this feature would eventually become baseline and would make the previous feature above irrelevant.

[ddbeck]

Ah, OK, I really like this compromise that @captainbrosset has suggested.

One called something like "Notifications from service workers and installed apps", which would be baseline (low, I think).

We could do this, but I expect it'd be a keyless entry, like JPEG XL. If we pinned it to caniuse: notifications and resolved #1880, then we could at least know we're anchored to something.

More sophisticated tooling would be nice, but I'm not sure I want to put a bunch of effort into extremely niche cases. Maybe something simple like, having a last_reviewed field and a GitHub Actions workflow to trigger a review on some interval (semi-annually?) would be enough.

[captainbrosset]

but I expect it'd be a keyless entry, like JPEG XL.

Makes sense to me.

More sophisticated tooling would be nice, but I'm not sure I want to put a bunch of effort into extremely niche cases. Maybe something simple like, having a last_reviewed field and a GitHub Actions workflow to trigger a review on some interval (semi-annually?) would be enough.

Yeah, that would work. Mostly, I just want us to be in a place where we can easily find and review the manual features.

[autonome]

Sounds good, thanks y'all, I'll update the PR to implement as two separate features in this way.

[autonome]

Updated #1678 with this approach.

• I went w/ notifications-apps for the feature key. I thought -pwa might be interesting since these requirements both kinda fall in that category, but I don't know that we've done anything in the PWA area yet wrt features...
• Maybe need a group, but I added comments pointing bidirectionally for now.