Re: [Notifications] feedback requested on new Editor's Draft
On Tue, Mar 23, 2010 at 4:53 PM, Ryan Seddon seddon.r...@gmail.com wrote: On Tue, Mar 23, 2010 at 1:06 PM, John Gregg john...@google.com 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, 23 Mar 2010 03:06:45 +0100, John Gregg john...@google.com 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/
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 ro...@berjon.com 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 Tue, Mar 23, 2010 at 1:06 PM, John Gregg john...@google.com 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
On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 10, 2010, at 20:35, John Gregg wrote: I agree that this is a good distinction, but I think even considering ambient notifications there is a question of how much interaction should be supported. NotifyOSD, for example, does not allow the user to take any action in response to a notification. Being able to acknowledge an ambient notification could be an optional feature that isn't supported on Ubuntu as long as NotifyOSD doesn't support acknowledging notifications. (If it's a problem to make acknowledgement optional, I think making HTML notification optional is going to be a bigger problem...) FWIW, Microsoft explicitly says notifications must be ignorable and don't persist. Notifications aren't modal and don't require user interaction, so users can freely ignore them. In Windows Vista® and later, notifications are displayed for a fixed duration of 9 seconds. http://msdn.microsoft.com/en-us/library/aa511497.aspx As such, it's always unsafe to design UI in a way that expects the users to be able to acknowledge a given notification. FWIW, the mentioned document is full of examples of Notifications that have text like Click here to ... on them. So Microsoft apparently differentiates between requires user dismissal and can be clicked for furhter action. Also, the absence of any hints that their notifications are actually clickable makes them have this text everywhere, which is unfortunate, IMO. Dmitry
Re: Notifications
Hi, Folks- We should put together a use case and requirements document (or section of the spec) to scope out this work. I know it seems like makework, but it can help resolve many issues later on, and serve as a measure of the maturity and success of the spec in meeting its goals. I've started a simple wiki page to kick this off: http://www.w3.org/2008/webapps/wiki/Web_Notifications Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Drew Wilson wrote (on 2/23/10 5:26 PM): 2010/2/23 Jonas Sicking jo...@sicking.cc The same is not true for the suggest notification API. Several proposals have been put forward that do not rely on fallback. One of the reasons I stepped back from this discussion is because it seemed clear that we weren't going to make progress on solutions until we had agreement on requirements (specifically, the amount of interaction that we want to enable in these notifications). The non-fallback proposals that have been put forward aren't acceptable to me for the same reasons that Jonas is opposed to the fallback proposals - we both have a different vision for what the requirements should be. I'd like to see us focus on gaining some consensus around requirements, because I think the rest of these disagreements will mostly resolve themselves once we do that. -atw
Re: Notifications
This thread seems to have languished, and I'm trying to figure out how to move forward here. My understanding, grossly simplified, of the current state of the world is this: 1. Some people have a desire to show HTML / interactive notifications, to support use cases like remind me of this calendar event again in 5 minutes or Answer this call / hang up this call. 2. Some people have a concern that the proposed way to achieve 1, namely allowing HTML, will result in certain platform notification systems (Growl, NotifyOSD etc) not to be used. I will disclose my biases up front and say that I do believe the use cases that 1) tries to support are important. (I want to be able to interact with a calendar notification to say remind me again or take me to the full details of the event, for instance). I also am of the belief regarding #2, being unable to find any actual data on how many users have and use growl, that the user base falls into roughly two camps. There's the people who have gone out and downloaded Growl (or another notification service) because they want everything coalesced, and then there's the people who don't really care, and if mail.app wants to tell them something vs their browser wants to tell them something, they don't really think much of it. I think that initially, we can do a lot more for this second group in terms of functionality that we can provide, and would find it unfortunate if we held up forward progress because of a current implementation detail. If that functionality proves to be useful and desired by a number of users, I believe that platforms like Growl and NotifyOSD will find a way to make it work. In the meantime though, I think there are relatively simple things we can do to not leave these users in the dark. 1, for the CreateHTMLNotification call, we could still allow a text version of the notification to be provided. If there's a significant number of users whose platforms don't support HTML Notifications, I think there's a reasonable chance that would be filled out. If 20% of users didn't see images, alt= text would be more prevalent. 2. For the case where there is no text alternative provided by the website for the HTML notification, the UA can make a best effort at transforming the HTML notification to a text notification, optionally with whatever markup the UA provides for text notifications (bold, links, etc). Obviously things may not be perfect and it would be preferable if the author of the page provided a notification, but the world is not perfect. 3. Let the user decide which notification mechanism they prefer. If the user prefers HTML notifications, then they get whatever the UA implements. If the user has an alternate notification provider they prefer, then they live with the constraints of that notification system, but either way it's a tradeoff that the user can make. And yes, in the near term some of this may be prohibitive on mobile devices, but so are many things (try as they might, mobile browsers still aren't a pleasure to work with when it comes to viewing large complex sites or sites that use flash, etc). I strongly believe that web applications are increasing in number, in scope, and are becoming an integral part of people's lives. As web applications expand, I don't think it is unreasonable to believe that support for HTML in the platform (e.g. HTML in notification providers) will happen some day. It's not going to be immediate, and so I have outlined some ideas that I hope may get us moving in the meanwhile, but I don't want us to fall victim to the argument of well, right now it's hard so let's not do it. My $0.02. Am 12. Februar 2010 12:50 schrieb John Gregg john...@google.com: On Fri, Feb 12, 2010 at 10:14 AM, Drew Wilson atwil...@google.com wrote: On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 11, 2010, at 16:07, Jeremy Orlow wrote: As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? More seriously though: Virtually every user of an up-to-date Ubuntu installation has the notification engine installed. As for Growl, the kind of users who install Growl are presumably the kind of users who care about notifications of multiple concurrent things the most. Furthermore, it seems that notifications are becoming more a part of operating system platfroms. For example, it looks like Windows 7 has a system API for displaying notifications: http://msdn.microsoft.com/en-us/library/ee330740%28VS.85%29.aspx This is a useful data point. It does seem like the major platforms are conforming to a simple icon + title + text interface for ambient notifications. The microsoft API seems more aligned with NotifyOSD (non-interactable notifications with a transient status tray icon provided to allow the user to click). I
Re: Notifications
Hi, Ian- I generally agree with you, and certainly with your sentiment. Not to go all SVG on you, but why *HTMLNotification? I understand that HTML is really common, and that increasingly SVG can be used as part of HTML, but there are lots of devices out there (TVs, mobiles, set-top boxes) that use SVG rather than HTML, which would benefit from these interactive notifications... shouldn't we define a more generic CreateWebNotification and pass an optional MIME Type parameter that defaults to text/html (or some similar mechanism)? I strongly agree with the sentiment that we should design for the future, in any case, and not limit ourselves to simple text notifications. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Ian Fette (イアンフェッティ) wrote (on 2/23/10 1:06 PM): This thread seems to have languished, and I'm trying to figure out how to move forward here. My understanding, grossly simplified, of the current state of the world is this: 1. Some people have a desire to show HTML / interactive notifications, to support use cases like remind me of this calendar event again in 5 minutes or Answer this call / hang up this call. 2. Some people have a concern that the proposed way to achieve 1, namely allowing HTML, will result in certain platform notification systems (Growl, NotifyOSD etc) not to be used. I will disclose my biases up front and say that I do believe the use cases that 1) tries to support are important. (I want to be able to interact with a calendar notification to say remind me again or take me to the full details of the event, for instance). I also am of the belief regarding #2, being unable to find any actual data on how many users have and use growl, that the user base falls into roughly two camps. There's the people who have gone out and downloaded Growl (or another notification service) because they want everything coalesced, and then there's the people who don't really care, and if mail.app wants to tell them something vs their browser wants to tell them something, they don't really think much of it. I think that initially, we can do a lot more for this second group in terms of functionality that we can provide, and would find it unfortunate if we held up forward progress because of a current implementation detail. If that functionality proves to be useful and desired by a number of users, I believe that platforms like Growl and NotifyOSD will find a way to make it work. In the meantime though, I think there are relatively simple things we can do to not leave these users in the dark. 1, for the CreateHTMLNotification call, we could still allow a text version of the notification to be provided. If there's a significant number of users whose platforms don't support HTML Notifications, I think there's a reasonable chance that would be filled out. If 20% of users didn't see images, alt= text would be more prevalent. 2. For the case where there is no text alternative provided by the website for the HTML notification, the UA can make a best effort at transforming the HTML notification to a text notification, optionally with whatever markup the UA provides for text notifications (bold, links, etc). Obviously things may not be perfect and it would be preferable if the author of the page provided a notification, but the world is not perfect. 3. Let the user decide which notification mechanism they prefer. If the user prefers HTML notifications, then they get whatever the UA implements. If the user has an alternate notification provider they prefer, then they live with the constraints of that notification system, but either way it's a tradeoff that the user can make. And yes, in the near term some of this may be prohibitive on mobile devices, but so are many things (try as they might, mobile browsers still aren't a pleasure to work with when it comes to viewing large complex sites or sites that use flash, etc). I strongly believe that web applications are increasing in number, in scope, and are becoming an integral part of people's lives. As web applications expand, I don't think it is unreasonable to believe that support for HTML in the platform (e.g. HTML in notification providers) will happen some day. It's not going to be immediate, and so I have outlined some ideas that I hope may get us moving in the meanwhile, but I don't want us to fall victim to the argument of well, right now it's hard so let's not do it. My $0.02. Am 12. Februar 2010 12:50 schrieb John Gregg john...@google.com mailto:john...@google.com: On Fri, Feb 12, 2010 at 10:14 AM, Drew Wilson atwil...@google.com mailto:atwil...@google.com wrote: On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi mailto:hsivo...@iki.fi wrote: On Feb 11, 2010, at 16:07, Jeremy Orlow wrote: As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a
Re: Notifications
This seems like a balance and all around reasonable way to move forward. 2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com This thread seems to have languished, and I'm trying to figure out how to move forward here. My understanding, grossly simplified, of the current state of the world is this: 1. Some people have a desire to show HTML / interactive notifications, to support use cases like remind me of this calendar event again in 5 minutes or Answer this call / hang up this call. 2. Some people have a concern that the proposed way to achieve 1, namely allowing HTML, will result in certain platform notification systems (Growl, NotifyOSD etc) not to be used. I will disclose my biases up front and say that I do believe the use cases that 1) tries to support are important. (I want to be able to interact with a calendar notification to say remind me again or take me to the full details of the event, for instance). I also am of the belief regarding #2, being unable to find any actual data on how many users have and use growl, that the user base falls into roughly two camps. There's the people who have gone out and downloaded Growl (or another notification service) because they want everything coalesced, and then there's the people who don't really care, and if mail.app wants to tell them something vs their browser wants to tell them something, they don't really think much of it. I think that initially, we can do a lot more for this second group in terms of functionality that we can provide, and would find it unfortunate if we held up forward progress because of a current implementation detail. If that functionality proves to be useful and desired by a number of users, I believe that platforms like Growl and NotifyOSD will find a way to make it work. In the meantime though, I think there are relatively simple things we can do to not leave these users in the dark. 1, for the CreateHTMLNotification call, we could still allow a text version of the notification to be provided. If there's a significant number of users whose platforms don't support HTML Notifications, I think there's a reasonable chance that would be filled out. If 20% of users didn't see images, alt= text would be more prevalent. 2. For the case where there is no text alternative provided by the website for the HTML notification, the UA can make a best effort at transforming the HTML notification to a text notification, optionally with whatever markup the UA provides for text notifications (bold, links, etc). Obviously things may not be perfect and it would be preferable if the author of the page provided a notification, but the world is not perfect. 3. Let the user decide which notification mechanism they prefer. If the user prefers HTML notifications, then they get whatever the UA implements. If the user has an alternate notification provider they prefer, then they live with the constraints of that notification system, but either way it's a tradeoff that the user can make. And yes, in the near term some of this may be prohibitive on mobile devices, but so are many things (try as they might, mobile browsers still aren't a pleasure to work with when it comes to viewing large complex sites or sites that use flash, etc). I strongly believe that web applications are increasing in number, in scope, and are becoming an integral part of people's lives. As web applications expand, I don't think it is unreasonable to believe that support for HTML in the platform (e.g. HTML in notification providers) will happen some day. It's not going to be immediate, and so I have outlined some ideas that I hope may get us moving in the meanwhile, but I don't want us to fall victim to the argument of well, right now it's hard so let's not do it. My $0.02. Am 12. Februar 2010 12:50 schrieb John Gregg john...@google.com: On Fri, Feb 12, 2010 at 10:14 AM, Drew Wilson atwil...@google.comwrote: On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 11, 2010, at 16:07, Jeremy Orlow wrote: As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? More seriously though: Virtually every user of an up-to-date Ubuntu installation has the notification engine installed. As for Growl, the kind of users who install Growl are presumably the kind of users who care about notifications of multiple concurrent things the most. Furthermore, it seems that notifications are becoming more a part of operating system platfroms. For example, it looks like Windows 7 has a system API for displaying notifications: http://msdn.microsoft.com/en-us/library/ee330740%28VS.85%29.aspx This is a useful data point. It does seem like the major platforms are conforming to a simple icon + title + text interface for
Re: Notifications
Doug - I did not mean to be HTML centric, apologies. I'm currently going through a debate in my mind (scary thing) about whether allowing an arbitrary mime type and content would be good or bad. My gut sense here is that if the UA is capable of displaying it, we should allow it, and it will be used or not used (with fallbacks provided) based on the support of UAs, with more UAs evolving to support it as user demand grows. Ideally we would provide multiple fallbacks, e.g. allow someone to specify an ordered list in order of preference, e.g. text/html representation followed by image/svg+xml followed by text/plain (although perhaps text/plain is better left broken out, so that it's more visible and people actually fill it in, as opposed to being some option in a list of things you can provide). e.g. CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. At any rate, I'm not opposed to what you propose, just trying to think out loud of how to best do that while still ensuring that a text fallback is still reasonably simple (and obvious) to specify. -Ian Am 23. Februar 2010 10:24 schrieb Doug Schepers schep...@w3.org: Hi, Ian- I generally agree with you, and certainly with your sentiment. Not to go all SVG on you, but why *HTMLNotification? I understand that HTML is really common, and that increasingly SVG can be used as part of HTML, but there are lots of devices out there (TVs, mobiles, set-top boxes) that use SVG rather than HTML, which would benefit from these interactive notifications... shouldn't we define a more generic CreateWebNotification and pass an optional MIME Type parameter that defaults to text/html (or some similar mechanism)? I strongly agree with the sentiment that we should design for the future, in any case, and not limit ourselves to simple text notifications. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Ian Fette (イアンフェッティ) wrote (on 2/23/10 1:06 PM): This thread seems to have languished, and I'm trying to figure out how to move forward here. My understanding, grossly simplified, of the current state of the world is this: 1. Some people have a desire to show HTML / interactive notifications, to support use cases like remind me of this calendar event again in 5 minutes or Answer this call / hang up this call. 2. Some people have a concern that the proposed way to achieve 1, namely allowing HTML, will result in certain platform notification systems (Growl, NotifyOSD etc) not to be used. I will disclose my biases up front and say that I do believe the use cases that 1) tries to support are important. (I want to be able to interact with a calendar notification to say remind me again or take me to the full details of the event, for instance). I also am of the belief regarding #2, being unable to find any actual data on how many users have and use growl, that the user base falls into roughly two camps. There's the people who have gone out and downloaded Growl (or another notification service) because they want everything coalesced, and then there's the people who don't really care, and if mail.app wants to tell them something vs their browser wants to tell them something, they don't really think much of it. I think that initially, we can do a lot more for this second group in terms of functionality that we can provide, and would find it unfortunate if we held up forward progress because of a current implementation detail. If that functionality proves to be useful and desired by a number of users, I believe that platforms like Growl and NotifyOSD will find a way to make it work. In the meantime though, I think there are relatively simple things we can do to not leave these users in the dark. 1, for the CreateHTMLNotification call, we could still allow a text version of the notification to be provided. If there's a significant number of users whose platforms don't support HTML Notifications, I think there's a reasonable chance that would be filled out. If 20% of users didn't see images, alt= text would be more prevalent. 2. For the case where there is no text alternative provided by the website for the HTML notification, the UA can make a best effort at transforming the HTML notification to a text notification, optionally with whatever markup the UA provides for text notifications (bold, links, etc). Obviously things may not be perfect and it would be preferable if the author of the page provided a notification, but the world is not perfect. 3. Let the user decide which notification mechanism they prefer. If the user prefers HTML notifications, then they get whatever the UA implements. If the user has an alternate notification provider they prefer, then they
Re: Notifications
Hi, Ian- No need to apologize... HTML is a little bit more widely adopted than SVG (I suspect that there are 10x as many HTML documents as SVG documents on the Web). It may be that only specifying text and HTML notifications is the best way forward for now, I just wanted to make sure it was an informed decision. I agree with the simplicity goal. Fallbacks and defaults make a lot of sense to me. I'll noodle a bit and see if I can come up with a simple mechanism, but I'm probably happier reviewing other people's proposals. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Ian Fette (イアンフェッティ) wrote (on 2/23/10 2:20 PM): Doug - I did not mean to be HTML centric, apologies. I'm currently going through a debate in my mind (scary thing) about whether allowing an arbitrary mime type and content would be good or bad. My gut sense here is that if the UA is capable of displaying it, we should allow it, and it will be used or not used (with fallbacks provided) based on the support of UAs, with more UAs evolving to support it as user demand grows. Ideally we would provide multiple fallbacks, e.g. allow someone to specify an ordered list in order of preference, e.g. text/html representation followed by image/svg+xml followed by text/plain (although perhaps text/plain is better left broken out, so that it's more visible and people actually fill it in, as opposed to being some option in a list of things you can provide). e.g. CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. At any rate, I'm not opposed to what you propose, just trying to think out loud of how to best do that while still ensuring that a text fallback is still reasonably simple (and obvious) to specify. -Ian Am 23. Februar 2010 10:24 schrieb Doug Schepers schep...@w3.org mailto:schep...@w3.org: Hi, Ian- I generally agree with you, and certainly with your sentiment. Not to go all SVG on you, but why *HTMLNotification? I understand that HTML is really common, and that increasingly SVG can be used as part of HTML, but there are lots of devices out there (TVs, mobiles, set-top boxes) that use SVG rather than HTML, which would benefit from these interactive notifications... shouldn't we define a more generic CreateWebNotification and pass an optional MIME Type parameter that defaults to text/html (or some similar mechanism)? I strongly agree with the sentiment that we should design for the future, in any case, and not limit ourselves to simple text notifications. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Ian Fette (イアンフェッティ) wrote (on 2/23/10 1:06 PM): This thread seems to have languished, and I'm trying to figure out how to move forward here. My understanding, grossly simplified, of the current state of the world is this: 1. Some people have a desire to show HTML / interactive notifications, to support use cases like remind me of this calendar event again in 5 minutes or Answer this call / hang up this call. 2. Some people have a concern that the proposed way to achieve 1, namely allowing HTML, will result in certain platform notification systems (Growl, NotifyOSD etc) not to be used. I will disclose my biases up front and say that I do believe the use cases that 1) tries to support are important. (I want to be able to interact with a calendar notification to say remind me again or take me to the full details of the event, for instance). I also am of the belief regarding #2, being unable to find any actual data on how many users have and use growl, that the user base falls into roughly two camps. There's the people who have gone out and downloaded Growl (or another notification service) because they want everything coalesced, and then there's the people who don't really care, and if mail.app wants to tell them something vs their browser wants to tell them something, they don't really think much of it. I think that initially, we can do a lot more for this second group in terms of functionality that we can provide, and would find it unfortunate if we held up forward progress because of a current implementation detail. If that functionality proves to be useful and desired by a number of users, I believe that platforms like Growl and NotifyOSD will find a way to make it work. In the meantime though, I think there are relatively simple things we can do to not leave
Re: Notifications
On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. I don't see why it cannot be just a URL. If the user agent supports the type it will render it and it will fail otherwise. There's no need for complex multi-level fallback here in my opinion, nobody is going to bother with that anyway. -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com: On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. I don't see why it cannot be just a URL. If the user agent supports the type it will render it and it will fail otherwise. There's no need for complex multi-level fallback here in my opinion, nobody is going to bother with that anyway. video has multi-level fallback, so there is precedent for better or worse. That said, specifying a (set of) URL(s) may be fine, but I think it would still be nice for a UA to have fallback options. Is everyone going to use it? Probably not, but I think people that actually care would. E.g. if I have a property that I expect people on mobile devices to go to, I will make sure that it works on mobile devices, exactly as we do with properties today where we reasonably expect mobile users. -Ian -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
Doug Schepers wrote (on 2/23/10 2:43 PM): HTML is a little bit more widely adopted than SVG (I suspect that there are 10x as many HTML documents as SVG documents on the Web). I've been told offlist that it may not be obvious that I was joking here... 10x is an absurdly low figure... HTML is many orders of magnitude more common on the Web than SVG (or PDF, or Word, or Flash, or txt, or pretty much anything else). :) Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Notifications
2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com: On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. I don't see why it cannot be just a URL. If the user agent supports the type it will render it and it will fail otherwise. There's no need for complex multi-level fallback here in my opinion, nobody is going to bother with that anyway. video has multi-level fallback, so there is precedent for better or worse. That said, specifying a (set of) URL(s) may be fine, but I think it would still be nice for a UA to have fallback options. Is everyone going to use it? Probably not, but I think people that actually care would. E.g. if I have a property that I expect people on mobile devices to go to, I will make sure that it works on mobile devices, exactly as we do with properties today where we reasonably expect mobile users. I suspect that text fallback + a single URL would be sufficient. As a fallback/escape hatch, servers can sniff UA headers and serve up a different data type if a non-HTML-supporting device starts supporting this API. -Ian -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com: Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com: On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. I don't see why it cannot be just a URL. If the user agent supports the type it will render it and it will fail otherwise. There's no need for complex multi-level fallback here in my opinion, nobody is going to bother with that anyway. video has multi-level fallback, so there is precedent for better or worse. That said, specifying a (set of) URL(s) may be fine, but I think it would still be nice for a UA to have fallback options. Is everyone going to use it? Probably not, but I think people that actually care would. E.g. if I have a property that I expect people on mobile devices to go to, I will make sure that it works on mobile devices, exactly as we do with properties today where we reasonably expect mobile users. Yes, there are several features, such as video and img that have fallback. However this is because there is no alternative other than simply not introducing these features. I.e. we can't redesign video in such a way that fallback for blind people isn't needed, due to inherit visual properties of video. The same is not true for the suggest notification API. Several proposals have been put forward that do not rely on fallback. I'm sure that if you ask any blind person they will tell you that the amount of fallback provided for img is no where near enough. And I'm fairly certain this isn't due to the fact that the majority of web authors don't care about blind people. So while I agree with some of your arguments, I don't at all buy the argument that there are other features out there that use fallback, so it's ok here too, or if people care, they'll provide fallback. / Jonas
Re: Notifications
Am 23. Februar 2010 13:44 schrieb Jonas Sicking jo...@sicking.cc: 2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com: Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com: On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. I don't see why it cannot be just a URL. If the user agent supports the type it will render it and it will fail otherwise. There's no need for complex multi-level fallback here in my opinion, nobody is going to bother with that anyway. video has multi-level fallback, so there is precedent for better or worse. That said, specifying a (set of) URL(s) may be fine, but I think it would still be nice for a UA to have fallback options. Is everyone going to use it? Probably not, but I think people that actually care would. E.g. if I have a property that I expect people on mobile devices to go to, I will make sure that it works on mobile devices, exactly as we do with properties today where we reasonably expect mobile users. Yes, there are several features, such as video and img that have fallback. However this is because there is no alternative other than simply not introducing these features. I.e. we can't redesign video in such a way that fallback for blind people isn't needed, due to inherit visual properties of video. The same is not true for the suggest notification API. Several proposals have been put forward that do not rely on fallback. I'm sure that if you ask any blind person they will tell you that the amount of fallback provided for img is no where near enough. And I'm fairly certain this isn't due to the fact that the majority of web authors don't care about blind people. So while I agree with some of your arguments, I don't at all buy the argument that there are other features out there that use fallback, so it's ok here too, or if people care, they'll provide fallback. / Jonas That's not really an accurate restating of my position. I am saying if no text fallback is specified, let's try to create one from what is given to us. Unlike with video and images, we actually have a reasonable chance of being able to create something intelligible here. Not perfect, but a lot different from the case of here's an image with no alt text, now I will just cry.
Re: Notifications
2010/2/23 Jonas Sicking jo...@sicking.cc The same is not true for the suggest notification API. Several proposals have been put forward that do not rely on fallback. One of the reasons I stepped back from this discussion is because it seemed clear that we weren't going to make progress on solutions until we had agreement on requirements (specifically, the amount of interaction that we want to enable in these notifications). The non-fallback proposals that have been put forward aren't acceptable to me for the same reasons that Jonas is opposed to the fallback proposals - we both have a different vision for what the requirements should be. I'd like to see us focus on gaining some consensus around requirements, because I think the rest of these disagreements will mostly resolve themselves once we do that. -atw
Re: Notifications
On Feb 10, 2010, at 20:35, John Gregg wrote: I agree that this is a good distinction, but I think even considering ambient notifications there is a question of how much interaction should be supported. NotifyOSD, for example, does not allow the user to take any action in response to a notification. Being able to acknowledge an ambient notification could be an optional feature that isn't supported on Ubuntu as long as NotifyOSD doesn't support acknowledging notifications. (If it's a problem to make acknowledgement optional, I think making HTML notification optional is going to be a bigger problem...) FWIW, Microsoft explicitly says notifications must be ignorable and don't persist. Notifications aren't modal and don't require user interaction, so users can freely ignore them. In Windows Vista® and later, notifications are displayed for a fixed duration of 9 seconds. http://msdn.microsoft.com/en-us/library/aa511497.aspx As such, it's always unsafe to design UI in a way that expects the users to be able to acknowledge a given notification. So a very simple use case: email web app wants to alert you have new mail outside the frame, and allow the user to click on that alert and be taken to the inbox page. This does not work on NotifyOSD, because they explicitly don't support that part of the D-bus notifications spec. However, Growl would support this. If acknowledgement support is super-important to Web apps, surely it should be to native apps, too. It seems to me that it would be a bad outcome for users if the Ubuntu desktop and the Web platform disagree on this point and it causes the duplication of notification mechanisms. I think it would make more sense to either add org.freedesktop.Notifications.ActionInvoked to NotifyOSD (if acknowledgeability is the Right Thing) or not to add acknowledgeability to the Web platform (if that's the Right Thing). Having two groups of platform designers (the designers of the Ubuntu desktop and the designers of the Web platform) disagree on what the Right Thing is makes the users lose. CCing mpt in case he can share some insight into why NotifyOSD explicitly doesn't support org.freedesktop.Notifications.ActionInvoked. On Feb 11, 2010, at 00:10, Drew Wilson wrote: it seems like the utility of being able to put markup such as bold text, or graphics, or links in a notification should be self-evident, It's not self-evident. If it were, surely native apps would be bypassing NotifyOSD and Growl to get more bolded and linkified notifications. On Feb 11, 2010, at 16:07, Jeremy Orlow wrote: As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? More seriously though: Virtually every user of an up-to-date Ubuntu installation has the notification engine installed. As for Growl, the kind of users who install Growl are presumably the kind of users who care about notifications of multiple concurrent things the most. Furthermore, it seems that notifications are becoming more a part of operating system platfroms. For example, it looks like Windows 7 has a system API for displaying notifications: http://msdn.microsoft.com/en-us/library/ee330740%28VS.85%29.aspx Are there other examples where we've dumbed down an API to the least common denominator for a small fraction of users? Especially when there's no technical reason why these providers could not be made more advanced (for example, embed webkit to display fully functional notifications)? It's not a given that it's an advancement in user experience terms not to force all ambient notifications into a consistent form. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: Notifications
On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote: FWIW, Microsoft explicitly says notifications must be ignorable and don't persist. Notifications aren't modal and don't require user interaction, so users can freely ignore them. In Windows Vista® and later, notifications are displayed for a fixed duration of 9 seconds. http://msdn.microsoft.com/en-us/library/aa511497.aspx There are several references to Windows notifications, and how they work as a guideline (ignorable, 9 seconds, etc.) It is worth noting that these have been around for some time and applications (im clients, some rss readers, etc.) that care about notification *don't* use them. So a very simple use case: email web app wants to alert you have new mail outside the frame, and allow the user to click on that alert and be taken to the inbox page. This does not work on NotifyOSD, because they explicitly don't support that part of the D-bus notifications spec. However, Growl would support this. If acknowledgement support is super-important to Web apps, surely it should be to native apps, too. The use case seems to be about allowing the user to take quick action on a notification. The growl, many mobile notifications (and the aforementioned windows notification system) allow the user to click notifications and be taken to a more in depth view of the information. It sounds like NotifyOSD is an outlier in this aspect. On Feb 11, 2010, at 00:10, Drew Wilson wrote: it seems like the utility of being able to put markup such as bold text, or graphics, or links in a notification should be self-evident, It's not self-evident. If it were, surely native apps would be bypassing NotifyOSD and Growl to get more bolded and linkified notifications. From reading the spec, it looks like Notify OSD supports two kinds of markup already, so it allows for bold, italic, links, underlines, images, and fonts (http://www.galago-project.org/specs/notification/0.9/x161.html, http://library.gnome.org/devel/pango/unstable/PangoMarkupFormat.html). So it makes headway in allowing for applications a richer display, but of course, this is arbitrarily limited and would cut out several scenarios that Drew and John have already mentioned. Lastly, it sounds like the any UA implementing the api being proposed could use these mechanisms (NotifyOSD, etc.) and just not provide as rich of an experience (as one would get from an html version). dave
Re: Notifications
On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 11, 2010, at 16:07, Jeremy Orlow wrote: As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? More seriously though: Virtually every user of an up-to-date Ubuntu installation has the notification engine installed. As for Growl, the kind of users who install Growl are presumably the kind of users who care about notifications of multiple concurrent things the most. Furthermore, it seems that notifications are becoming more a part of operating system platfroms. For example, it looks like Windows 7 has a system API for displaying notifications: http://msdn.microsoft.com/en-us/library/ee330740%28VS.85%29.aspx This is a useful data point. It does seem like the major platforms are conforming to a simple icon + title + text interface for ambient notifications. The microsoft API seems more aligned with NotifyOSD (non-interactable notifications with a transient status tray icon provided to allow the user to click). I suspect a UA on those platforms (NotifyOSD and Microsoft) would display an icon with each notification to give the user the ability to register a click on and/or dismiss the notification. Are there other examples where we've dumbed down an API to the least common denominator for a small fraction of users? Especially when there's no technical reason why these providers could not be made more advanced (for example, embed webkit to display fully functional notifications)? It's not a given that it's an advancement in user experience terms not to force all ambient notifications into a consistent form. I think this is a reasonable point also. I also want to reiterate that your distinction between ambient and interactive notifications is an interesting one - most of the system notification frameworks are geared towards ambient notifications (it's why NotifyOSD does not support the DBUS actions array, I'm assuming). Their core use cases are things like your printer is out of paper, not You have an incoming voice call from Bob. Answer the call? Yes/No. I think the challenge here is framing our API in a way to allow developers to specify their intent (interactive vs ambient), with more restrictions on ambient content. The current spec makes one cut at this via createNotification vs createHTMLNotification, but it's not at all clear that HTML notifications are intended to be interactive rather than just pretty versions of ambient notifications (hence, Jonas' concern that developers will just create HTML notifications when what they really want is an ambient notification). One solution is only to support ambient notifications (which is essentially the thrust of the no HTML argument), but I'd be opposed to any API that does not allow for interactive notifications. I suppose that's a discussion for the requirements thread, though :) -atw
Re: Notifications
On Fri, Feb 12, 2010 at 10:14 AM, Drew Wilson atwil...@google.com wrote: On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 11, 2010, at 16:07, Jeremy Orlow wrote: As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? More seriously though: Virtually every user of an up-to-date Ubuntu installation has the notification engine installed. As for Growl, the kind of users who install Growl are presumably the kind of users who care about notifications of multiple concurrent things the most. Furthermore, it seems that notifications are becoming more a part of operating system platfroms. For example, it looks like Windows 7 has a system API for displaying notifications: http://msdn.microsoft.com/en-us/library/ee330740%28VS.85%29.aspx This is a useful data point. It does seem like the major platforms are conforming to a simple icon + title + text interface for ambient notifications. The microsoft API seems more aligned with NotifyOSD (non-interactable notifications with a transient status tray icon provided to allow the user to click). I suspect a UA on those platforms (NotifyOSD and Microsoft) would display an icon with each notification to give the user the ability to register a click on and/or dismiss the notification. Are there other examples where we've dumbed down an API to the least common denominator for a small fraction of users? Especially when there's no technical reason why these providers could not be made more advanced (for example, embed webkit to display fully functional notifications)? It's not a given that it's an advancement in user experience terms not to force all ambient notifications into a consistent form. I think this is a reasonable point also. I also want to reiterate that your distinction between ambient and interactive notifications is an interesting one - most of the system notification frameworks are geared towards ambient notifications (it's why NotifyOSD does not support the DBUS actions array, I'm assuming). Their core use cases are things like your printer is out of paper, not You have an incoming voice call from Bob. Answer the call? Yes/No. I think the challenge here is framing our API in a way to allow developers to specify their intent (interactive vs ambient), with more restrictions on ambient content. The current spec makes one cut at this via createNotification vs createHTMLNotification, but it's not at all clear that HTML notifications are intended to be interactive rather than just pretty versions of ambient notifications (hence, Jonas' concern that developers will just create HTML notifications when what they really want is an ambient notification). In terms of how I wrote the current draft, HTML vs Text+Icon has nothing to do with notifications being ambient or persistent. It is really just about the content of the notification. It would completely acceptable to me to have HTML notifications which are always ambient: they show up for a few seconds, then they go away, but if the user wants to interact with the dynamic content during those seconds it's possible. The problem is that none of the popular ambient notification providers support HTML, so the assumption is that HTML = another new window or HTML = mandatory acknowledgement. However that's not necessarily true. One solution is only to support ambient notifications (which is essentially the thrust of the no HTML argument), but I'd be opposed to any API that does not allow for interactive notifications. I suppose that's a discussion for the requirements thread, though :) Nothing in the current draft spec requires a UA to make Web Notifications of either type persistent - a UA which only supports ambient (self-closing) notifications could already be conforming, as long as clicks that do happen are passed back to the web page. -John
Re: Notifications
On Thu, Feb 11, 2010 at 7:24 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 10, 2010 at 6:29 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote: And I think the answer is yes. Any time someone talks about an optional web feature I get nervous. Can you give any examples of successful optional web features that exist today? I'd suggest Javascript and Images, but you've rejected them because you don't think they are examples of successful optional features (meaning that browsers that don't support them are not equally compatible with all web content) - and yet most browsers do support turning them off so there must be some value for a subset of users. Have you ever tried to browse the web with javascript or images turned off? It's not an experience most users would say is useful. I think there are some potentially conflicting goals for any of the HTML APIs: 1) Providing a single lowest-common-denominator API that we can support on every single platform to provide the maximum amount of compatibility. For notifications, pretty much every capable platform can display an icon and a single line of text, so if we wanted to be pedantic we could make that our API, but the currently proposed icon + header + body text is probably more reasonable. 2) Providing an API that is flexible enough to take advantage of the capabilities of more advanced platforms. 3) Future proofing the API (as capabilities of platforms grow, the API can continue to support them) I disagree with 2 and 3 being goals. Taking advantage of platform capabilities isn't a goal in and of itself, it's just a mean. Providing a better user experience is the goal IMHO. If users that want to use Growl can't get their browser notifications through growl because the browser was forced to use some other mechanism to implement HTML notifications, then we haven't improved that users experience. Even worse, if they don't get *any* notifications because the website didn't provide a non-html equivalent, then we certainly haven't helped that user. As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? Are there other examples where we've dumbed down an API to the least common denominator for a small fraction of users? Especially when there's no technical reason why these providers could not be made more advanced (for example, embed webkit to display fully functional notifications)? I really think this is a silly rathole that we've gotten ourselves into here. I'm sure that we can come up with a technical solution that gracefully degrades for those users who want html notifications to integrate with growl/etc but provides a robust experience for the rest of users. J
Re: Notifications
I can't help but think the Growl issue is way overblown. I am the user who uses Growl and also a GoogleTalkLabsEdition for Mac that pop ups nice notifications about upcoming meetings, email and chat. Growl is connected to IRC and something else (don't even remember). They both use top-right corner of the screen to pop up their balloons and co-exist just fine. I don't remember having them ever overlap (or that being a problem). And snooze on meeting popups is great. As for less-capable devices like phones, a few years ago even having a real HTML displayed on them was out of the question. There are still successful companies out there that provide a service of translating any given HTML page into dumbed-down version for a particular cellphone model - for a fee per-translation. Sites that are serious about mobile internet on wide variety of currently-deployed devices often use this stuff to serve pages, it's easier then to build up expertise on all the variants of crippled 'browsers' out there. The progress in this field in a last few years is phenomenal and fast. It wouldn't be surprising if 'regular' HTML notifications were totally possible on those devices by the time the spec and implementations gain some maturity. There is no reason why user of a cell phone can not have a nice meeting reminder with a snooze button, or a chat invite with 'reply now', without the need for a native app. Dmitry On Thu, Feb 11, 2010 at 6:07 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Feb 11, 2010 at 7:24 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 10, 2010 at 6:29 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote: And I think the answer is yes. Any time someone talks about an optional web feature I get nervous. Can you give any examples of successful optional web features that exist today? I'd suggest Javascript and Images, but you've rejected them because you don't think they are examples of successful optional features (meaning that browsers that don't support them are not equally compatible with all web content) - and yet most browsers do support turning them off so there must be some value for a subset of users. Have you ever tried to browse the web with javascript or images turned off? It's not an experience most users would say is useful. I think there are some potentially conflicting goals for any of the HTML APIs: 1) Providing a single lowest-common-denominator API that we can support on every single platform to provide the maximum amount of compatibility. For notifications, pretty much every capable platform can display an icon and a single line of text, so if we wanted to be pedantic we could make that our API, but the currently proposed icon + header + body text is probably more reasonable. 2) Providing an API that is flexible enough to take advantage of the capabilities of more advanced platforms. 3) Future proofing the API (as capabilities of platforms grow, the API can continue to support them) I disagree with 2 and 3 being goals. Taking advantage of platform capabilities isn't a goal in and of itself, it's just a mean. Providing a better user experience is the goal IMHO. If users that want to use Growl can't get their browser notifications through growl because the browser was forced to use some other mechanism to implement HTML notifications, then we haven't improved that users experience. Even worse, if they don't get *any* notifications because the website didn't provide a non-html equivalent, then we certainly haven't helped that user. As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? Are there other examples where we've dumbed down an API to the least common denominator for a small fraction of users? Especially when there's no technical reason why these providers could not be made more advanced (for example, embed webkit to display fully functional notifications)? I really think this is a silly rathole that we've gotten ourselves into here. I'm sure that we can come up with a technical solution that gracefully degrades for those users who want html notifications to integrate with growl/etc but provides a robust experience for the rest of users. J
Re: Notifications
On Feb 3, 2010, at 20:54, Drew Wilson wrote: Following up on breaking out createHTMLNotification() and createNotification() vs combining them into one large API - I believe the intent is that a given user agent may not support all types of notifications (for example, a mobile phone application may only support text + icon notifications, not HTML notifications). My main concern isn't mobile phones in the abstract but mapping to concrete system-wide notification mechanisms: Growl and NotifyOSD on Mac and Ubuntu respectively. So far, the only use case I've seen (on the WHATWG list) for HTML notifications that aren't close to the kind of notifications that Growl and NotifyOSD support has been a calendar alarm. I agree that calendar alarm is a valid use case, but I think HTML vs. not HTML isn't the right taxonomy. Rather, it seems to me that there are ambient notifications (that dismiss themselves after a moment even if unacknowledged) and notifications that are all about interrupting the user until explicitly dismissed (calendar alarms). I think the API for ambient notifications should be designed so that browsers can map all ambient notifications to Growl and NotifyOSD. As for notifications that require explicit acknowledgement, I think it would be worthwhile to collect use cases beyond calendar alarms first and not heading right away to generic HTML notifications. If it turns out that notifications that require explicit acknowledgements are virtually always calendar alarms or alarm clock notifications, it might make sense to design an API explicitly for those. For example, it could be desirable to allow a privileged calendar Web app to schedule such alarms to fire on a mobile device without having to keep a browsing context or a worker active at the notification time. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: Notifications
On Wed, Feb 10, 2010 at 2:17 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 3, 2010, at 20:54, Drew Wilson wrote: Following up on breaking out createHTMLNotification() and createNotification() vs combining them into one large API - I believe the intent is that a given user agent may not support all types of notifications (for example, a mobile phone application may only support text + icon notifications, not HTML notifications). My main concern isn't mobile phones in the abstract but mapping to concrete system-wide notification mechanisms: Growl and NotifyOSD on Mac and Ubuntu respectively. So far, the only use case I've seen (on the WHATWG list) for HTML notifications that aren't close to the kind of notifications that Growl and NotifyOSD support has been a calendar alarm. I agree that calendar alarm is a valid use case, but I think HTML vs. not HTML isn't the right taxonomy. Rather, it seems to me that there are ambient notifications (that dismiss themselves after a moment even if unacknowledged) and notifications that are all about interrupting the user until explicitly dismissed (calendar alarms). I agree that this is a good distinction, but I think even considering ambient notifications there is a question of how much interaction should be supported. NotifyOSD, for example, does not allow the user to take any action in response to a notification. So a very simple use case: email web app wants to alert you have new mail outside the frame, and allow the user to click on that alert and be taken to the inbox page. This does not work on NotifyOSD, because they explicitly don't support that part of the D-bus notifications spec. However, Growl would support this. So this suggested approach reduces us to the least common denominator of these existing notification providers, which are far from ubiquitous (Growl is a separate install from the OS, and we haven't yet discussed what Windows users would see). Perhaps spec'ing HTML notifications is looking too far down one particular road, but I'm concerned about being completely restricted by the current set of frameworks, if that means we can't even rely on an onclick event. -John
Re: Notifications
We ran into this issue when mapping our own browser notifications to platform notification APIs. For ambient notifications, you can't rely on the user being able to click on the notification, because the notification might time out and disappear on its own before the user has had a chance to react, so there always has to be another way for the user to get the information and perform the action. So NotifyOSD not supporting actions is an issue of convenience, not functionality. So then, if the NotifyOSD designers think their users don't need that convenience, that's their call. A generic API can offer support for actions with the understanding that in some cases users won't be able to use them. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Notifications
On Wed, Feb 10, 2010 at 2:17 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 3, 2010, at 20:54, Drew Wilson wrote: Following up on breaking out createHTMLNotification() and createNotification() vs combining them into one large API - I believe the intent is that a given user agent may not support all types of notifications (for example, a mobile phone application may only support text + icon notifications, not HTML notifications). My main concern isn't mobile phones in the abstract but mapping to concrete system-wide notification mechanisms: Growl and NotifyOSD on Mac and Ubuntu respectively. I've had a few conversations about Growl and NotifyOSD, both on- and off-list, and I think it makes sense to discuss some of the underlying concerns. From these conversations, I've gotten the impression that some of the objections to HTML notifications are not entirely based in use cases (for example, it seems like the utility of being able to put markup such as bold text, or graphics, or links in a notification should be self-evident, even ignoring the various use cases around direct interaction with notifications). I haven't heard anyone claim that markup is bad - rather, the objections seem to boil down to a concern that somehow the mere existence of HTML notifications would undermine the adoption or use of Growl and NotifyOSD. I absolutely agree that Growl and NotifyOSD are important use cases to support, but I don't think they should be the tail that wags the dog (for example, I'm not sure that I agree with Henri that they should be treated as a more important use case than mobile phones, given the disparity in the size of the installed bases). And I also understand that for the users of these frameworks, having an application display notifications outside of the framework (possibly conflicting with those frameworks) would be a real problem. One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. I don't think it's in the best interest of developers or users to enforce a lowest-common-denominator approach to this API (especially since the currently dominant platform [Windows] doesn't have any native notification framework and would seem to derive great benefit from notifications with markup). Is the API change described above sufficient, or are there more things that we can do from an API standpoint to give UAs the flexibility to provide the desired user experience under Growl/NotifyOSD, without putting unnecessary restrictions on UAs running on other platforms? -atw So far, the only use case I've seen (on the WHATWG list) for HTML notifications that aren't close to the kind of notifications that Growl and NotifyOSD support has been a calendar alarm. I agree that calendar alarm is a valid use case, but I think HTML vs. not HTML isn't the right taxonomy. Rather, it seems to me that there are ambient notifications (that dismiss themselves after a moment even if unacknowledged) and notifications that are all about interrupting the user until explicitly dismissed (calendar alarms). I think the API for ambient notifications should be designed so that browsers can map all ambient notifications to Growl and NotifyOSD. As for notifications that require explicit acknowledgement, I think it would be worthwhile to collect use cases beyond calendar alarms first and not heading right away to generic HTML notifications. If it turns out that notifications that require explicit acknowledgements are virtually always calendar alarms or alarm clock notifications, it might make sense to design an API explicitly for those. For example, it could be desirable to allow a privileged calendar Web app to schedule such alarms to fire on a mobile device without having to keep a browsing context or a worker active at the notification time. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: Notifications
On Thu, Feb 11, 2010 at 11:10 AM, Robert O'Callahan rob...@ocallahan.orgwrote: We ran into this issue when mapping our own browser notifications to platform notification APIs. For ambient notifications, you can't rely on the user being able to click on the notification, because the notification might time out and disappear on its own before the user has had a chance to react, so there always has to be another way for the user to get the information and perform the action. So NotifyOSD not supporting actions is an issue of convenience, not functionality. So then, if the NotifyOSD designers think their users don't need that convenience, that's their call. A generic API can offer support for actions with the understanding that in some cases users won't be able to use them. Er, ignore that entire message. Sorry! Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Notifications
On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote: One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. The problem with that is that authors who test with a system that supports HTML notifications could easily provide the wrong non-HTML message, or no message at all, and not notice. It also forces authors to say things twice. I think a better way to go would be to support a restricted subset of HTML, and then consider how the UA should extract text for a plaintext-only notification framework (possibly opting to fall back to non-native notifications if the text extraction doesn't work). For example, you could allow only b and img elements, and for text-only notifications you would strip b and use the alt text for img, and if the author didn't provide alt text for img then and only then you would fall back to non-native notifications. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Notifications
On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote: One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. The problem with that is that authors who test with a system that supports HTML notifications could easily provide the wrong non-HTML message, or no message at all, and not notice. It also forces authors to say things twice. Analogously, developers can (and do!) create pages that rely on javascript or images being enabled, which break if a UA does not support them. I would not use this as an argument against UAs supporting Javascript or images. You make the further point that application authors may intentionally *only* want to display HTML notifications, and would rather display nothing if HTML is not available (they pass in no message at all) - I'm not sure this is true, but if it is I'd say that's an argument in favor of supporting HTML in this API, not against it. I think a better way to go would be to support a restricted subset of HTML, and then consider how the UA should extract text for a plaintext-only notification framework (possibly opting to fall back to non-native notifications if the text extraction doesn't work). For example, you could allow only b and img elements, and for text-only notifications you would strip b and use the alt text for img, and if the author didn't provide alt text for img then and only then you would fall back to non-native notifications. It seems unusual to me that in a spec directed at HTML-based UAs, we would define some sort of domain-specific markup language rather than simply supporting HTML. Browsers know how to render HTML and can extract text appropriately if for some reason they need to down-render (for example, see the textContent and innerText element properties). Why would we define a separate markup language to allow defining marked up text that can be rendered differently depending on the display capabilities - isn't that what HTML is for? Is there an advantage to defining a subset? Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Notifications
On Wed, Feb 10, 2010 at 3:03 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote: One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. The problem with that is that authors who test with a system that supports HTML notifications could easily provide the wrong non-HTML message, or no message at all, and not notice. It also forces authors to say things twice. Analogously, developers can (and do!) create pages that rely on javascript or images being enabled, which break if a UA does not support them. I would not use this as an argument against UAs supporting Javascript or images. This has indeed lead to that any browser that wants to get a significant user base, or wants to be able to browse a significant part of the web has to implement a Javascript engine and the DOM. The argument is that the same thing would happen here. Every browser would have to implement support for HTML notifications. I.e. calling it optional will likely only be true in theory after a while. / Jonas
Re: Notifications
On Thu, Feb 11, 2010 at 12:03 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote: I think a better way to go would be to support a restricted subset of HTML, and then consider how the UA should extract text for a plaintext-only notification framework (possibly opting to fall back to non-native notifications if the text extraction doesn't work). For example, you could allow only b and img elements, and for text-only notifications you would strip b and use the alt text for img, and if the author didn't provide alt text for img then and only then you would fall back to non-native notifications. It seems unusual to me that in a spec directed at HTML-based UAs, we would define some sort of domain-specific markup language rather than simply supporting HTML. Browsers know how to render HTML and can extract text appropriately if for some reason they need to down-render (for example, see the textContent and innerText element properties). Why would we define a separate markup language to allow defining marked up text that can be rendered differently depending on the display capabilities - isn't that what HTML is for? Is there an advantage to defining a subset? If it supports, e.g., scripting, then you have to define what the relationship is between the browsing context for the notification and the browsing context for the opener. Can a notification document navigate itself using document.location = ...? At that point, this sounds like a specialized version of window.open. If that's your intent, maybe we should just add a flag to window.open? Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Notifications
On Wed, Feb 10, 2010 at 3:31 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 11, 2010 at 12:03 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote: I think a better way to go would be to support a restricted subset of HTML, and then consider how the UA should extract text for a plaintext-only notification framework (possibly opting to fall back to non-native notifications if the text extraction doesn't work). For example, you could allow only b and img elements, and for text-only notifications you would strip b and use the alt text for img, and if the author didn't provide alt text for img then and only then you would fall back to non-native notifications. It seems unusual to me that in a spec directed at HTML-based UAs, we would define some sort of domain-specific markup language rather than simply supporting HTML. Browsers know how to render HTML and can extract text appropriately if for some reason they need to down-render (for example, see the textContent and innerText element properties). Why would we define a separate markup language to allow defining marked up text that can be rendered differently depending on the display capabilities - isn't that what HTML is for? Is there an advantage to defining a subset? If it supports, e.g., scripting, then you have to define what the relationship is between the browsing context for the notification and the browsing context for the opener. Can a notification document navigate itself using document.location = ...? At that point, this sounds like a specialized version of window.open. If that's your intent, maybe we should just add a flag to window.open? I agree - the spec needs to define all of the implications of HTML support as well as any restrictions as to its use. On the bright side, from a security standpoint treating an HTML notification as its own browsing context ala window.open() is a well-understood model. As for using a specialized version of window.open() for notifications - that's an interesting suggestion. I think we'd still need to deal with the permission grant issue as well as having a good way to generate icon+header+body notifications from the HTML for compatibility with Growl/NotifyOSD/mobile platforms - I still think that having some way for the developer to explicitly specify a title/icon/body is superior to having the browser have to infer these pieces from a parsed DOM tree. But it's a good point that this starts to feel more like window.open(). Stepping back from the HTML issue, I note that one of the things in the NotifyOSD/DBUS API is the concept of a client-specified replace ID - the idea is that client applications can give their notifications a replace ID, and when that application displays a notification with that ID it replaces any currently displayed notification with that ID. I think that something like this would solve one of the core issues with the proposed notification API, which is avoiding duplicate notifications in the case where you have the same web page open in multiple windows. If we supported an optional replace ID parameter in createNotification(), then a page that wanted to have (say) a you have new mail notification could give that notification an ID of new_mail, so if any other page under the same origin tried to display a notification with a new_mail ID it would just replace the existing notification rather than displaying a duplicate notification. If we don't support this, apps have to jump through hoops using SharedWorkers or other methods to make sure they don't annoy the user with duplicate notifications. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Notifications
On Wed, Feb 10, 2010 at 3:22 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 10, 2010 at 3:03 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote: One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. The problem with that is that authors who test with a system that supports HTML notifications could easily provide the wrong non-HTML message, or no message at all, and not notice. It also forces authors to say things twice. Analogously, developers can (and do!) create pages that rely on javascript or images being enabled, which break if a UA does not support them. I would not use this as an argument against UAs supporting Javascript or images. This has indeed lead to that any browser that wants to get a significant user base, or wants to be able to browse a significant part of the web has to implement a Javascript engine and the DOM. I hear you. I'm not convinced that the web would be a better place without support for Javascript or Images though, despite the burden it might put on UA developers looking for wide compatibility. The nice thing about notifications is they are *clearly* an optional addition to the core functionality of a site (since the user has to grant permission to allow them to be displayed - they don't work by default anyway) so from an end user standpoint they can merely deny notification permission to web apps that do not display useful notifications. Your original objection about the existence of createHTMLNotification() was spot-on - UAs that do not provide this API would indeed break the web because application javascript code would throw undefined method exceptions in the middle of related operations. With a coalesced API that exists regardless of platform, it seems like this argument has less force. The argument is that the same thing would happen here. Every browser would have to implement support for HTML notifications. I.e. calling it optional will likely only be true in theory after a while. I'm assuming you aren't suggesting that this would happen because HTML notifications are so much better than non-HTML that developers just want to use HTML notifications :) I think our goal for optional support for HTML should not be that this would somehow enable desktop browsers to omit support for HTML notifications (keep in mind that NotifyOSD and Growl are far from ubiquitous on their relative platforms - browsers on Linux and the Mac will still need to be able to display notifications in the absence of these frameworks). Rather, providing a text + icon fallback for the HTML parameter enables this API to work on platforms that *cannot* support HTML notifications (a good example of a platform like this would be the Palm Pre, which has a dedicated text notification bar), similar to alt-text for img tags. A related goal is to support things like NotifyOSD and Growl gracefully, but IMO the expectation should not be that desktop browsers can/should just omit HTML notification support entirely. So I think the right question to ask isn't does this force all browsers to support HTML notifications? because I think that all browsers on platforms that can support them will need to do so anyway, but rather does the presence of widespread HTML notification support make it more likely that developers will neglect text+icon notifications, to the detriment of users that want them. Anyhow, my other concern with baking in lowest-common-denominator functionality into our APIs is that platform capabilities evolve over time. To make up a hypothetical example, it would not be unthinkable for another notification framework to supplant Growl over the next 5 years (for instance, if Apple added support for WebKit-based HTML notifications to the OS), or for Growl to add support for markup in its notifications, and yet UAs would be powerless to take advantage of these new capabilities if the APIs themselves lock in the lowest-common-denominator functionality. If we can future-proof the API, we should. / Jonas
Re: Notifications
On Wed, Feb 10, 2010 at 5:21 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 3:22 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 10, 2010 at 3:03 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote: One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. The problem with that is that authors who test with a system that supports HTML notifications could easily provide the wrong non-HTML message, or no message at all, and not notice. It also forces authors to say things twice. Analogously, developers can (and do!) create pages that rely on javascript or images being enabled, which break if a UA does not support them. I would not use this as an argument against UAs supporting Javascript or images. This has indeed lead to that any browser that wants to get a significant user base, or wants to be able to browse a significant part of the web has to implement a Javascript engine and the DOM. I hear you. I'm not convinced that the web would be a better place without support for Javascript or Images though, despite the burden it might put on UA developers looking for wide compatibility. Javascript and images has added *a lot* of value to the web platform though. I'm not convinced that HTML notifications add the similar amount of value over a simpler notification format. The argument is that the same thing would happen here. Every browser would have to implement support for HTML notifications. I.e. calling it optional will likely only be true in theory after a while. I'm assuming you aren't suggesting that this would happen because HTML notifications are so much better than non-HTML that developers just want to use HTML notifications :) It's enough that one or two high profile sites use it for every browser to need to implement it. I think our goal for optional support for HTML should not be that this would somehow enable desktop browsers to omit support for HTML notifications (keep in mind that NotifyOSD and Growl are far from ubiquitous on their relative platforms - browsers on Linux and the Mac will still need to be able to display notifications in the absence of these frameworks). Rather, providing a text + icon fallback for the HTML parameter enables this API to work on platforms that *cannot* support HTML notifications (a good example of a platform like this would be the Palm Pre, which has a dedicated text notification bar), similar to alt-text for img tags. However these types of fallback generally are used very rarely. I think Hixie might have run some actual numbers, but I would be surprised if even 1% of all images that need fallback content has a useful alt attribute. A related goal is to support things like NotifyOSD and Growl gracefully, but IMO the expectation should not be that desktop browsers can/should just omit HTML notification support entirely. So I think the right question to ask isn't does this force all browsers to support HTML notifications? because I think that all browsers on platforms that can support them will need to do so anyway, but rather does the presence of widespread HTML notification support make it more likely that developers will neglect text+icon notifications, to the detriment of users that want them. And I think the answer is yes. Any time someone talks about an optional web feature I get nervous. Can you give any examples of successful optional web features that exist today? / Jonas
Re: Notifications
On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote: And I think the answer is yes. Any time someone talks about an optional web feature I get nervous. Can you give any examples of successful optional web features that exist today? I'd suggest Javascript and Images, but you've rejected them because you don't think they are examples of successful optional features (meaning that browsers that don't support them are not equally compatible with all web content) - and yet most browsers do support turning them off so there must be some value for a subset of users. The history of the web has generally been that good features spread to become ubiquitous, and if your concern is that HTML notifications will become one of those features, then I echo your concern :) I think there are some potentially conflicting goals for any of the HTML APIs: 1) Providing a single lowest-common-denominator API that we can support on every single platform to provide the maximum amount of compatibility. For notifications, pretty much every capable platform can display an icon and a single line of text, so if we wanted to be pedantic we could make that our API, but the currently proposed icon + header + body text is probably more reasonable. 2) Providing an API that is flexible enough to take advantage of the capabilities of more advanced platforms. 3) Future proofing the API (as capabilities of platforms grow, the API can continue to support them) I think we all have differing opinions over the importance of these varying goals - ideally we'd find an API that can satisfy all three, but I do agree that adding optional HTML support has a potentially negative impact on goal #1. However, that doesn't mean that we should pursue an API that *only* satisfies goal #1. I don't want to get completely focused on a single possible solution to this dilemma (i.e. supporting an optional HTML parameter), although I have to admit I personally think the idea of a fully-scriptable active notification is really compelling. Are there other solutions that would better meet those 3 goals? Maybe I'm off-base and goal #1 is the only one that matters in this case? -atw
Re: Notifications
On Wed, Feb 10, 2010 at 6:29 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote: And I think the answer is yes. Any time someone talks about an optional web feature I get nervous. Can you give any examples of successful optional web features that exist today? I'd suggest Javascript and Images, but you've rejected them because you don't think they are examples of successful optional features (meaning that browsers that don't support them are not equally compatible with all web content) - and yet most browsers do support turning them off so there must be some value for a subset of users. Have you ever tried to browse the web with javascript or images turned off? It's not an experience most users would say is useful. I think there are some potentially conflicting goals for any of the HTML APIs: 1) Providing a single lowest-common-denominator API that we can support on every single platform to provide the maximum amount of compatibility. For notifications, pretty much every capable platform can display an icon and a single line of text, so if we wanted to be pedantic we could make that our API, but the currently proposed icon + header + body text is probably more reasonable. 2) Providing an API that is flexible enough to take advantage of the capabilities of more advanced platforms. 3) Future proofing the API (as capabilities of platforms grow, the API can continue to support them) I disagree with 2 and 3 being goals. Taking advantage of platform capabilities isn't a goal in and of itself, it's just a mean. Providing a better user experience is the goal IMHO. If users that want to use Growl can't get their browser notifications through growl because the browser was forced to use some other mechanism to implement HTML notifications, then we haven't improved that users experience. Even worse, if they don't get *any* notifications because the website didn't provide a non-html equivalent, then we certainly haven't helped that user. / Jonas
Re: Notifications
On Thu, 04 Feb 2010 00:36:26 +0100, John Gregg john...@google.com wrote: I'm familiar with that version of the proposal (in fact my WHATWG proposal from March '09 had the same language: untrusted notifications displayed in-browser), but considering it more I think it is too limiting. Considering widgets, mobile browsers, browser extensions, workers (already in the spec), etc., which all might want to use this API, it's potentially many different forms of UI for untrusted notifications---where do they go, how is it clear where they came from? Compare that to a single place outside the browser, with a clear source displayed, once trust is established. I prefer the latter. You probably need different permission UI regardless. E.g. on mobile browsers you might not show the notification in-tab but would only something if the user did something in response to a dialog. In the case the first notification from an application is an important one, that app should be able to request permission for out-of-tab notifications beforehand; Aren't notifications by nature somewhat non-important? In any event, we could expose to the application whether or not it was displayed and if it was not the application could pick an alternative route to convey the information. for that reason I'm convinced requestPermission() is desirable. However beyond that, perhaps the spec should be flexible; if a UA wants to treat PERMISSION_UNKNOWN as show in-tab rather than throw exception, the spec could allow it -- but I don't think it should require it. Would that be acceptable? I'm not convinced we need a permission API and would therefore rather leave it out to see if we can do without. We do not have an API like this anymore else. -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
On Fri, Feb 5, 2010 at 6:52 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 04 Feb 2010 00:36:26 +0100, John Gregg john...@google.com wrote: In the case the first notification from an application is an important one, that app should be able to request permission for out-of-tab notifications beforehand; Aren't notifications by nature somewhat non-important? Yes, but only if they aren't done well. I have notifications to remind me to go to meetings, or when someone is trying to reach me in irc. These are very important to me. oth, I may also have a notification about new email that is directly to me. It still may need my attention but is less important to me that the prior two. I don't want notifications about things that are unimportant to me.
Re: Notifications
On Fri, Feb 5, 2010 at 6:52 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 04 Feb 2010 00:36:26 +0100, John Gregg john...@google.com wrote: I'm familiar with that version of the proposal (in fact my WHATWG proposal from March '09 had the same language: untrusted notifications displayed in-browser), but considering it more I think it is too limiting. Considering widgets, mobile browsers, browser extensions, workers (already in the spec), etc., which all might want to use this API, it's potentially many different forms of UI for untrusted notifications---where do they go, how is it clear where they came from? Compare that to a single place outside the browser, with a clear source displayed, once trust is established. I prefer the latter. You probably need different permission UI regardless. E.g. on mobile browsers you might not show the notification in-tab but would only something if the user did something in response to a dialog. I've thought about this some more, and I'm not at all convinced that in-tab notification support is the right way to go. It seems that in-tab notifications are a solved problem already (in a few lines of code an app can create a floating div with whatever content it desires) with the advantage that the web app can display that notification in a way that is consistent with the UI in the site (set the notification so as not to interfere with site content, appropriately style the notification so it fits in with the look of the site, etc). I don't quite understand what browser-provided in-tab notifications would provide that would be an improvement over existing functionality. In the case the first notification from an application is an important one, that app should be able to request permission for out-of-tab notifications beforehand; Aren't notifications by nature somewhat non-important? In any event, we could expose to the application whether or not it was displayed and if it was not the application could pick an alternative route to convey the information. I'd say exactly the opposite - that's why we proactively display them to the user rather than leave them passively within the page waiting for the user to go look at them. for that reason I'm convinced requestPermission() is desirable. However beyond that, perhaps the spec should be flexible; if a UA wants to treat PERMISSION_UNKNOWN as show in-tab rather than throw exception, the spec could allow it -- but I don't think it should require it. Would that be acceptable? I'm not convinced we need a permission API and would therefore rather leave it out to see if we can do without. We do not have an API like this anymore else. We do have permissions UI in other parts of HTML5 (geolocation, for example). The difference here is that applications generally would like the user to make a permission grant *before* they actually want to display a notification - actually waiting until it's time to display a calendar reminder before the user is prompted for permission means that the user is likely to miss that first calendar event. One possible alternative to an explicit requestPermission() API would be to instead just have the browser display permissions UI the first time the user calls createNotification(). An application that wants to get permission in advance could just call createNotification(), but then never actually call show() (or, perhaps they could just display a confirmation notification like Desktop notifications are now enabled for FooMail). As someone who has integrated notifications into a web app, I have to say that I found the explicit API useful, but I'm not currently using the callback for requestPermission() so an alternate API could work so long as there was some way to initiate a permission grant without actually displaying a notification. -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
On Fri, 05 Feb 2010 19:19:24 +0100, Drew Wilson atwil...@google.com wrote: I've thought about this some more, and I'm not at all convinced that in-tab notification support is the right way to go. It seems that in-tab notifications are a solved problem already (in a few lines of code an app can create a floating div with whatever content it desires) with the advantage that the web app can display that notification in a way that is consistent with the UI in the site (set the notification so as not to interfere with site content, appropriately style the notification so it fits in with the look of the site, etc). I don't quite understand what browser-provided in-tab notifications would provide that would be an improvement over existing functionality. Allowing them to be displayed there and not having an active permission dialog would make it totally opaque to the application whether or not it can do system-wide notifications. This seems better for privacy and I also think it makes it less likely the user opts into something the user does not want. I'm not convinced we need a permission API and would therefore rather leave it out to see if we can do without. We do not have an API like this anymore else. We do have permissions UI in other parts of HTML5 (geolocation, for example). The difference here is that applications generally would like the user to make a permission grant *before* they actually want to display a notification - actually waiting until it's time to display a calendar reminder before the user is prompted for permission means that the user is likely to miss that first calendar event. One possible alternative to an explicit requestPermission() API would be to instead just have the browser display permissions UI the first time the user calls createNotification(). An application that wants to get permission in advance could just call createNotification(), but then never actually call show() (or, perhaps they could just display a confirmation notification like Desktop notifications are now enabled for FooMail). This sounds somewhat better to me. As someone who has integrated notifications into a web app, I have to say that I found the explicit API useful, but I'm not currently using the callback for requestPermission() so an alternate API could work so long as there was some way to initiate a permission grant without actually displaying a notification. I'm still a little bit afraid of what's going to happen when we get many of these APIs that need some kind of user permission. It's going to be too confusing I think. -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
On Fri, Feb 5, 2010 at 10:36 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 05 Feb 2010 19:19:24 +0100, Drew Wilson atwil...@google.com wrote: I've thought about this some more, and I'm not at all convinced that in-tab notification support is the right way to go. It seems that in-tab notifications are a solved problem already (in a few lines of code an app can create a floating div with whatever content it desires) with the advantage that the web app can display that notification in a way that is consistent with the UI in the site (set the notification so as not to interfere with site content, appropriately style the notification so it fits in with the look of the site, etc). I don't quite understand what browser-provided in-tab notifications would provide that would be an improvement over existing functionality. Allowing them to be displayed there and not having an active permission dialog would make it totally opaque to the application whether or not it can do system-wide notifications. This seems better for privacy and I also think it makes it less likely the user opts into something the user does not want. I'm not entirely convinced that opacity here is a good thing, especially since the alternative for apps that want this behavior would be: if (notifications.checkPermission() == PERMISSION_GRANTED) notifications.createNotification(icon, title, body); else jqueryUI.displayInTabNotification(icon, title, body); Or something similar. For an example, there is no value for something like a Calendar app to display in-tab event reminders. The whole point of event reminders is to notify the user of an upcoming event in a way that is visible when they are doing other tasks, but in a less-invasive way than an alert() but in-tab notifications would not provide this. Opacity here would work against the application's ability to provide the desired user flow which is to drive the user towards granting desktop notification permissions. I would rather have the application know that it can't display desktop notifications rather than silently defaulting to an unwanted user experience. I guess in summary, the main goal of having a notification API is to provide a way for web apps to display notifications to the user when the associated tab is not active. The application already has ways to display notifications to the user when the tab *is* active. It seems like the only reason to default to in-tab notifications is to jump through hoops to avoid an active permission grant UI (i.e. to have in-tab notifications with passive UI for making them out-of-tab) - no application actually wants in-tab notification functionality since they already have that. So I'm not convinced that avoiding an active permission grant should be a goal of this API, especially since there are a number of other APIs which implicitly have active permission grant UIs (geolocation, storage quota, etc). If a UA wants to avoid displaying active permission grants there are other ways for them to do it without in-tab notifications (they could display a pending notification icon in the tab chrome, etc) - perhaps removing requestPermission() would provide the flexibility to allow UAs to do this if that's what they want? I'm not convinced we need a permission API and would therefore rather leave it out to see if we can do without. We do not have an API like this anymore else. We do have permissions UI in other parts of HTML5 (geolocation, for example). The difference here is that applications generally would like the user to make a permission grant *before* they actually want to display a notification - actually waiting until it's time to display a calendar reminder before the user is prompted for permission means that the user is likely to miss that first calendar event. One possible alternative to an explicit requestPermission() API would be to instead just have the browser display permissions UI the first time the user calls createNotification(). An application that wants to get permission in advance could just call createNotification(), but then never actually call show() (or, perhaps they could just display a confirmation notification like Desktop notifications are now enabled for FooMail). This sounds somewhat better to me. As someone who has integrated notifications into a web app, I have to say that I found the explicit API useful, but I'm not currently using the callback for requestPermission() so an alternate API could work so long as there was some way to initiate a permission grant without actually displaying a notification. I'm still a little bit afraid of what's going to happen when we get many of these APIs that need some kind of user permission. It's going to be too confusing I think. I agree and there have been similar concerns expressed about permissions explosions elsewhere. I suspect the HTML standards community will need to look at how to bulk-manage
Re: Notifications
On Fri, Feb 5, 2010 at 10:19 AM, Drew Wilson atwil...@google.com wrote: One possible alternative to an explicit requestPermission() API would be to instead just have the browser display permissions UI the first time the user calls createNotification(). An application that wants to get permission in advance could just call createNotification(), but then never actually call show() (or, perhaps they could just display a confirmation notification like Desktop notifications are now enabled for FooMail). As someone who has integrated notifications into a web app, I have to say that I found the explicit API useful, but I'm not currently using the callback for requestPermission() so an alternate API could work so long as there was some way to initiate a permission grant without actually displaying a notification. This (permission request on first-use) was discussed before. The concern was that if we are going to have a permissions flow, it should be user-initiated, or the site will have the ability to annoy the user by popping up unsolicited browser UI. For this reason the spec requires a user gesture to call requestPermission(). If we request permission on first use, we again allow unsolicited permission dialogs, which I think is bad. -John
Re: Notifications
On Wed, Feb 3, 2010 at 9:55 AM, Olli Pettay olli.pet...@helsinki.fi wrote: Hi all, some random comments about http://dev.w3.org/2006/webapi/WebNotifications/publish/ (I didn't know that the draft existed until the link was mentioned in an email to @whatwg mailing list :/ ) Hi Olli, I was hoping to get some more work in on the draft before officially sending it out for feedback, but since there is interest out there it's time to start ramping it up. Thanks for the comments! NotificationCenter is a bit strange. Why do we need a separate interface for this? I'd rather added createNotification to window object, or to .screen. The idea was to have a common place to manage notification permissions as well as create notifications. That would end up with a lot of notifications-specific items on the window object. createNotification and createHTMLNotification could be merged. Based on the parameters UA could create a bit different kinds of notifications. Or depending on what kind of resources get loaded. PERMISSION_NOT_ALLOWED vs. PERMISSION_DENIED The naming should be better. Maybe PERMISSION_UNKNOWN and PERMISSION_DENIED ? That sounds reasonable to me, I'll make that change. requestPermission talks about user gesture, but doesn't define what an user gesture actually is. I thought the term was well known, but I will find a suitable reference. If createNotification would be in .screen or in window, then perhaps rename other methods to .requestNotificationPermission() and .checkNotificationPermission() those are a bit long ones, but still shorter than .notifications.requestPermission() As mentioned above, I think it's a good trade of 2 extra characters to put these things in a common place; it also makes it more easy for an author to check if (window.notifications === undefined). Why the need for notifications in a worker? In which screen would the notification show up? I would leave that out of the draft. Worker can easily send some message to window to ask for a notification. The thought is that a shared worker would be a good place to generate notifications for a multi-tab application, while avoiding duplicate alerts. If we require it to find a window, it has to keep track of which windows are open. As that set may change, I don't think it's as easy as allowing direct access to the API. How does create(HTML)Notification actually work. At which point does it load the external resources? At which point is display event dispatched? When showing the notification? But what if the external HTML file or icon file isn't loaded yet? I will make this more specific in the draft: create[HTML]Notification should not load the necessary resources until it is about to be displayed (in case of a queue). Once it is at the top of the queue, it should: - load its resources as if opening a new window - dispatch the display event - show itself on the screen The function provided in the callback parameter will be invoked when the user has responded to the permission request. The IDL doesn't show any callback parameter. Quite right -- will fix.
Re: Notifications
Following up on breaking out createHTMLNotification() and createNotification() vs combining them into one large API - I believe the intent is that a given user agent may not support all types of notifications (for example, a mobile phone application may only support text + icon notifications, not HTML notifications). Having these APIs broken out separately allows the UA to communicate whether it supports one or the other to the web app (a UA that does not support HTML notifications would leave createHTMLNotification() undefined). -atw On Wed, Feb 3, 2010 at 10:33 AM, John Gregg john...@google.com wrote: On Wed, Feb 3, 2010 at 9:55 AM, Olli Pettay olli.pet...@helsinki.fiwrote: Hi all, some random comments about http://dev.w3.org/2006/webapi/WebNotifications/publish/ (I didn't know that the draft existed until the link was mentioned in an email to @whatwg mailing list :/ ) Hi Olli, I was hoping to get some more work in on the draft before officially sending it out for feedback, but since there is interest out there it's time to start ramping it up. Thanks for the comments! NotificationCenter is a bit strange. Why do we need a separate interface for this? I'd rather added createNotification to window object, or to .screen. The idea was to have a common place to manage notification permissions as well as create notifications. That would end up with a lot of notifications-specific items on the window object. createNotification and createHTMLNotification could be merged. Based on the parameters UA could create a bit different kinds of notifications. Or depending on what kind of resources get loaded. PERMISSION_NOT_ALLOWED vs. PERMISSION_DENIED The naming should be better. Maybe PERMISSION_UNKNOWN and PERMISSION_DENIED ? That sounds reasonable to me, I'll make that change. requestPermission talks about user gesture, but doesn't define what an user gesture actually is. I thought the term was well known, but I will find a suitable reference. If createNotification would be in .screen or in window, then perhaps rename other methods to .requestNotificationPermission() and .checkNotificationPermission() those are a bit long ones, but still shorter than .notifications.requestPermission() As mentioned above, I think it's a good trade of 2 extra characters to put these things in a common place; it also makes it more easy for an author to check if (window.notifications === undefined). Why the need for notifications in a worker? In which screen would the notification show up? I would leave that out of the draft. Worker can easily send some message to window to ask for a notification. The thought is that a shared worker would be a good place to generate notifications for a multi-tab application, while avoiding duplicate alerts. If we require it to find a window, it has to keep track of which windows are open. As that set may change, I don't think it's as easy as allowing direct access to the API. How does create(HTML)Notification actually work. At which point does it load the external resources? At which point is display event dispatched? When showing the notification? But what if the external HTML file or icon file isn't loaded yet? I will make this more specific in the draft: create[HTML]Notification should not load the necessary resources until it is about to be displayed (in case of a queue). Once it is at the top of the queue, it should: - load its resources as if opening a new window - dispatch the display event - show itself on the screen The function provided in the callback parameter will be invoked when the user has responded to the permission request. The IDL doesn't show any callback parameter. Quite right -- will fix.
Re: Notifications
On Wed, Feb 3, 2010 at 10:33 AM, John Gregg john...@google.com wrote: On Wed, Feb 3, 2010 at 9:55 AM, Olli Pettay olli.pet...@helsinki.fiwrote: Hi all, some random comments about http://dev.w3.org/2006/webapi/WebNotifications/publish/ (I didn't know that the draft existed until the link was mentioned in an email to @whatwg mailing list :/ ) Hi Olli, I was hoping to get some more work in on the draft before officially sending it out for feedback, but since there is interest out there it's time to start ramping it up. Thanks for the comments! NotificationCenter is a bit strange. Why do we need a separate interface for this? I'd rather added createNotification to window object, or to .screen. The idea was to have a common place to manage notification permissions as well as create notifications. That would end up with a lot of notifications-specific items on the window object. Agreed. And there is precedent for this. (AppCache, WebStorage, IndexedDB I know off the top of my head.) createNotification and createHTMLNotification could be merged. Based on the parameters UA could create a bit different kinds of notifications. Or depending on what kind of resources get loaded. PERMISSION_NOT_ALLOWED vs. PERMISSION_DENIED The naming should be better. Maybe PERMISSION_UNKNOWN and PERMISSION_DENIED ? That sounds reasonable to me, I'll make that change. requestPermission talks about user gesture, but doesn't define what an user gesture actually is. I thought the term was well known, but I will find a suitable reference. If createNotification would be in .screen or in window, then perhaps rename other methods to .requestNotificationPermission() and .checkNotificationPermission() those are a bit long ones, but still shorter than .notifications.requestPermission() As mentioned above, I think it's a good trade of 2 extra characters to put these things in a common place; it also makes it more easy for an author to check if (window.notifications === undefined). Why the need for notifications in a worker? In which screen would the notification show up? I would leave that out of the draft. Worker can easily send some message to window to ask for a notification. The thought is that a shared worker would be a good place to generate notifications for a multi-tab application, while avoiding duplicate alerts. If we require it to find a window, it has to keep track of which windows are open. As that set may change, I don't think it's as easy as allowing direct access to the API. Agreed. Having a shared worker that doesn't need to worry about races with shutting down windows seems like a big win. Olli, do you foresee any problems with allowing access from workers?
Re: Notifications
On 2/3/10 8:33 PM, John Gregg wrote: I will make this more specific in the draft: create[HTML]Notification should not load the necessary resources until it is about to be displayed (in case of a queue). Once it is at the top of the queue, it should: - load its resources as if opening a new window - dispatch the display event - show itself on the screen Does it wait for all the resources to load before dispatching display event? What if loading resources takes lots of time? Since notification is pretty much like a new window, why the need for new display event. Perhaps the event name could be just usual load. -Olli
Re: Notifications
On 2/3/10 8:55 PM, Jeremy Orlow wrote: Agreed. Having a shared worker that doesn't need to worry about races with shutting down windows seems like a big win. Olli, do you foresee any problems with allowing access from workers? In a multiscreen environment worker can't define which screen to use. That seems to be a pretty major problem, IMO. -Olli
Re: Notifications
I will make this more specific in the draft: create[HTML]Notification should not load the necessary resources until it is about to be displayed (in case of a queue). Once it is at the top of the queue, it should: - load its resources as if opening a new window - dispatch the display event - show itself on the screen Does it wait for all the resources to load before dispatching display event? What if loading resources takes lots of time? Since notification is pretty much like a new window, why the need for new display event. Perhaps the event name could be just usual load. I have no particular attachment to the name, but would prefer to be agnostic as to the presentation for non-HTML notifications. Leaving open the possibility that a user-agent routes this API to a third-party text+icon notification library, it's not a window and it's a different notion than load; it's just the notification being displayed to the user.
Re: Notifications
On Wed, Feb 3, 2010 at 10:58 AM, Olli Pettay olli.pet...@helsinki.fiwrote: On 2/3/10 8:55 PM, Jeremy Orlow wrote: Agreed. Having a shared worker that doesn't need to worry about races with shutting down windows seems like a big win. Olli, do you foresee any problems with allowing access from workers? In a multiscreen environment worker can't define which screen to use. That seems to be a pretty major problem, IMO. You could use whatever screen the window the worker is attached to is on. And if the worker is a shared worker used by windows on multiple screens, you could either pick one or send it to both...right? J
Re: Notifications
On Wed, Feb 3, 2010 at 10:55 AM, Olli Pettay olli.pet...@helsinki.fiwrote: On 2/3/10 8:33 PM, John Gregg wrote: I will make this more specific in the draft: create[HTML]Notification should not load the necessary resources until it is about to be displayed (in case of a queue). Once it is at the top of the queue, it should: - load its resources as if opening a new window - dispatch the display event - show itself on the screen Does it wait for all the resources to load before dispatching display event? What if loading resources takes lots of time? I think that will be fine even if it takes lots of time. Since it also waits until resources are loaded before displaying the notification, the display event and the actual display will essentially coincide. I should probably clarify that by loading resources I mean loading the URL supplied to createHTMLNotification or the URL supplied for the icon to createNotification. If the HTML requires sub-resources, those could be loaded after the display.
Re: Notifications
That's true in general about any UI the worker may display (HTTP Auth, Certificate errors, etc) - the UA generally picks a parent document on behalf of the worker and displays the UI on the associated screen. If the client cares about which screen specifically it's displaying on (because it has parent windows spread across multiple screens?), it can try to route things back through a specific window itself - providing this API from worker context does nothing to prevent that and it's a huge convenience for the overwhelming majority of uses. -atw On Wed, Feb 3, 2010 at 10:58 AM, Olli Pettay olli.pet...@helsinki.fiwrote: On 2/3/10 8:55 PM, Jeremy Orlow wrote: Agreed. Having a shared worker that doesn't need to worry about races with shutting down windows seems like a big win. Olli, do you foresee any problems with allowing access from workers? In a multiscreen environment worker can't define which screen to use. That seems to be a pretty major problem, IMO. -Olli
Re: Notifications
On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay olli.pet...@helsinki.fi wrote: NotificationCenter is a bit strange. Why do we need a separate interface for this? I'd rather added createNotification to window object, or to .screen. Shouldn't it be on navigator? We use navigator for other device-related APIs as well, e.g. onLine and registerProtocolHandler(). -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
On Wed, 03 Feb 2010 19:54:44 +0100, Drew Wilson atwil...@google.com wrote: Following up on breaking out createHTMLNotification() and createNotification() vs combining them into one large API - I believe the intent is that a given user agent may not support all types of notifications (for example, a mobile phone application may only support text + icon notifications, not HTML notifications). Having these APIs broken out separately allows the UA to communicate whether it supports one or the other to the web app (a UA that does not support HTML notifications would leave createHTMLNotification() undefined). 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.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
On Wed, Feb 3, 2010 at 11:38 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay olli.pet...@helsinki.fi wrote: NotificationCenter is a bit strange. Why do we need a separate interface for this? I'd rather added createNotification to window object, or to .screen. Shouldn't it be on navigator? We use navigator for other device-related APIs as well, e.g. onLine and registerProtocolHandler(). It seems as though there are currently a lot of device related APIs in the pipeline (especially in the DAP WG). Are you suggesting that navigator be a dumping ground for all of them? Like I said in a response to Olli's original email, there's precedent for creating an object that hangs off DOMWindow. Is there any reason you're against this? Also note that checking to see whether window.notifiactions exists seems like a very nice way for consumers of the API to check whether it's available. J
Re: Notifications
I'm not entirely certain I understand this suggestion - is this just a
change to the spec language, or does it impact the actual API (i.e. would
webapps still do the following):
if ('createHTMLNotifications' in window.notifications) {
...html notifications exist...
}
Or are you proposing something else?
Since these APIs are available in Chrome currently (as the experimental
window.webkitNotifications API), there's no reason for us to debate the
utility of HTML notifications in the abstract when we can get feedback from
application developers with real use cases. I've been running into some of
the limitations of the text + icon notifications in my recent work (one
example: the lack of an onclick event) which I'll try to write up sometime
in the near future.
-atw
On Wed, Feb 3, 2010 at 11:41 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Feb 2010 19:54:44 +0100, Drew Wilson atwil...@google.com
wrote:
Following up on breaking out createHTMLNotification() and
createNotification() vs combining them into one large API - I believe the
intent is that a given user agent may not support all types of
notifications
(for example, a mobile phone application may only support text + icon
notifications, not HTML notifications). Having these APIs broken out
separately allows the UA to communicate whether it supports one or the
other
to the web app (a UA that does not support HTML notifications would leave
createHTMLNotification() undefined).
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.)
--
Anne van Kesteren
http://annevankesteren.nl/
Re: Notifications
On Wed, Feb 3, 2010 at 11:41 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 03 Feb 2010 19:54:44 +0100, Drew Wilson atwil...@google.com wrote: Following up on breaking out createHTMLNotification() and createNotification() vs combining them into one large API - I believe the intent is that a given user agent may not support all types of notifications (for example, a mobile phone application may only support text + icon notifications, not HTML notifications). Having these APIs broken out separately allows the UA to communicate whether it supports one or the other to the web app (a UA that does not support HTML notifications would leave createHTMLNotification() undefined). 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?) 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. 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. -John
Re: Notifications
On Wed, 03 Feb 2010 21:04:06 +0100, John Gregg john...@google.com wrote:
On Wed, Feb 3, 2010 at 11:41 AM, Anne van Kesteren ann...@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/
Re: Notifications
On Wed, 03 Feb 2010 20:52:18 +0100, Jeremy Orlow jor...@chromium.org wrote: On Wed, Feb 3, 2010 at 11:38 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay olli.pet...@helsinki.fi wrote: NotificationCenter is a bit strange. Why do we need a separate interface for this? I'd rather added createNotification to window object, or to .screen. Shouldn't it be on navigator? We use navigator for other device-related APIs as well, e.g. onLine and registerProtocolHandler(). It seems as though there are currently a lot of device related APIs in the pipeline (especially in the DAP WG). Are you suggesting that navigator be a dumping ground for all of them? I have argued that, yes. (Though within bounds, e.g. the device proposal makes sense and the REST approach for certain APIs does too.) Like I said in a response to Olli's original email, there's precedent for creating an object that hangs off DOMWindow. Is there any reason you're against this? Yes, polluting the global object further. Also, there is precedent for hanging off APIs on navigator too, in particular APIs that have something to do with the platform. Also note that checking to see whether window.notifiactions exists seems like a very nice way for consumers of the API to check whether it's available. if(navigator.createNotification) does not seem much worse. -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay olli.pet...@helsinki.fi wrote: some random comments about http://dev.w3.org/2006/webapi/WebNotifications/publish/ (I didn't know that the draft existed until the link was mentioned in an email to @whatwg mailing list :/ ) Some other thoughts on this API: * It would be nice if we could avoid the exception somehow. Maybe just have an error callback? * I'm not a big fan of introducing two new ways to load resources as proposed in this API. We are not doing that elsewhere either (consider e.g. drawImage()). Passing a Document and HTMLImageElement (potentially HTMLCanvasElement and HTMLVideoElement too I suppose) would make more sense. This does create some additional burden on the developer but it does keep security-sensitive operations more limited and also gives the ability for greater control and information. (E.g. with XMLHttpRequest you get to know how fast the resource is being fetched, etc.) Libraries could provide the higher-level API. * If we keep checkPermission() it should not be a method. But I'm not sure it is needed if there is an error callback. -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
On Wed, Feb 3, 2010 at 1:22 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay olli.pet...@helsinki.fi wrote: some random comments about http://dev.w3.org/2006/webapi/WebNotifications/publish/ (I didn't know that the draft existed until the link was mentioned in an email to @whatwg mailing list :/ ) Some other thoughts on this API: * It would be nice if we could avoid the exception somehow. Maybe just have an error callback? I thought that in practice the exception was reasonable, specifically because the exception is entirely avoidable because you can check permission before calling any protected APIs. I would rather have an explicit failure in case of bugs (and calling createNotification() without getting permission first is a bug) rather than a silent failure. Perhaps I'm misunderstanding what you are suggesting - are you talking about the exception thrown from requestPermission() or the exception thrown from createNotification()? * I'm not a big fan of introducing two new ways to load resources as proposed in this API. We are not doing that elsewhere either (consider e.g. drawImage()). Passing a Document and HTMLImageElement (potentially HTMLCanvasElement and HTMLVideoElement too I suppose) would make more sense. This does create some additional burden on the developer but it does keep security-sensitive operations more limited and also gives the ability for greater control and information. (E.g. with XMLHttpRequest you get to know how fast the resource is being fetched, etc.) Libraries could provide the higher-level API. I see createHTMLNotification() as akin to window.open() - it doesn't really increase the attack surface. I'm not sure I completely understand the suggestion of passing in a Document object - what would that API look like? Since an HTML notification is (effectively) a separate window, it just seems like tracking progress for the loading of resources is a solved problem for app developers - Gmail displays a loading bar while its window loads. I suspect I'm not understanding your use case entirely though. * If we keep checkPermission() it should not be a method. But I'm not sure it is needed if there is an error callback. I think that we need some way to get the current permission but I agree that an attribute would be better than an API call. I'm not sure that an error callback from createNotification() is sufficient as you generally want to initiate the permission grant *in advance* of displaying notifications. As an example, allow me to describe the following use case: A web mail program would like to display desktop notifications when new mail arrives. Because UAs require calls to requestPermission() to be in the context of a user gesture, I need to display some UI along the lines of click here to enable desktop notifications for new mail, which, when clicked upon, results in the web app calling requestPermission() to initiate the permission grant from the UA. I only want to display this UI if the user has not already been granted/denied permission (once he's responded to the permission grant dialog, I no longer want to display this UI in future loads of the program). Without a checkPermission()-type API (or permission attribute) there's no way for me to achieve this user flow. -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
On Wed, Feb 3, 2010 at 1:22 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay olli.pet...@helsinki.fi wrote: some random comments about http://dev.w3.org/2006/webapi/WebNotifications/publish/ (I didn't know that the draft existed until the link was mentioned in an email to @whatwg mailing list :/ ) Some other thoughts on this API: * It would be nice if we could avoid the exception somehow. Maybe just have an error callback? I'm neutral on that. If the preferred convention is to use an error callback instead of an exception, Web Notifications should do the same. * I'm not a big fan of introducing two new ways to load resources as proposed in this API. We are not doing that elsewhere either (consider e.g. drawImage()). Passing a Document and HTMLImageElement (potentially HTMLCanvasElement and HTMLVideoElement too I suppose) would make more sense. This does create some additional burden on the developer but it does keep security-sensitive operations more limited and also gives the ability for greater control and information. (E.g. with XMLHttpRequest you get to know how fast the resource is being fetched, etc.) Libraries could provide the higher-level API. Having the site construct the Document seems like it adds a lot of complexity for the developer. Another concern is that the notification resources don't need to be loaded immediately in the case of a queue. If a notification is queued and then canceled before being displayed, that resource load can be avoided. * If we keep checkPermission() it should not be a method. But I'm not sure it is needed if there is an error callback. Yes, this makes sense; I am changing the draft spec to have a permissionLevel attribute. I think having access to the permission level is important for the same reasons as Drew gave: the site should know whether to display permissions UI in advance of having a notification to show. -John
Re: Notifications
On Wed, 03 Feb 2010 23:40:23 +0100, John Gregg john...@google.com wrote: Yes, this makes sense; I am changing the draft spec to have a permissionLevel attribute. I think having access to the permission level is important for the same reasons as Drew gave: the site should know whether to display permissions UI in advance of having a notification to show. The design Hixie once made for notifications was much nicer I thought. Initially you would get tab-scoped in-browser notifications but the user could opt-in (maybe when the first of such notifications was shown) into system-wide notifications. The application would not have to know either way and the user is not forced to click through permission dialog in order to see something. It's still available in one of the older copies of HTML5: http://www.w3.org/TR/2008/WD-html5-20080610/web-browsers.html#notifications (The comparison with window.open() from Drew made sense to me by the way, though whether the same is applicable to icons I'm less sure of.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
On Wed, Feb 3, 2010 at 2:50 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 03 Feb 2010 23:40:23 +0100, John Gregg john...@google.com wrote: Yes, this makes sense; I am changing the draft spec to have a permissionLevel attribute. I think having access to the permission level is important for the same reasons as Drew gave: the site should know whether to display permissions UI in advance of having a notification to show. The design Hixie once made for notifications was much nicer I thought. Initially you would get tab-scoped in-browser notifications but the user could opt-in (maybe when the first of such notifications was shown) into system-wide notifications. The application would not have to know either way and the user is not forced to click through permission dialog in order to see something. It's still available in one of the older copies of HTML5: http://www.w3.org/TR/2008/WD-html5-20080610/web-browsers.html#notifications That's an interesting option (fallback to in-tab display if the parent context does not have permission). BTW, I'd note that supporting this would not preclude continuing to provide a way for an app to explicitly request a permission grant, as a way for guiding users to setup the app as a trusted notification source. The alternative would be for applications to have UA-specific directions directing the user to click on specific items in the UA chrome (If you want new mail notifications to appear on your desktop, click on the smiley face in the notification titlebar) which is a more clunky user flow. -atw
