[whatwg] Implementation question about Notifications

[Andrew Wilson]

On Mon, Nov 18, 2013 at 1:01 PM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Thu, Nov 14, 2013 at 10:45 PM, Andrew Wilson <atwilson at google.com>
> wrote:
> > var n1 = new Notification("title");
> > var n2 = new Notification("title", {icon: "invalid_icon_url"});
> > var n3 = new Notification("title", {icon: "http://non-existent-icon.com
> "});
> >
> > I think that it should be:
> >
> > n1.dir == "auto"
> > n1.lang == ""
> > n1.body === undefined
> > n1.tag === undefined
> > n1.icon === undefined
> >
> > Do you agree? Or should it map to something different?
>
> If we want to treat empty string different from missing for
> body/tag/icon we could make them nullable. Not sure that's worth it
> though. Shall I clarify the specification that they should be the
> empty string as well?
>
>
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(""))

Since these two notifications are different, I'd say that the |tag|
attribute should reflect that difference:

var n1 = Notification("title", {tag: ""})
assert(n1.tag == "");

var n2 = Notification("title");
assert(n2.tag === undefined);

Either that, or we should update the spec to treat empty strings the same
as undefined in NotificationOptions.


>
> > What about n2.icon and n3.icon - what should they read? I'm curious,
> given
> > that section 4.9.1 reads:
>
> 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 :)


>
> > I'm not certain if "set notification's icon" refers to just the visible
> > image within the notification, or to the *Notification.icon* attribute
> > itself - I'm assuming the former (since we don't want to wait for a
> network
> > fetch before setting the Notification.icon attribute) so perhaps we
> should
> > rephrase this as "set notification's icon image to the decoded resource"?
>
> Done.
>
>
> --
> http://annevankesteren.nl/
>