Re: Tags and origins (was: Re: Web Notifications)
On Wed, Jun 20, 2012 at 5:30 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jun 20, 2012 at 12:17 PM, Olli Pettay olli.pet...@helsinki.fi wrote: Seems like tags are global. I think they should be per origin. Yes I believe they should be. http://dvcs.w3.org/hg/notifications/rev/563e9af218b9 Thanks, This seems like an odd way to restore per-origin tags. Now tag means be either a string or a tuple depending on context. Can we either go back to the original language where in the showing algorithm you compare both tag and origin (add origin to the model), or rename the model context of tag to something more specific, perhaps even replace ID? -John
Re: Thoughts on WebNotification
On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner doug.tur...@gmail.com wrote: Hey Drew, I think this is too vague, as it's sounds like a user agent could *not* ignore markup in the string, and still be compliant with the spec. I think we need to be very explicit that the string *must* be treated as plain text. So if I pass in gt;bfoo/b as the body parameter to createNotification(), the resulting notification must display the string gt;bfoo/b, without stripping or converting any of the substrings that might look like HTML entities. Yup. we should tighten up the language. i think we are on the same page here. It's actually more complicated given the various platform behavior. While Growl doesn't interpret markup, NotifyOSD on linux does allow some markup in its notifications (lt; shows , for example) [1, section 5]. So it's not sufficient to just pass the string directly, it has to be escaped in order to present the exact text provided. So perhaps, the user agent must display the string as plain text, without interpreting markup; if using a notification platform which does interpret markup, the user agent should modify the string so that any markup is shown rather than interpreted. [1] https://wiki.ubuntu.com/NotificationDevelopmentGuidelines
Re: Thoughts on WebNotification
I'm happy with this course of action, but first I wanted to ask why not the gracefully degrade suggestion from the Notifications thread started on the 3rd of Feb. As far as I can tell, it was never seriously considered, but several of us brought it up. And I feel like it'd be a much better way forward than having a different interface for html based notifications and text notifications. (The basic idea was to accept either text or html and then if it's the latter and the notification scheme doesn't support it, we'd use some simple, specced heuristics to extract data to be used. In the thread, there were some specific ideas about how the transformations could work. But from a quick skim, I couldn't find any reasons why it was a bad idea.) J There were actually several ways considered to combine the interfaces: - We can a have a method createNotification(text, body, icon, URL) which uses the URL parameter if supported and text/body/icon parameters to be used as the backup if HTML content is not supported (I call this the alt text option). - We can allow the API to take a URL, load that resource and read some meta information from it, such as the title tag. (the title tag option). I prefer the alt text option between these two, because it is much simpler to implement for browsers that don't want to support HTML notifications and would also be better performing, since it doesn't require the resource load. -John
Re: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 8:56 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Jun 25, 2010 at 4:44 PM, John Gregg john...@google.com wrote: I'm happy with this course of action, but first I wanted to ask why not the gracefully degrade suggestion from the Notifications thread started on the 3rd of Feb. As far as I can tell, it was never seriously considered, but several of us brought it up. And I feel like it'd be a much better way forward than having a different interface for html based notifications and text notifications. (The basic idea was to accept either text or html and then if it's the latter and the notification scheme doesn't support it, we'd use some simple, specced heuristics to extract data to be used. In the thread, there were some specific ideas about how the transformations could work. But from a quick skim, I couldn't find any reasons why it was a bad idea.) J There were actually several ways considered to combine the interfaces: - We can a have a method createNotification(text, body, icon, URL) which uses the URL parameter if supported and text/body/icon parameters to be used as the backup if HTML content is not supported (I call this the alt text option). - We can allow the API to take a URL, load that resource and read some meta information from it, such as the title tag. (the title tag option). A third option would be to take raw HTML rather than a URL and compute the text version if necessary. Whenever the spec allows a URL for HTML notifications, I intend that data url is an option for developers who want to specify the HTML as a string. (Chrome supports this already, FYI.) Or did you mean to suggest that only local HTML would be allowed in the suggested API, not a remote URL? I prefer the alt text option between these two, because it is much simpler to implement for browsers that don't want to support HTML notifications and would also be better performing, since it doesn't require the resource load. The difficulty in implementation is much less important than difficulty in use is much less important than the difficulty in use. Although it seems that at least one mainstream browser will only implement the text conversion option and thus the alt text version probably won't be as neglected as alt text in an image (at least initially) and this is something we expect mostly advanced web developers will use, I still think it's a mistake to assume web developers will properly support both. So I would support #2 or my #3 much more than #1 which I would support more than Doug's original suggestion (for that reason). I see the developer-side complexity the opposite way. In #1 the backup plan is very explicit, in #2/3 for the developer to get good results on text-only platforms they have to understand our heuristics. We haven't specified them exactly, but I would speculate that using them would involve at least as much effort as specifying the backup plan explicitly. -John
Re: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 8:50 AM, Doug Turner doug.tur...@gmail.com wrote: On Jun 25, 2010, at 8:39 AM, John Gregg wrote: On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner doug.tur...@gmail.com wrote: Hey Drew, I think this is too vague, as it's sounds like a user agent could *not* ignore markup in the string, and still be compliant with the spec. I think we need to be very explicit that the string *must* be treated as plain text. So if I pass in gt;bfoo/b as the body parameter to createNotification(), the resulting notification must display the string gt;bfoo/b, without stripping or converting any of the substrings that might look like HTML entities. Yup. we should tighten up the language. i think we are on the same page here. It's actually more complicated given the various platform behavior. While Growl doesn't interpret markup, NotifyOSD on linux does allow some markup in its notifications (lt; shows , for example) [1, section 5]. So it's not sufficient to just pass the string directly, it has to be escaped in order to present the exact text provided. So perhaps, the user agent must display the string as plain text, without interpreting markup; if using a notification platform which does interpret markup, the user agent should modify the string so that any markup is shown rather than interpreted. [1] https://wiki.ubuntu.com/NotificationDevelopmentGuidelines From an implementation pov, this text sorta scares me. Figuring out which notification platform interpret which character sequences sounds hard. And these system are not static and must be reevaluated constantly. I think it might make it a bunch easier to simply say that UA should strip out any escape sequences or html tags. What do you think? I'm concerned that it would make it impossible to display a certain category of strings in notifications. Suppose we're both web devs, I'm chatting with you and want to share with you a snippet of code; will the chat notification be blank? I agree with the problem of depending on the providers, but if we do want to be able to specify dependable output for input (my interpretation of this discussion), I think we have to make some sort of effort there. -John -John
Re: Thoughts on WebNotification
On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner doug.tur...@gmail.com wrote:
I have been thinking a bit on Desktop Notifications [1]. After reviewing
the Web Notification specification [2], I would like to propose the
following changes:
1) Factor out the permission api into a new interface and/or spec. The
ability to test for a permission without bring up a UI would improve the UX
of device access. I could imagine implementing this feature for use with
Geolocation as well as notifications. For example:
interface Permissions {
// permission values
const unsigned long PERMISSION_ALLOWED = 0;
const unsigned long PERMISSION_UNKNOWN = 1;
const unsigned long PERMISSION_DENIED = 2;
void checkPermission(in DOMString type, in Function callback);
}
Then we could do something like:
navigator.permissions.checkPermission(desktop-notification,
function(value) {});
or
navigator.permissions.checkPermission(geolocation, function(value) {});
I like this idea, I think it's definitely preferable to a one-off permission
system just for notifications.
Your proposal doesn't have a way to explicitly request permission. Would
you be willing to add that, with the recommendation that it only take place
on a user gesture? I don't think this eliminates the ability to implement
request-on-first-use, if that's what Mozilla prefers, but I also still think
there is benefit to allowing permissions to be obtained separately from
invoking the API in question.
The bigger question is, are other features interested? Would the
Geolocation spec consider using something like this for permissions?
2) Add language to the spec to indicate that the DOMStrings used
|createNotification| are not to include any mark up. Basically,
implementations are going to hand off notifications to system-level
services. For example, on the Mac, GROWL does not handle any mark up...
their API just takes plain strings. I'd like to see the API reflect this
reality. Something like the |title| and |body| arguments are to be treated
as plain text... or some such language.
Although the group isn't chartered to deliver the spec forward, FWIW I agree
with this suggestion (it was always the intent) and have made this language
explicit in the editor's draft.
3) Move Web notifications to a version 2 of the specification. For the
most basic use cases, this API isn't required and a web developer could use
the more base API to simulate this. Furthermore, as I mentioned above, many
system-level notification services know nothing about rendering html.
Though I think web content still makes sense for notifications coming from a
web browser, and would want to publish an API which drives things in that
direction, I think this is reasonable if it will encourage greater
implementation of the basic API. As long as the text+icon API we use
doesn't cut off that avenue, and I think what we have now meets that.
-John
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
[Notifications] feedback requested on new Editor's Draft
After the extensive discussion several weeks ago, I've been working on a new draft for Web Notifications which is now available at http://dev.w3.org/2006/webapi/WebNotifications/publish/ The most substantial changes are: - Add requirements section. This is derived from the wiki page which Doug Schepers started, but I think it should live inside the spec. It's clear that there is interest in implementing the spec using Growl and other such platform APIs, so I've made it explicit that the spec is required to allow that implementation. At the same time, to achieve platform/device independence and look to the future of more sophisticated notifications, it isn't specified as the only way notifications can be implemented. - Rename HTMLNotification to WebNotification to allow other types of content (e.g. SVG as was in the feedback) and move this to a supplemental interface. - Add a definitions section so that terminology is clear. I look forward to seeing additional feedback. Thanks, -John
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 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
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
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: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
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, 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: Web Notifications, do we need a new spec?
Apologies for the delay, I've been spending the majority of my time completing the initial implementation for Chrome, but I've posted a draft version of a spec for notifications to http://sites.google.com/a/chromium.org/dev/developers/design-documents/desktop-notifications/api-specification I think that's a good starting point for formalizing it. This specification simplifies some of the notions of the widget spec (such as, is it necessary to bring the notifying context into view when a notification is generated?; i prefer they be passive). It is also more general in other areas (such as allowing more event handlers), so if there are specific requirements there we may need to come to consensus. -John 2009/9/7 Marcos Caceres marc...@opera.com John Gregg wrote: Hi Marcos, I'm doing the implementation for Chromium so I'm pretty familiar with notifications. Although I'm fairly new to the process, I would be happy to volunteer to help, since I would definitely like to see a new notifications spec come together. Great! Basically, we just need a plain-text brain-dump from you about how your implementation works and what the APIs. That should be sufficient as a starting point to get the ball rolling. As I've got some experience writing W3C specs, I'm happy to help co-edit. Before starting on an actual spec, the parts we need are: Requirements: a simple list of what the requirements are. (e.g., there must be a means to request the user's attention.) APIs: some IDL (or pseudo code) and a brief description of each of the attribute or method. A description of how you envision notifications play with HTML5's browsing contexts/origin. You might also look at what we originally had in the widget spec (search for The showNotification() Method and The getAttention() Method): http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-api/Overview.src.html?rev=1.87content-type=text/html;%20charset=iso-8859-1 showNotification() was based on some old HTML5 text, which was removed about a year ago. Anyway, please let us know if you need anything else, and we look forward your input! :D Kind regards, Marcos
Re: Web Notifications, do we need a new spec?
Hi Marcos, I'm doing the implementation for Chromium so I'm pretty familiar with notifications. Although I'm fairly new to the process, I would be happy to volunteer to help, since I would definitely like to see a new notifications spec come together. -John On Fri, Sep 4, 2009 at 9:35 AM, Marcos Caceres marc...@opera.com wrote: Ian Fette (イアンフェッティ) wrote: We are in the middle of implementing in WebKit and in Chromium, so yes we are still interested in pursuing. John Gregg (johnnyg@) has been leading the effort from our end. Beyond an implementation that people can experiment with, what sort of resources are you looking for? Basically, a spec editor. We need to formally gather the requirements and just start writing. I was personally hoping to do this, but I don't have the cycles or experience in this area (which is why I'm asking you guys if you can help me out). Kind regards, Marcos
