- From: Andrew Wilson <atwilson@google.com>
- Date: Mon, 29 Sep 2014 13:55:10 +0200
- 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