- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 03 Feb 2010 21:15:40 +0100
- To: "John Gregg" <johnnyg@google.com>
- Cc: "Drew Wilson" <atwilson@google.com>, Olli@pettay.fi, public-webapps <public-webapps@w3.org>
On Wed, 03 Feb 2010 21:04:06 +0100, John Gregg <johnnyg@google.com> wrote: > On Wed, Feb 3, 2010 at 11:41 AM, Anne van Kesteren <annevk@opera.com> > wrote: >> If that is the idea createHTMLNotification() should be on a separate >> supplemental interface that user agents on platforms that support HTML >> notifications can implement to make it clear it might not be available >> and that is somewhat separate. (Not sure whether I agree we need HTML >> notifications though, especially for v1.) > > I'd be okay with using a separate interface if it is the more clear way > make something optional in the spec, provided the actual invocation > doesn't > become too cumbersome. > (window.notifications.html.createNotification(url) > vs window.notifications.createNotification(icon,text) maybe?) Sorry, it would just be prose. E.g. [Supplemental] interface NotificationCenter { ... }; See http://dev.w3.org/csswg/cssom-view/#extensions-to-the-document-interface for an example of extensions to the Document interface. > I tried to indicate in the descriptive parts of the spec that > createHTMLNotification could be left undefined if unsupported, so the > goal is the same as what you propose. I suppose that could work too. > As to whether HTML notifications are needed, I think there are many use > cases, even simple ones, in which there is a lot of a benefit to dynamic > behavior. I'm repeating myself from whatwg list, but even a calendar > reminder with a <select> for snooze delay is very useful. My main gripe with it is that they do not integrate with the system notification systems, though that can change of course. -- Anne van Kesteren http://annevankesteren.nl/
Received on Wednesday, 3 February 2010 20:16:21 UTC