- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 8 Oct 2014 10:31:52 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WHATWG <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jake Archibald <jaffathecake@gmail.com>, Andrew Wilson <atwilson@google.com>, Peter Beverloo <beverloo@google.com>
On Wed, Oct 8, 2014 at 7:13 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, Oct 7, 2014 at 7:33 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> I don't know of a use-case for that. And given that I think we should >> define that non-persistent notifications go away after a timeout, I >> think this is the common scenario. >> >> The reason I think we should use timeouts is that this matches all >> OS-native non-persistent notifications that I know of, and also seems >> like a better UX. > > I started to remove the close event and then I noticed we also use it > when a notification gets replaced by a newer one. Do we care about > that? Interesting. Though if we don't need an event for .close() being called, I suspect we won't need one for a notification being replace. It seems somewhat rare that either of these things would provide significant use to the app if the notification is going away soon anyway. Also, BroadcastChannel was created to allow people to handle these types of things themselves if needed. So we're not leaving people without a workaround if for some reason there is a use case here. / Jonas
Received on Wednesday, 8 October 2014 17:32:51 UTC