Re: [whatwg] Notifications and service workers

On Mon, Oct 6, 2014 at 12:05 AM, Andrew Wilson <atwilson@google.com> wrote:
> 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.

Actually, my question was in regards to the "native" gmail app. Not
web content of any sort.

> 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.

I agree with this.

Generally speaking we tend to leave UI up to browsers and avoid
speccing it. However given that notifications is all about UI I think
doing so effectively makes the feature untrustable for authors. We
don't need to define exact pixels etc, but I think we need to define
some semantics in the form of expected behavior of UI.

/ Jonas

Received on Monday, 6 October 2014 07:16:38 UTC