- From: Andrew Wilson <atwilson@google.com>
- Date: Mon, 6 Oct 2014 09:05:00 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- 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 Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking <jonas@sicking.cc> wrote: > > 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. > AFAICT, no - gmail for android doesn't use web notifications. In general the mobile versions of gmail are kind of bare-boned fallbacks in favor of the native apps. I'm not sure that we should pay too much attention to the use case of apps like gmail that want to do lots of hands-on control of their notifications - I think that's pretty much a rare case. I do think it's useful to have some guidelines for how platforms handle notifications, though, just to make sure that some web developer doesn't just test on one platform, and get unexpected behavior on others. So, trying to encourage auto-close behavior (maybe via SHOULD language in the spec) would be good for consistency's sake. Clarifying what should happen when the user clicks on a notification would also be good (should it bring the tab to the foreground? Should it leave it up to the app? Should it provide a default, but allow apps to override it?) - I think all three of these behaviors are currently implemented (or have been in the past) by different UAs.
Received on Monday, 6 October 2014 07:05:27 UTC