Re: [Notifications] feedback requested on new Editor's Draft
On Tue, Mar 23, 2010 at 4:53 PM, Ryan Seddon wrote: > On Tue, Mar 23, 2010 at 1:06 PM, John Gregg wrote: > >> After the extensive discussion several weeks ago, I've been working on a >> new draft for Web Notifications which is now available at >> http://dev.w3.org/2006/webapi/WebNotifications/publish/ >> > > Not sure if this has been asked before but what about an optional property > to position it elsewhere beside the bottom left. > > Something like: > > createNotification(in DOMString iconUrl, in DOMString title, in DOMString > body[, in DOMString position]) > > Where it can take 4 possible values: topleft, topright, bottomleft, > bottomright. Bottomright being the default. Do you have a use case in mind for this? Perhaps there is one on a particular device, but for most of the browser/desktop use cases I think it is preferable to leave it up to the user agent or the underlying notification platform to decide where to put the notifications (probably based on user preferences). > > > > Should we really put another interface on the global object? Can we not >> put these on window.navigator like other APIs that integrate with the system >> layer? >> > > I also agree that it would make sense to add it to navigator. > Sounds like there is consensus on that. I will move it there. -John
Re: [Notifications] feedback requested on new Editor's Draft
On Tue, Mar 23, 2010 at 1:06 PM, John Gregg wrote: > After the extensive discussion several weeks ago, I've been working on a > new draft for Web Notifications which is now available at > http://dev.w3.org/2006/webapi/WebNotifications/publish/ > Not sure if this has been asked before but what about an optional property to position it elsewhere beside the bottom left. Something like: createNotification(in DOMString iconUrl, in DOMString title, in DOMString body[, in DOMString position]) Where it can take 4 possible values: topleft, topright, bottomleft, bottomright. Bottomright being the default. > Should we really put another interface on the global object? Can we not > put these on window.navigator like other APIs that integrate with the system > layer? > I also agree that it would make sense to add it to navigator. --Ryan
Re: [Notifications] feedback requested on new Editor's Draft
This looks good. One thing which I suggested previously but which didn't make it into the spec is the ability for the UA to eliminate duplicate notifications. Since I've been using the existing experimental notifications API in Chrome, I've found that duplicate notifications are very common and quite irritating to the user, and there's no good way for applications to do duplicate elimination themselves (they could route notifications through a SharedWorker, but there's no good way for the SharedWorker to route click events back to the parent windows in such a way that they appear to be user gestures, so you wouldn't be able to satisfy the "Go To Inbox" use case described in the spec). A few notes on the spec itself: Section 4: - The definition of the onclose attribute is incorrect, and should read "An event listener function corresponding to the event type '*close*'", not 'error'. Section 5: - (parroting Anne's comment): It's somewhat ambiguous how the iconUrl parameter in createNotification() is processed - I'm wondering about how UAs should handle cases like HTTP auth while trying to access that resource (should they display the notification without an icon? fail the notification?). Likewise, I'm curious about how a UA should treat a non-secure iconUrl being generated from script within a secure page, although perhaps that's outside the bounds of the spec. - I'm wondering if the documentation for requestPermission() should read: "If the current permission level is permission_denied, the user agent *must* take no action..." (rather than "may take no action"). - Is the intent of the spec that an Exception is thrown if the user calls requestPermission() when the permission is already PERMISSION_ALLOWED? Section 6: - I don't understand the need for the optional mime parameter to createWebNotification(). What use case is it satisfying, that the normal resource fetching/mime-type inference mechanisms don't satisfy (i.e. +1 to Anne's comment) Section 8: - Should passing an unsupported type of web content to createWebNotification() generate an error event? - The "display" event is generated when the notification is passed along to the underlying notification platform - technically, since the underlying platform can also do its own queueing, it's possible that the display event is generated before the notification itself is displayed. Should this be mentioned in the spec? Section 9: - Is there any use case where an application needs to know that the system has closed the notification without user input? Currently a close event is only generated if the user explicitly dismisses a notification. -atw On Tue, Mar 23, 2010 at 3:54 AM, Robin Berjon wrote: > On Mar 23, 2010, at 11:33 , Anne van Kesteren wrote: > > Currently there are no processing requirements for the mime argument of > createWebNotification(), do we really need it? > > Do we have use cases for content other than HTML or SVG? Presumably those > can "just work". > > > Should we really put another interface on the global object? Can we not > put these on window.navigator like other APIs that integrate with the system > layer? > > +1, navigator is the new window :) > > -- > Robin Berjon - http://berjon.com/ > > > > >
Re: [Notifications] feedback requested on new Editor's Draft
On Mar 23, 2010, at 11:33 , Anne van Kesteren wrote: > Currently there are no processing requirements for the mime argument of > createWebNotification(), do we really need it? Do we have use cases for content other than HTML or SVG? Presumably those can "just work". > Should we really put another interface on the global object? Can we not put > these on window.navigator like other APIs that integrate with the system > layer? +1, navigator is the new window :) -- Robin Berjon - http://berjon.com/
Re: [Notifications] feedback requested on new Editor's Draft
On Tue, 23 Mar 2010 03:06:45 +0100, John Gregg wrote: After the extensive discussion several weeks ago, I've been working on a new draft for Web Notifications which is now available at http://dev.w3.org/2006/webapi/WebNotifications/publish/ The Web IDL should be cleaned up: * There is no such thing as DOMWindow * Supplemental interfaces should use [Supplemental] The methods should raise some kind of exception when there is something wrong with the URL argument. See e.g. the open() method description in XMLHttpRequest. It would be nice if fetching of resources was described in terms of the fetch algorithm from HTML5. Currently there are no processing requirements for the mime argument of createWebNotification(), do we really need it? Queuing should be defined in terms of the HTML5 event loop. Should we really put another interface on the global object? Can we not put these on window.navigator like other APIs that integrate with the system layer? -- Anne van Kesteren http://annevankesteren.nl/
[Notifications] feedback requested on new Editor's Draft
After the extensive discussion several weeks ago, I've been working on a new draft for Web Notifications which is now available at http://dev.w3.org/2006/webapi/WebNotifications/publish/ The most substantial changes are: - Add requirements section. This is derived from the wiki page which Doug Schepers started, but I think it should live inside the spec. It's clear that there is interest in implementing the spec using Growl and other such platform APIs, so I've made it explicit that the spec is required to allow that implementation. At the same time, to achieve platform/device independence and look to the future of more sophisticated notifications, it isn't specified as the only way notifications can be implemented. - Rename "HTMLNotification" to "WebNotification" to allow other types of content (e.g. SVG as was in the feedback) and move this to a supplemental interface. - Add a definitions section so that terminology is clear. I look forward to seeing additional feedback. Thanks, -John
