W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] Implementation question about Notifications

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 19 Nov 2013 14:35:52 +0000
Message-ID: <CADnb78j7ZEmur-o+5p46_RCqpcZv=mC3WhS2V8-gWvcr__BSRg@mail.gmail.com>
To: Andrew Wilson <atwilson@google.com>
Cc: Peter Beverloo <peter@chromium.org>, WHATWG List <whatwg@whatwg.org>
On Mon, Nov 18, 2013 at 2:08 PM, Andrew Wilson <atwilson@google.com> wrote:
> I think having them return the empty string would be fine (and would,
> coincidentally, match our current implementation in Chrome).


> My one concern is that according to the current spec, "" is a valid |tag|
> and so Notification("title", { tag: ""}) is different than
> Notification(title) because the latter has no tag, while the former has an
> empty tag (and so can be fetched via Notification.get(""))

In https://github.com/whatwg/notifications/commit/0db93b134e71431c9c85787cf5332692778d11cb
I made it so that tag being the empty string is equivalent to a
notification not having a tag. That avoids us having to choose
undefined or null to deal with his manner and gives a string-only API
which seems somewhat convenient.

>> Well, "invalid_icon_url" is not an invalid URL, but if you had used
>> e.g. "http://test:test/" it would have to return the same as n1.
>> n3.icon should return "http://non-existent-icon.com/" per
>> http://notifications.spec.whatwg.org/#dom-notification-icon
> Yes, makes sense, taking into account my inability to form an ill-formed URL
> :)

Just to be clear, note that it serializes the URL, hence the trailing
slash. This is similar to how <a>.href and family behave.

Received on Tuesday, 19 November 2013 14:36:18 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC