- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 19 Nov 2013 14:35:52 +0000
- 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).
Okay.
> 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.
--
http://annevankesteren.nl/
Received on Tuesday, 19 November 2013 14:36:18 UTC