Re: [w3ctag/spec-reviews] Notifications API (#94)

OK, here's my review.  Do bear in mind that I'm a web developer, not a spec author, so may need some hand holding in places, sorry.

## 2.1

> a couple of seconds

I'm unsure whether this is intended to be a required duration of exactly 2 seconds, or a recommendation of an approximate time, the exact duration to be left to the UA implementor.

This section uses *should* where it might be better to use *must*?

## 2.2

> "default"
> This is equivalent to "denied", but the user has made no explicit choice thus far.

Is it confusing to call these states equivalent?  There is a difference in terms of whether the notification will succeed, isn't there?

## 2.5

> Then, in parallel:

The steps in this algo do not seem to be parallelisable to me, but I'm new to reading algorithm specs, so I may not understand the subtleties, apologies.

## 2.7

Is it necessary to have this much difference between the behaviour of persistent and non-persistent notifications?  For example, could the event name be `notificationclick` in both cases?

On a non-persistent notification, does the `click` event bubble?

> Throughout the web platform "activate" is intentionally misnamed as "click".

Isn't this a bit revisionist? If not, why is the misnaming intentional?!

## 2.8

Can you clarify if/why it doesn't make sense for the closure of a non-persistent notification to trigger an event?

## 3.2

Could we make it possible to use the constructor within a service worker?  It seems like unnecessary work to make developers learn two different ways to use notifications.  Or conversely use showNotification in a document context?

I was surprised that simply constructing the notification shows it.  That seems inconsistent with things like `CustomEvent`, which is created and then triggered.

## 3.5.1

Since `Notification` implements `EventTarget` would `not.addEventListener` be a better pattern to show here?

## 3.5.2

Really clear and practical example here, thanks!

## 3.5.3

Is there a timeout or lifetime on tags?  What if I issue a second notification with the same tag after the first notification has been closed?  Would a new notification appear?

## Considering Alex's points:

* Different construct methods in different contexts: I agree, and included that point in my review above.
* Event mode works in SW but not in documents?: I may not have captured this point properly. I couldn't find any problems with the availability of events other than the lack of a close event for non-persistent notifications.
* Growing set of notification types? Icons and action buttons? Multi res images/formats, Large image formats? List of items?: I believe Alex is concerned about scope creep here.  I would have been concerned if each of these represented a fundamentally different notification, but if it is possible to use all these properties together as required, that just adds flexibility to the notification content, which sounds good to me.
* notifications for ringing - more aggressive, need perms?: As Peter noted above, not currently captured - a way to handle real time, urgent state notifications with short (and potentially unpredictable) timeouts for action.
* Line up Requireinteraction flag and background task API - overlap?: I failed to remember what this point was, apologies.  Alex may want to follow up here.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/94#issuecomment-236866812