Re: Moving to Last Call

On Fri, Jun 7, 2013 at 10:04 PM, Justin DeWitt <dewittj@google.com> wrote:
>
>
>    - 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 reason we added this to the original proposal was to prevent web pages
from spamming the user with permission requests, although perhaps we've
decided we don't need this any longer? I don't recall any discussion on
this topic either.

>
>    - 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.
>
> It feels like there's a fundamental incompatibility between two different
ways that UAs might manage notifications - in one world (the current Linux
Chrome implementation), the browser just displays notifications in FIFO
order, and leaves them on the screen forever until the user dismisses them
or they are closed by the app. In the other world (e.g. Chrome on Mac)
there's some notification-center-style management happening, and the
browser controls exactly how long various notifications stay on the screen,
and potentially moves them into some kind of off-screen digest format when
it has decided not to show them on-screen any longer.

Gmail currently is written to live in a world like the former - where the
browser never auto-closes any notifications, so it does intensive
management of its own notifications (for example, it shows each email
notification for 5-6 seconds, then closes them - if it did not auto-close
these notifications, then email notifications would become much less useful
on platforms like Chrome Linux, because the user would be *forced* to close
every notification for every email).

I don't think it's possible to write a single web app that plays nicely
with UAs that manage the lifetime of their notifications, and also with UAs
that do not manage notification lifetimes. Ideally, we'd codify in the web
notification spec what the behavior of the UA should be (roughly) wrt
notification management - if we do not, then applications will have to
assume a lowest-common-denominator UA that does no notification management,
and write their own notification management (close their notifications
themselves).

If we'd like apps to not close their own notifications, then we need to
give them a viable alternative.

>
>    - 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.
>
> I'd request that we continue to notify the application for the
non-user-initiated close event so the application has a way to clean up any
of its data structures related to the notification which may no longer be
needed once it is no longer around (i.e. the application needs to know
whenever a notification is closed, regardless of its cause). If the
application needs to differentiate between different types of close events,
I'd be OK with having some attribute on the event itself to indicate this.

>
>
> Thanks,
> Justin
>
>
> 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
>>
>>
>