W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2010

Fwd: [WebNotifications] omnibus feedback reply, new draft

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 22 Apr 2010 21:44:26 -0400
Message-Id: <5D59E909-A072-4461-84AF-ADFF50C228CE@nokia.com>
To: public-device-apis <public-device-apis@w3.org>, John Gregg <johnnyg@google.com>
FYI, John reports some good progress on the Web Notifications  
Editor's Draft:


Please send comments to public-webapps@w3.org

Begin forwarded message:

> From: ext John Gregg <johnnyg@google.com>
> Date: April 22, 2010 3:16:30 PM EDT
> To: public-webapps <public-webapps@w3.org>
> Subject: [WebNotifications] omnibus feedback reply, new draft
> Archived-At: <http://www.w3.org/mid/ 
> l2k5ce7a0db1004221216k8eac909ci675786194003612a@mail.gmail.com>
> 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  
> <annevk@opera.com> 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 <atwilson@google.com>  
> 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  
> 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.
Received on Friday, 23 April 2010 01:45:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:19 UTC