- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 3 Oct 2014 19:42:11 -0700
- To: Andrew Wilson <atwilson@google.com>
- Cc: WHAT Working Group <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jake Archibald <jaffathecake@gmail.com>, Robert Bindar <robertbindar@gmail.com>, Peter Beverloo <beverloo@google.com>
On Sep 30, 2014 1:26 AM, "Andrew Wilson" <atwilson@google.com> wrote: >> In any case it sounds like gmail would not notify properly on platforms where notifications do dissappear after a few seconds, which seems problematic, no? > > I think that Chrome doesn't generate a close event in the case that the notification is hidden, but agreed, it's a problem. It's frankly one of the major flaws of the original spec that behavior like this isn't well specified, because it really prevents applications from doing anything particularly sophisticated around notification management, because you can't keep notifications on-screen if the notification platform wants to close them, and you can't easily differentiate between user-close and system-close. I agree. One of the big shortcomings of the current spec is that it leaves UI too undefined. This is particularly problematic given that notifications is all about using UI to get certain types of user attention. The fact that platform conventions, and browser conventions, for notifications vary wildly is indeed a big problem. One possible solutions to this is to go really high level and create an API which caters to the lowest common denominator. Another solution is to go super low level and expose lots of API which is describe and expose platform behavior in detail, and then ask application code to write logic to deal with the differences. Another thing we could do here is to simply not address this use case. Does gmail for android do the same thing? I wasn't able to reproduce it though I might have done something wrong. / Jonas
Received on Saturday, 4 October 2014 02:43:07 UTC