- 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