W3C home > Mailing lists > Public > public-web-notification@w3.org > June 2013

Re: Moving to Last Call

From: Justin DeWitt <dewittj@google.com>
Date: Fri, 7 Jun 2013 13:04:57 -0700
Message-ID: <CAE54qEYaT6QwfnOX21LZTmD=We+6OE7NQVAvp=ckTAfcoLHNgA@mail.gmail.com>
To: Jon Lee <jonlee@apple.com>
Cc: WG <public-web-notification@w3.org>

I'm glad to see this is moving forward.  I've been working on an extensions
API for desktop notifications in Chrome, and this spec seems mostly
compatible with the way we'll be rendering and displaying desktop
notifications going forward.  Just a few comments about the spec as-is:

   - Today, Chrome requires that requestPermission be called from within a
   callback handler for a user action.  The spec as written makes no mention
   of such a limitation.  Was it the intention of this WG to remove that
   restriction?  I searched a bit in the archives but didn't see a discussion
   on this topic.
   - The presence of the "show" event has a few downsides.  First, it can
   leak information about the user's idle status, since it's unlikely that UAs
   will display notifications while the screen is locked.  Second, it
   encourages applications to write their own code managing the duration of
   display for notifications.  This doesn't interact particularly well with
   the model that the system can control when and for how long a notification
   is presented.
   - In one section ( http://www.w3.org/TR/notifications/#using-events )
   the "close" event is said to be fired when the notification is closed by
   the user, and in another section (
   http://www.w3.org/TR/notifications/#closing-a-notification ) the spec
   says that the "close steps" must be run (and the "close" event fired)
   whether the notification is closed by the system or by the user. When
   writing an application, it is essential to know whether the close event has
   been generated by the user (indicating explicit acknowledgement and
   dismissal) or by the system (for other unrelated reasons such as screen
   real estate or resource limitations).  So, I recommend either modifying the
   spec to only fire the close event when the user has closed the
   notification, or to add a parameter to the onClose event handler that
   indicates whether the user closed the notification.


On Wed, May 29, 2013 at 12:10 PM, Jon Lee <jonlee@apple.com> wrote:

> Thanks to Ted for merging in those fixes.
> These changes resolved all of the remaining open issues on our spec. Given
> this, I'd like to move to Last Call on June 7, unless anyone objects. Does
> anyone have any concerns with this plan?
> As we move forward with the v1 spec, I encourage the WG to begin
> considering ideas for a v2 spec. Contributors have already made suggestions
> that the WG decided to push to a later version [1][2]; some new use cases
> have been raised in the WHATWG [3][4]. Now is a great time to start or
> continue discussing these ideas here.
> Jon
> [1]
> http://lists.w3.org/Archives/Public/public-web-notification/2012Jun/0023.html
> [2]
> http://lists.w3.org/Archives/Public/public-web-notification/2012Apr/0018.html
> [3]
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-March/039310.html
> [4]
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-March/039311.html
Received on Saturday, 8 June 2013 01:26:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:14 UTC