W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2014

Re: [whatwg] Notifications and service workers

From: Andrew Wilson <atwilson@google.com>
Date: Mon, 29 Sep 2014 13:55:10 +0200
Message-ID: <CAArhhitLANYi-E4PbDc2U6k--C0RrLgg7g0Fm5HP+isepJ9muA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: WHATWG <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jake Archibald <jaffathecake@gmail.com>, Robert Bīndar <robertbindar@gmail.com>, Peter Beverloo <beverloo@google.com>
On Mon, Sep 29, 2014 at 1:40 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson <atwilson@google.com>
> wrote:
> > I'm sorry, I meant that you can only use the 'data' attribute, if the
> data
> > you want to associate with the notification is structured-cloneable.
> Which
> > precludes lots of interesting stuff, like objects with attached methods,
> > memoized functions, etc.
> >
> > I'm aware that 'data' is structured-cloneable - I'm saying that's not
> > sufficient for many uses.
> But if the data that you want to associate with the notification isn't
> structured clonable, how are you going to make that data survive a
> page reload? Keep in mind that for persistent notifications, the
> notification often outlives the page that created the notification.

OK, I get it - we're talking about different models. I'm talking about the
current Gmail use case, where I don't want notifications to live forever
(in fact, I close them all when you close the main Gmail pane).

I understand that for persistent notifications, the uses are different. And
again, apologies if I missed the context and the idea was to only remove
the close event for persistent notifications - it's the danger of dropping
into the middle of a thread :) Hopefully the plan is to continue enabling
web properties that want to go the Gmail route to continue doing so, and
for those pages, I think a 'close' event is useful.

> It might help to have some concrete examples of what you're trying to do
> here.
> / Jonas
Received on Monday, 29 September 2014 11:55:36 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:23 UTC