Re: Web Notifications to CR: 48-hour Call for Consensus (CR)

Hi all,

Mike wrote:

>> To weigh in on this proposal to transition the specification to CR,
>> please reply to this message before Feb 21st with either an
>> expression of agreement or an expression of disagreement.

Anne replied:

> Given https://github.com/whatwg/notifications/issues/26 and the
> discussion on the WHATWG list to remove several events (which resulted
> in changes to the WHATWG document) it's not clear that this document
> still has wide support from the community.

I'm probably completely failing to understand the github issue you've
linked to. I think it should be easy for a webmail service to let its
users know that they have new mail. That's what this spec does. All you
have to do is "new Notification('You\'ve got mail!');" and you're good.
And hey, that works in multiple shipping browsers today.

Peter Beverloo wrote, in issue 26:

>>> The specification currently defines two types of notifications,
>>> persistent and non-persistent ones, identified by whether they're
>>> associated with a Service Worker or not.

I take it that "persistent" notifications are the ones associated with a
service worker, and "non-persistent" notifications are created directly
in the page?

That is, "persistence" is referring to whether or not the web page
attempting to show a notification is currently open? (If I've gotten
this part wrong, please disregard the rest of this email.)

>>> If we were to design the Notification API today, would we still have
>>> this distinction? I don't think we would.

I don't know if this distinction is interesting.

But yeah, if we were adding notifications to the Web today I would
certainly hope we'd make it easy to use from a currently open web page
without requiring the use of a service worker.

>>> I don't think I have to repeat any of the other arguments that
>>> backed introduction of persistent notifications in the first place.

Adding the ability to generate a notification from a service worker
seems like a reasonable idea. I think it would be a mistake to add it to
this spec at the present time, which would unnecessarily delay getting a
simple, broadly-implemented feature to REC.

>>> A number of pieces of functionality of non-persistent notifications
>>> have been removed recently, notably the show and close events.

What was the rationale for removing them? I'm not personally invested in
either event, and dropping normative requirements often makes it easier
to get things to REC. :) That said, they do seem useful. I don't
remember what was marked at risk when we entered LC, so it might not be
worth the LC-CR looping that removing them would require. Especially
since they're already shipping in browsers.

>>> What about going taking another jump, and deprecating support for
>>> them altogether?

(By "them," Peter is referring to what he calls non-persistent
notifications.) Why would we drop them? The "webmail in an open tab" use
case is compelling. The feature is shipping in browsers.

We shouldn't gate such a simple feature on service workers, which are
far more complicated and much less broadly implemented.


Ted

Received on Friday, 20 February 2015 21:51:38 UTC