Re: Tags and origins (was: Re: Web Notifications)
On Wed, Jun 20, 2012 at 5:30 AM, Anne van Kesteren wrote: > On Wed, Jun 20, 2012 at 12:17 PM, Olli Pettay > 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 Fri, Jun 25, 2010 at 8:50 AM, Doug Turner wrote: > > On Jun 25, 2010, at 8:39 AM, John Gregg wrote: > > > > > > > On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner > 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 ">foo" as the body parameter to > createNotification(), the resulting notification must display the string > ">foo", 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 (< 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 Fri, Jun 25, 2010 at 8:56 AM, Jeremy Orlow wrote: > On Fri, Jun 25, 2010 at 4:44 PM, John Gregg 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 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
> > >> 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 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 Thu, Jun 24, 2010 at 1:29 PM, Doug Turner 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 ">foo" as the body parameter to > createNotification(), the resulting notification must display the string > ">foo", 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 (< 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
On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner 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
[WebNotifications] omnibus feedback reply, new draft
I've posted a new editor's draft of the notifications spec. It addresses the comments made on the previous spec (inline below, duplicate comments removed), and adds the following new pieces which were also suggested in other threads. * dir attribute which allows the directionality of the notification When the notification is web content, this is not important as the directionality can be specified internally; for text+icon notifications, the directionality indicates how the content should be passed to the notification platform. * replaceId attribute which allows notifications to be replaced. The use case for the replaceId is multi-tab web applications. Currently specified, it is easy to produce unwanted duplicate notifications for the same purpose (e.g., the same meeting reminder), and difficult to avoid except by using something like shared workers as a point of synchronization. Using a replacement ID means that duplicates cancel each other out cleanly, and also allows in-place updates. This functionality is supported natively by libnotify, and can be simulated on other platforms by closing and opening. Feedback, especially on these new additions, is appreciated. Thanks, -John On Tue, Mar 23, 2010 at 3:33 AM, Anne van Kesteren wrote: > The Web IDL should be cleaned up: > > * There is no such thing as DOMWindow > * Supplemental interfaces should use [Supplemental] Cleaned these things up. > 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. Added this. > It would be nice if fetching of resources was described in terms of the > fetch algorithm from HTML5. Added this reference and changed the language to match. > Currently there are no processing requirements for the mime argument of > createWebNotification(), do we really need it? I've removed the MIME type. > Queuing should be defined in terms of the HTML5 event loop. I'm not sure this makes sense. Queueing for notifications takes place outside of the script execution context, much like the timer queues where the spec defines an abstract list of pending timers that return to the event loop when they expire. I think notifications are the same way: there's an abstract queue which returns to the event loop when space is available. I've tried to make this more clear in the spec. > 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 moved it to the navigator object. On Tue, Mar 23, 2010 at 10:16 AM, Drew Wilson wrote: > > 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'. I've fixed the typo. > > Section 5: > > 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"). I don't think we should specify that explicitly, but rather leave room for implementation experience to guide whether this should be guided by heuristics or by a single rule. I can imagine situations where these permission settings get stale or a user doesn't know how to configure them; if there is no way to ever be prompted again, this could be quite limiting. > Is the intent of the spec that an Exception is thrown if the user calls > requestPermission() when the permission is already PERMISSION_ALLOWED? That was not my intent. If the request for permission can be satisfied with no action, I think the method should just return and call the callback immediately. > Section 8: > > Should passing an unsupported type of web content to createWebNotification() > generate an error event? I think it should throw an exception. Since there is no Notification object yet to target, an error event doesn't make sense. > 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? I added text which makes this explicitly clear. > 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. The close event should be fired for all methods of closing. I've added text to that effect.
Re: [Notifications] feedback requested on new Editor's Draft
On Tue, Mar 23, 2010 at 4:53 PM, Ryan Seddon wrote: > On Tue, Mar 23, 2010 at 1:06 PM, John Gregg wrote: > >> After the extensive discussion several weeks ago, I've been working on a >> new draft for Web Notifications which is now available at >> http://dev.w3.org/2006/webapi/WebNotifications/publish/ >> > > Not sure if this has been asked before but what about an optional property > to position it elsewhere beside the bottom left. > > Something like: > > createNotification(in DOMString iconUrl, in DOMString title, in DOMString > body[, in DOMString position]) > > Where it can take 4 possible values: topleft, topright, bottomleft, > bottomright. Bottomright being the default. Do you have a use case in mind for this? Perhaps there is one on a particular device, but for most of the browser/desktop use cases I think it is preferable to leave it up to the user agent or the underlying notification platform to decide where to put the notifications (probably based on user preferences). > > > > Should we really put another interface on the global object? Can we not >> put these on window.navigator like other APIs that integrate with the system >> layer? >> > > I also agree that it would make sense to add it to navigator. > Sounds like there is consensus on that. I will move it there. -John
[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 wrote: > On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen 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 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 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 3:09 PM, Drew Wilson wrote:
>
> On Wed, Feb 3, 2010 at 2:50 PM, Anne van Kesteren wrote:
>
>> On Wed, 03 Feb 2010 23:40:23 +0100, John Gregg
>> 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.
>
>
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.
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; 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?
-John
Re: Notifications
On Wed, Feb 3, 2010 at 1:22 PM, Anne van Kesteren wrote: > On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay > 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, Feb 3, 2010 at 11:41 AM, Anne van Kesteren wrote: > On Wed, 03 Feb 2010 19:54:44 +0100, 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). 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 for snooze delay is very useful. -John
Re: Notifications
On Wed, Feb 3, 2010 at 10:55 AM, Olli Pettay wrote: > 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
> > 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 9:55 AM, Olli Pettay 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: 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 > > > 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.87&content-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 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 >
