[webkit-dev] Can we remove Notification.show()?

[John Gregg]

On Mon, Jan 28, 2013 at 2:24 PM, Jochen Eisinger <jochen at chromium.org>wrote:

>
>
> On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn <esprehn at chromium.org>wrote:
>
>> This seems like a badly designed API, constructors shouldn't have side
>> effects and not having show() means after calling close() the notification
>> object is useless which is silly.
>>
>
There was a discussion a while ago which resulted in removing the show
method and making show implicit in construction.
http://lists.w3.org/Archives/Public/public-web-notification/2011Jun/0005.html.
 The reasoning was that there typically isn't much value in reusing a
notification.


>
> In the new API, there's also no close() method...
>

There is still a close() method in the latest spec:
http://notifications.spec.whatwg.org/#api


>
> -jochen
>
>
>>
>>
>> On Mon, Jan 28, 2013 at 4:35 AM, Andrew Wilson <atwilson at google.com>wrote:
>>
>>> So, we've recently landed some fixes to address permissions handling for
>>> Notification.show(): http://trac.webkit.org/changeset/140927
>>>
>>> Turns out, the notifications specification does not have a show() API
>>> (the notification is automatically shown from the constructor --
>>> http://notifications.spec.whatwg.org/#api). Does anyone have any
>>> objections to moving the show() API under the ENABLE_LEGACY_NOTIFICATIONS
>>> flag to bring us under compliance with the spec?
>>>
>>> Also, it looks like if a platform enables ENABLE_LEGACY_NOTIFICATIONs,
>>> not only do they get support for the old webkitNotifications API, but also
>>> some of the old API (like show() and cancel()) is exposed on the new
>>> Notifications objects, because we share the same interface for
>>> webkitNotifications and Notifications. Do we care (will this make it harder
>>> to eventually turn off ENABLE_LEGACY_NOTIFICATIONS since web apps may start
>>> using those APIs on the new Notifications objects)?
>>>
>>> -atw
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130128/b81b3e2e/attachment.html>