Re: [whatwg] Notification API
On Wed, Feb 3, 2010 at 12:55, Henri Sivonen hsivo...@iki.fi wrote: It seems to me that Growl and NotifyOSD notifications have these things in common: 4) Ability to find out if the user clicked the notification. (Not yet in Karmic?) You can't click on a NotifyOSD notification by design. It's supposed to disappear or become translucent when you hover over it, so you can click behind it. -- Remco
Re: [whatwg] Notification API
The Webapps WG is working on a spec for a Web Notification API. You can see the current draft at http://dev.w3.org/2006/webapi/WebNotifications/publish/, and I would suggest sending comments to the public-webapps mailing list. That spec attempts to address the icon+title+text use case, and allows a user agent to use a third party presentation system as long as that system can notify of notifications being acknowledged, but also allows HTML as an option if the device supports it. I disagree with the claim that HTML notifications are overkill as long as they can be done securely, it opens up a lot of benefit to have dynamic interactive notifications. Even for the simple case of Calendar reminders which might have multiple forms of acknowledgement: snooze for N minutes (a select would be nice), or dismiss. Thanks, -John On Wed, Feb 3, 2010 at 3:55 AM, Henri Sivonen hsivo...@iki.fi wrote: I noticed that there's a Chromium-specific API for notifications: http://dev.chromium.org/developers/design-documents/desktop-notifications/api-specification Opera has an Opera Widgets-specific API: http://dev.opera.com/articles/view/opera-widgets-specification-fourth-ed/#wo_showNotification What's the right mailing list for discussing notification APIs? Since the right people are likely reading this list: It seems to me that it would be desirable to have an API that authorized Web apps can use to post notifications to Growl (Mac) or NotifyOSD (Ubuntu). HTML notifications look like an overkill to me. It seems to me that Growl and NotifyOSD notifications have these things in common: 1) Title 2) Description 3) Icon 4) Ability to find out if the user clicked the notification. (Not yet in Karmic?) To map that to a really simply Web API, a single method with four arguments could be added to the navigator object. The arguments would be: 1) DOMString title (required) 2) DOMString description (optional, LF means rendered line break) 3) DOMString iconURL (optional, defaults to the favicon of the root browsing context of the script invoking the API) 4) function acknowledgement (optional, callback that is called if the user clicks the notification; clicking should always bring the window/tab of the page that invoked the notification to front) Does Chromium have use cases for HTML notifications that wouldn't be addressed by the simpler API outlined above? Does Opera have a reason for not allowing an icon and two distinct strings in notifications? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Notification API
On Thu, Feb 4, 2010 at 6:17 AM, John Gregg john...@google.com wrote: The Webapps WG is working on a spec for a Web Notification API. You can see the current draft at http://dev.w3.org/2006/webapi/WebNotifications/publish/, and I would suggest sending comments to the public-webapps mailing list. That spec attempts to address the icon+title+text use case, and allows a user agent to use a third party presentation system as long as that system can notify of notifications being acknowledged, but also allows HTML as an option if the device supports it. I disagree with the claim that HTML notifications are overkill as long as they can be done securely, it opens up a lot of benefit to have dynamic interactive notifications. Even for the simple case of Calendar reminders which might have multiple forms of acknowledgement: snooze for N minutes (a select would be nice), or dismiss. If the underlying platform notification system (e.g. Growl or libnotification) doesn't support that functionality, how should the UA behave? I suppose the UA could distinguish between notifications that can be supported by the platform and those that can't, and use the platform notification system when possible, otherwise fall back to its own notifications, but that could be a jarring user experience. 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: [whatwg] Notification API
On Wed, Feb 3, 2010 at 12:27 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 4, 2010 at 6:17 AM, John Gregg john...@google.com wrote: The Webapps WG is working on a spec for a Web Notification API. You can see the current draft at http://dev.w3.org/2006/webapi/WebNotifications/publish/, and I would suggest sending comments to the public-webapps mailing list. That spec attempts to address the icon+title+text use case, and allows a user agent to use a third party presentation system as long as that system can notify of notifications being acknowledged, but also allows HTML as an option if the device supports it. I disagree with the claim that HTML notifications are overkill as long as they can be done securely, it opens up a lot of benefit to have dynamic interactive notifications. Even for the simple case of Calendar reminders which might have multiple forms of acknowledgement: snooze for N minutes (a select would be nice), or dismiss. If the underlying platform notification system (e.g. Growl or libnotification) doesn't support that functionality, how should the UA behave? I suppose the UA could distinguish between notifications that can be supported by the platform and those that can't, and use the platform notification system when possible, otherwise fall back to its own notifications, but that could be a jarring user experience. The spec states that HTML is an optional part of the implementation. If the UA intends to use a presentation system that doesn't support HTML it should not expose the HTML API and just expose the plain one. This isn't ideal as it requires authors to check the capabilities of the UA, but it does provide consistency for the user. -John
Re: [whatwg] Notification API
BTW, I would highly recommend that we move this conversation to the public-webapps list. I'm not sure about the best way to do this other than to stop posting here, starting...um...right after my reply :) Anyhow, your question below outlines is why there are two exposed notification APIs - one is simple, lowest-common-denominator text + icon notifications (createNotification()), and the other is HTML (createHTMLNotification()). Platforms (such as mobile devices) that can't support popup HTML notifications can just not expose the createHTMLNotification attribute. Likewise, if the user on a given system just wants to force everyone to use text + icon notifications because he finds the mix of (say) Growl and HTML notifications jarring, then the UA could provide an option for that (which would cause the UA to not expose the createHTMLNotification attribute). -atw On Wed, Feb 3, 2010 at 12:27 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 4, 2010 at 6:17 AM, John Gregg john...@google.com wrote: The Webapps WG is working on a spec for a Web Notification API. You can see the current draft at http://dev.w3.org/2006/webapi/WebNotifications/publish/, and I would suggest sending comments to the public-webapps mailing list. That spec attempts to address the icon+title+text use case, and allows a user agent to use a third party presentation system as long as that system can notify of notifications being acknowledged, but also allows HTML as an option if the device supports it. I disagree with the claim that HTML notifications are overkill as long as they can be done securely, it opens up a lot of benefit to have dynamic interactive notifications. Even for the simple case of Calendar reminders which might have multiple forms of acknowledgement: snooze for N minutes (a select would be nice), or dismiss. If the underlying platform notification system (e.g. Growl or libnotification) doesn't support that functionality, how should the UA behave? I suppose the UA could distinguish between notifications that can be supported by the platform and those that can't, and use the platform notification system when possible, otherwise fall back to its own notifications, but that could be a jarring user experience. 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: [whatwg] Notification API
On Wed, Feb 3, 2010 at 1:00 PM, John Gregg john...@google.com wrote: On Wed, Feb 3, 2010 at 12:27 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Feb 4, 2010 at 6:17 AM, John Gregg john...@google.com wrote: The Webapps WG is working on a spec for a Web Notification API. You can see the current draft at http://dev.w3.org/2006/webapi/WebNotifications/publish/, and I would suggest sending comments to the public-webapps mailing list. That spec attempts to address the icon+title+text use case, and allows a user agent to use a third party presentation system as long as that system can notify of notifications being acknowledged, but also allows HTML as an option if the device supports it. I disagree with the claim that HTML notifications are overkill as long as they can be done securely, it opens up a lot of benefit to have dynamic interactive notifications. Even for the simple case of Calendar reminders which might have multiple forms of acknowledgement: snooze for N minutes (a select would be nice), or dismiss. If the underlying platform notification system (e.g. Growl or libnotification) doesn't support that functionality, how should the UA behave? I suppose the UA could distinguish between notifications that can be supported by the platform and those that can't, and use the platform notification system when possible, otherwise fall back to its own notifications, but that could be a jarring user experience. The spec states that HTML is an optional part of the implementation. If the UA intends to use a presentation system that doesn't support HTML it should not expose the HTML API and just expose the plain one. This isn't ideal as it requires authors to check the capabilities of the UA, but it does provide consistency for the user. This is a very bad idea. Sites are going to forget to do this, or rather not know that they need to do this. At some point a high-profile site is going to not do this check, and from that point on all UAs will effectively be forced to support HTML notifications or not be compatible with the web. I can't think of a single time when optional web features have succeeded. / Jonas
Re: [whatwg] Notification API
Apps on the iphone using SQL data storage might disagree with you about the value of optional web features :) But I do understand your point, and perhaps there's a better way to achieve the goals of the notification API. The goals as I understand them are: 1) Support simple text + icon notifications on devices that are unable to support full HTML notifications (I'm thinking of mobile devices specifically, such as the Palm Pre which exposes a similar JS notification API, but some system notification frameworks also fall under this category). 2) Allow more full-featured HTML notifications on the overwhelming majority of platforms that support them. 3) Give web applications the ability to tell whether a given UA supports HTML notifications so they can choose not to display any notification at all if the system does not support HTML. A corollary to #3 may be that a given UA could make it possible for the user to disable HTML notifications even though they would theoretically be possible to support on that platform, if it is believed that there are user benefits to only allowing text + icon notifications on that specific installation (e.g. tighter integration with system notification frameworks). It's possible that Goal #3 is unimportant, or that it could be satisfied through some other mechanism (like a capabilities attribute? ick?) - if so, then it seems like an option to fold createNotification() and createHTMLNotification() together by adding an optional htmlUrl parameter to createNotification() which would be ignored on systems that don't want to display HTML notifications. -atw On Wed, Feb 3, 2010 at 1:27 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 3, 2010 at 1:00 PM, John Gregg john...@google.com wrote: On Wed, Feb 3, 2010 at 12:27 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Feb 4, 2010 at 6:17 AM, John Gregg john...@google.com wrote: The Webapps WG is working on a spec for a Web Notification API. You can see the current draft at http://dev.w3.org/2006/webapi/WebNotifications/publish/, and I would suggest sending comments to the public-webapps mailing list. That spec attempts to address the icon+title+text use case, and allows a user agent to use a third party presentation system as long as that system can notify of notifications being acknowledged, but also allows HTML as an option if the device supports it. I disagree with the claim that HTML notifications are overkill as long as they can be done securely, it opens up a lot of benefit to have dynamic interactive notifications. Even for the simple case of Calendar reminders which might have multiple forms of acknowledgement: snooze for N minutes (a select would be nice), or dismiss. If the underlying platform notification system (e.g. Growl or libnotification) doesn't support that functionality, how should the UA behave? I suppose the UA could distinguish between notifications that can be supported by the platform and those that can't, and use the platform notification system when possible, otherwise fall back to its own notifications, but that could be a jarring user experience. The spec states that HTML is an optional part of the implementation. If the UA intends to use a presentation system that doesn't support HTML it should not expose the HTML API and just expose the plain one. This isn't ideal as it requires authors to check the capabilities of the UA, but it does provide consistency for the user. This is a very bad idea. Sites are going to forget to do this, or rather not know that they need to do this. At some point a high-profile site is going to not do this check, and from that point on all UAs will effectively be forced to support HTML notifications or not be compatible with the web. I can't think of a single time when optional web features have succeeded. / Jonas
Re: [whatwg] Notification API
On Thu, Feb 4, 2010 at 11:34 AM, Drew Wilson atwil...@google.com wrote: 2) Allow more full-featured HTML notifications on the overwhelming majority of platforms that support them. Given that Mac and Linux don't support HTML notifications, what platforms are those? 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: [whatwg] Notification API
On Wed, Feb 3, 2010 at 3:18 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Feb 4, 2010 at 11:34 AM, Drew Wilson atwil...@google.com wrote: 2) Allow more full-featured HTML notifications on the overwhelming majority of platforms that support them. Given that Mac and Linux don't support HTML notifications, what platforms are those? Additionally, how full fledged HTML are we talking? Do you want script to be running in the notification? Should forms work? Plugins? HTML is a very powerful format, not really the best choice if all you need is some basic text formatting. / Jonas
Re: [whatwg] Notification API
On Wed, Feb 3, 2010 at 3:25 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 3, 2010 at 3:18 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Feb 4, 2010 at 11:34 AM, Drew Wilson atwil...@google.com wrote: 2) Allow more full-featured HTML notifications on the overwhelming majority of platforms that support them. Given that Mac and Linux don't support HTML notifications, what platforms are those? Additionally, how full fledged HTML are we talking? Do you want script to be running in the notification? Should forms work? Plugins? HTML is a very powerful format, not really the best choice if all you need is some basic text formatting. I was about to comment, but then I realized this is all on the wrong alias (whatwg instead of public-webapps) as Drew pointed out a little earlier. dave
