Re: [whatwg] Form Controls Wish List

[Domenic Denicola]

Hi Garret,

I'd really encourage you to read the WHATWG FAQ. In particular, the part urging 
you to focus on presenting compelling use cases, instead of specific APIs or 
solutions. Many of your suggestions are not motivated by use cases, from what I 
can see, and in fact would actively harm developers by breaking backward 
compatibility with existing content.

With that in mind, after reading the FAQ, I'd urge you to come back with those 
of your requests that still remain in the form of use cases only, with *no* 
specific API proposals.

If this seems like a strange way of doing business, I can only say ... The FAQ 
explains it much better than me :)

From: Garrett Smith
Sent: ‎2014-‎07-‎10 21:03
To: WHAT Working Group
Subject: [whatwg] Form Controls Wish List

Here's what I want.

1.   Form `dirty` property. Set to false, initially. Set to true
when the user has interacted with any of the form's controls to make
them dirty.

2.   HTMLFormControl. Why is there no HTMLFormControl interface? I
see HTMLFormControlsCollection but no HTMLFormControl. HTMLElement
doesn't cover HTMLSelectElement. I see a 'listed' category. Why no
interface defining HTMLFormControl?

3.   To determine if a form control is eligible for success (see
below) `HTMLFormControl.isEnabled`

4.   To get the value of a form's enabled controls as a string:
HTMLFormElement.serialize(type, callbackFunction). `type` can be
"json" or "query".

5.   Set the value of a form's controls using
HTMLForm.revive(object[, metaReviver])



(3) Disabled Fieldset
Disabling a fieldset disables its descendant controls but does not
change their disabled property. Thus, a disabled fieldset's descendant
controls won't succeed, however, its descendant controls' `disabled`
property can be true.



>From what I understand, the word "disabled" it appears in HTML5 is
overloaded to describe the following three different things:

1)  The form control's disabled `property` *

2)  The form control's disabled attribute (content attribute) **

3)  The form control's eligibility for success. ***


I propose changing one of these -- the last -- to the positive sense
-- isEnabled, and exposing that in the DOM. Because it's not so useful
to have a form whose disabled property is false but the form is
"disabled" due to being a descendant of a disabled fieldset.

The proposed form control `isEnabled` property determines if the
control is eligible for success. This property exists for the purpose
of handling the situation where a control's `disabled` property is
false and the control is a descendant of a disabled fieldset. In this
case, the control's `isEnabled` property and disabled property will
both be false and the control will not be eligible for success.

 *
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#htmlinputelement
 **
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-disabled
 ***
http://dev.w3.org/html5/spec-preview/attributes-common-to-form-controls.html#enabling-and-disabling-form-controls


"A form control is disabled if its disabled attribute is set, or if it
is a descendant of a fieldset element whose disabled attribute is
set..."

Disabling fieldsets is potentially quite useful; it just needs better
support and a better DOM api for nested controls.

That's my wishlist for forms.
--
Garrett
@xkit
ChordCycles.com
garretts.github.io

[whatwg] Form Controls Wish List

[Garrett Smith]

Here's what I want.

1.   Form `dirty` property. Set to false, initially. Set to true
when the user has interacted with any of the form's controls to make
them dirty.

2.   HTMLFormControl. Why is there no HTMLFormControl interface? I
see HTMLFormControlsCollection but no HTMLFormControl. HTMLElement
doesn't cover HTMLSelectElement. I see a 'listed' category. Why no
interface defining HTMLFormControl?

3.   To determine if a form control is eligible for success (see
below) `HTMLFormControl.isEnabled`

4.   To get the value of a form's enabled controls as a string:
HTMLFormElement.serialize(type, callbackFunction). `type` can be
"json" or "query".

5.   Set the value of a form's controls using
HTMLForm.revive(object[, metaReviver])



(3) Disabled Fieldset
Disabling a fieldset disables its descendant controls but does not
change their disabled property. Thus, a disabled fieldset's descendant
controls won't succeed, however, its descendant controls' `disabled`
property can be true.



>From what I understand, the word "disabled" it appears in HTML5 is
overloaded to describe the following three different things:

1)  The form control's disabled `property` *

2)  The form control's disabled attribute (content attribute) **

3)  The form control's eligibility for success. ***


I propose changing one of these -- the last -- to the positive sense
-- isEnabled, and exposing that in the DOM. Because it's not so useful
to have a form whose disabled property is false but the form is
"disabled" due to being a descendant of a disabled fieldset.

The proposed form control `isEnabled` property determines if the
control is eligible for success. This property exists for the purpose
of handling the situation where a control's `disabled` property is
false and the control is a descendant of a disabled fieldset. In this
case, the control's `isEnabled` property and disabled property will
both be false and the control will not be eligible for success.

 *
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#htmlinputelement
 **
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-disabled
 ***
http://dev.w3.org/html5/spec-preview/attributes-common-to-form-controls.html#enabling-and-disabling-form-controls


"A form control is disabled if its disabled attribute is set, or if it
is a descendant of a fieldset element whose disabled attribute is
set..."

Disabling fieldsets is potentially quite useful; it just needs better
support and a better DOM api for nested controls.

That's my wishlist for forms.
-- 
Garrett
@xkit
ChordCycles.com
garretts.github.io

Re: [whatwg] Better DOM hooks for polyfilling CSS properties?

[Tab Atkins Jr.]

[This discussion belongs on the www-st...@w3.org list, not whatwg. I'll
give a perfunctory answer here, but will not follow up. Please start a
thread on www-style if you wish to discuss this further.]

On Jul 10, 2014 2:39 PM, "Brian Blakely"  wrote:
>
> Problem
> ===
>
> It's difficult to know when an unsupported property was set for any
arbitrary
> element, and manually sifting through stylesheets isn't very easy.
>
> This makes polyfilling CSS harder than it needs to be.
>
> Strawman
> ===
>
> The endgoal is to easily get a NodeList containing elements that have a
> particular invalid/unsupported property applied.
>
> Suggestion 1: Dictionary
> ---
>
> Object populated with information about elements that have a rejected CSS
> property applied.  It updates continuously to reflect the app's most
> current state.
>
> document.rejectedCSSProperties = {
>   "": ,
>   ...
>   ...
> };
>
> This, combined with Object.observe, would allow authors an extensible way
to
> handle unsupported CSS.
>
> Suggestion 2: Query Method
> ---
>
> document.getElementsByRejectedProperty('foo-bar');
>
> This is the most direct solution.  Maybe more difficult to
implement/maintain
> vendorside.  Should return live NodeLists, a la getElementsByClassName.
>
> Suggestion 3: Event
> ---
>
> document.oncsspropertyrejected = function(event) {
>   element.property // "foo-bar"
>   event.elements // NodeList
> };
>
> Kind of similar semantically to the solution in Suggestion 1, but in a
> more traditional format.  I prefer Suggestion 1, as it offers a
> centralized "registrar" of rejected properties.

CSS very intentionally does not expose invalid properties, to protect our
ability to extend CSS in the future.

Instead, we are adding custom properties with a special syntax that
guarantees no future conflicts will occur: any property name that starts
with two dashes is a custom property, and will be preserved in the cssom
and not otherwise processed by CSS.

The first iteration of custom properties is defined in <
http://dev.w3.org/csswg/css-variables>. This is a simplistic variant,
exposing only the portion of vision properties that is needed for
variables, but the CSS Extensions spec <
http://dev.w3.org/csswg/css-extensions> will define a more complete variant
of the feature, including the ability to easily determine what elements
have a custom property applied to them, and when it changes.

~TJ

Re: [whatwg] Notifications improvements

[Jonas Sicking]

On Thu, Jul 10, 2014 at 8:01 AM, Peter Beverloo  wrote:
>
> On Thu, Jul 10, 2014 at 4:44 AM, Jonas Sicking  wrote:
>>
>> We need to change the GC behavior. Right now it seems like if a
>>
>> Notification object is created, but no event listeners are attached,
>> because the page is expecting to use the SW event to listen for
>> clicks, the notification won't be kept alive and so the SW can't get
>> to any of its data.
>>
>> We also need to keep state on the Notification object if the user has
>> clicked the notification or not.
>>
>> We should also consider enabling passing a URL to the Notification
>> constructor which is opened when the user clicks the notification.
>> Probably this should attempt to reuse an existing tab with said URL if
>> one is open.
>
>
> Notifications should just be serialized and re-created on demand, since they
> can outlive both pages and workers.
>
> If a page creates a notification, events for which should be delivered to a
> Service Worker, then won't be able to re-use the existing object anyway. We
> can't rely on a SW to stay alive between [creating a notification,
> interacting with the notification] either. Since the |data| property exists,
> developers can use that (or the notification's title) instead of using the
> equality operator.
>
> I believe we had some discussion about a launch URL earlier on. There are
> various race conditions: what if the user presses twice on the notification
> in quick succession - will we open the page twice? What is a page with that
> URL has already been opened? What if there are two? Deferring to a Service
> Workers solves these. The |notificationclick| event could be allowed to open
> windows, too.

I completely agree. The spec needs to separate the notion of a
UI-visible notification, from the Notification object instance.

/ Jonas

Re: [whatwg] Notifications improvements

[Jonas Sicking]

On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson  wrote:
>
> On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking  wrote:
>>
>> Hi All,
>>
>> We've on and off discussed various features added to notifications.
>> It'd be great to move forward with some of these improvements.
>>
>> I think the most low hanging fruit would be to add the following as
>> data that can be displayed in a notification:
>>
>> * Progress bar
>> * Lists of title/body pairs
>> * Date (for things like "event will happen in 10 minutes")
>>
>
> So, many of these cases were what the original HTMLNotification API was
> supposed to address. This was eventually shot down for a number of (good)
> reasons: too much complexity on the implementation side, and more
> importantly, the fact that these more complex notifications aren't
> compatible with various platform notification frameworks and so this would
> be a source of platform/UA incompatibility. It's not clear to me that
> re-adding support for these use cases one at a time as distinct notification
> types is really a good path forward, or that it's necessarily "low-hanging
> fruit" unless we have a good idea for how to deal with the
> platform-compatibility issue.

Actually, given that the UA has a very high degree of semantic
understanding of these properties, I think it should be doable to
implement on top of all existing platform notification systems. In all
of the above cases you can come up with a reasonable string to add to
the end to render the content. This is what pages have to do right now
anyway.

This is different from generic HTML->text conversion I think, since
HTML is very rich and there's a bigger risk of generating unuseful
text.

One thing that we *could* do is to add API for detecting which of
these properties will be rendered "natively", and which ones will use
some form of UA-provided fallback. This way an advanced page could
compensate for lacking capabilities in more advanced ways, whereas
less advanced authors would get reasonably good automatic fallback.

>> Second, we really need to figure out the story around handling user
>> clicking notifications after the user has closed the original page.
>>
>> At the very least we need the ability to send a message to a
>> ServiceWorker when the user clicks a notification. This way the SW can
>> decide if UI should be shown, and if so if an existing window can be
>> reused or not.
>>
>> SW integration will require some other changes too.
>>
>> We need to change the GC behavior. Right now it seems like if a
>> Notification object is created, but no event listeners are attached,
>> because the page is expecting to use the SW event to listen for
>> clicks, the notification won't be kept alive and so the SW can't get
>> to any of its data.
>>
>> We also need to keep state on the Notification object if the user has
>> clicked the notification or not.
>>
>> We should also consider enabling passing a URL to the Notification
>> constructor which is opened when the user clicks the notification.
>> Probably this should attempt to reuse an existing tab with said URL if
>> one is open.
>>
>>
>> Third, we should look at enabling minimal user input through the
>> Notification. It's very common for notifications to support having one
>> or more buttons that the user can click. It would also be good to
>> enable putting a simple text-input in the notification. This area is
>> definitely more complex though so happy to put this last.
>>
> I think if we want to address the "more complex data type" use cases above,
> then this needs to be part of that proposal - for example, I'm not sure how
> valuable having something like a "Date/Event" notification would be without
> a "Snooze" button.

I'm not sure that's true. Notifying that an event is going to happen
in 10 minutes would still be useful even if the user can't "snooze"
that notification.

/ Jonas

Re: [whatwg] Stricter data URL policy

[Ian Hickson]

On Wed, 9 Jul 2014, Jonas Sicking wrote:
> 
> But javascript: is sort of screwed no matter what. A javascript URL 
> inheritely will run javascript, and it always does so in the origin of 
> whoever set the url. So pages will have to look for javascript: anytime 
> they are handling URLs.
> 
> But it's better if pages only have to look for javascript: when handling 
> URLs. Rather than having to look for javascript:, data:, blob: and 
> nextbigthing:.
> 
> I'd love to simply deprecate javascript:. It doesn't seem like the use 
> cases are worth the complexity for both implementations and authors. But 
> I think it's too commonly used these days to get rid of. At least for 
> quite some time. About 100x the usage of sync XHR if [1] means that I 
> guess it means.

Note that 'javascript:' at this point is about as deprecated as I think we 
can get it. It's just special-cased logic in the navigation algorithm. 
Everywhere else, it just gets treated as an unknown URL scheme.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] Better DOM hooks for polyfilling CSS properties?

[Brian Blakely]

Problem
===

It's difficult to know when an unsupported property was set for any arbitrary
element, and manually sifting through stylesheets isn't very easy.

This makes polyfilling CSS harder than it needs to be.

Strawman
===

The endgoal is to easily get a NodeList containing elements that have a
particular invalid/unsupported property applied.

Suggestion 1: Dictionary
---

Object populated with information about elements that have a rejected CSS
property applied.  It updates continuously to reflect the app's most
current state.

document.rejectedCSSProperties = {
  "": ,
  ...
  ...
};

This, combined with Object.observe, would allow authors an extensible way to
handle unsupported CSS.

Suggestion 2: Query Method
---

document.getElementsByRejectedProperty('foo-bar');

This is the most direct solution.  Maybe more difficult to implement/maintain
vendorside.  Should return live NodeLists, a la getElementsByClassName.

Suggestion 3: Event
---

document.oncsspropertyrejected = function(event) {
  element.property // "foo-bar"
  event.elements // NodeList
};

Kind of similar semantically to the solution in Suggestion 1, but in a
more traditional format.  I prefer Suggestion 1, as it offers a
centralized "registrar" of rejected properties.

Re: [whatwg] Questions about the Fetch API

[Domenic Denicola]

From: whatwg  on behalf of Juan Ignacio Dopazo 


> Would it be to crazy to get fetch(url).asJSON() to work? Either by not having 
> fetch() return a promise (and return something that has a function that 
> returns a promise for the headers) or by having it return a subclass of 
> Promise that contains those utility methods?

In my opinion subclassing promises should not be done just for adding minor 
conveniences. It should be done for qualitatively new types of promises (e.g. 
cancellable ones), but arbitrary concepts should not become promise subclasses.

> Also, my question about the Request class is because I don't see a way to get 
> a writable stream for the body of the request. It'd be nice if we had that 
> for uploaders for example.

This is a very important question and we should look into solving it before the 
API settles too much.

To provide a clearer example of what Juan is talking about, in Node it is 
common to do something like


var req = http.request({ method: "POST", ... });

req.write("data1");
req.write("data2");
req.end();

// or even better

fs.createReadStream("file.txt").pipe(req);

We are doing a very good job IMO on preparing the spec for readable stream 
integration, with the FetchBodyStream scaffold. We need to spend similar effort 
preparing for writable stream integration. I would be happy to help spearhead 
this effort along with anyone else interested.

Re: [whatwg] Questions about the Fetch API

[Joshua Bell]

On Thu, Jul 10, 2014 at 7:17 AM, Juan Ignacio Dopazo 
wrote:

>
>
> On Wednesday, July 9, 2014 3:02 AM, Tab Atkins Jr. 
> wrote:
>
>
>
>
>
> On Tue, Jul 8, 2014 at 11:35 AM, Juan Ignacio Dopazo
>  wrote:
> > - And more importantly, why does fetch() return a Promise
> instead of a Response?
> Because you aren't allowed to do network fetches sync.  (And if you
> have an async action, returning a Promise for its result is the
> idiomatic way to do it, rather than, say, making the object itself
> asynchronous in some way.)
>
>
> That makes sense considering Response is representing the actual response
> from the server. You get the response once you get the first answer from
> the server and that response contains the headers. However, my first
> thought when looking at the API was: why can't I just do
> fetch(url).asJSON().then(...)? I'd say that, while headers will be super
> useful for certain kinds of apps and for stuff like Service Workers, at
> least 80% of XHR requests in the web are about getting data and just ignore
> the headers. So instead of just getting the data, we either have to write
> library code or write something like:
>
> fetch(url).then(function (response) {
>   return response.body.asJSON();
> }).then(...);
>
>
FWIW, with ES6 "fat arrow" expressions it will soon be possible to write:

fetch(url).then(r => r.body.asJSON()).then(...);

And there's a proposal for an "infix eventual operator" [1] in ES7 that
would let you write it as:

fetch(url)!body.asJSON().then(...);

... which is still wordier than your proposal, of course.

[1] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency

Would it be to crazy to get fetch(url).asJSON() to work? Either by not
> having fetch() return a promise (and return something that has a function
> that returns a promise for the headers) or by having it return a subclass
> of Promise that contains those utility methods?
>
> Also, my question about the Request class is because I don't see a way to
> get a writable stream for the body of the request. It'd be nice if we had
> that for uploaders for example.
>
> Thanks,
>
> Juan
>

Re: [whatwg] Notifications improvements

[Peter Beverloo]

In principle I agree that the specification should be implementable by all
major platforms. However, I also think that there is an important trade-off
to make here, since they are an increasingly important part of the user
experience offered by an applications -- most notably when applications can
have background activities.

Windows 8's Toast Notifications are the most basic ones, exactly matching
what the Web Notification API provides today. Both iOS and Android have
various features on top of this, with Android's notifications being much
richer than most other platforms'. Some desktop user agents implement their
own rendering, and therefore have much more freedom than having to defer to
an operating system.

I would love to be able to expose a reasonable subset of those features to
users, but we'll have to be very conscious about the impact this can have
in terms of interoperability. I don't think we should strictly hold back
because of platforms which choose to be conservative in the Notification
features they offer, as long as (1) developers can feature detect the
differences, and (2) they can degrade gracefully.

Perhaps we can start with investigating buttons? iOS 8's interactive
notifications will introduce support for them.

On Thu, Jul 10, 2014 at 4:44 AM, Jonas Sicking  wrote:
>
> Second, we really need to figure out the story around handling user
> clicking notifications after the user has closed the original page.
>
> At the very least we need the ability to send a message to a
> ServiceWorker when the user clicks a notification. This way the SW can
> decide if UI should be shown, and if so if an existing window can be
> reused or not.


Yes. See my e-mail about this in May; we should continue discussing Service
Worker integration there. Anne has yet to make the changes.

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-May/296806.html

On Thu, Jul 10, 2014 at 4:44 AM, Jonas Sicking  wrote:
>
> We need to change the GC behavior. Right now it seems like if a
> Notification object is created, but no event listeners are attached,
> because the page is expecting to use the SW event to listen for
> clicks, the notification won't be kept alive and so the SW can't get
> to any of its data.
>
> We also need to keep state on the Notification object if the user has
> clicked the notification or not.
>
> We should also consider enabling passing a URL to the Notification
> constructor which is opened when the user clicks the notification.
> Probably this should attempt to reuse an existing tab with said URL if
> one is open.


Notifications should just be serialized and re-created on demand, since
they can outlive both pages and workers.

If a page creates a notification, events for which should be delivered to a
Service Worker, then won't be able to re-use the existing object anyway. We
can't rely on a SW to stay alive between [creating a notification,
interacting with the notification] either. Since the |data| property
exists, developers can use that (or the notification's title) instead of
using the equality operator.

I believe we had some discussion about a launch URL earlier on. There are
various race conditions: what if the user presses twice on the notification
in quick succession - will we open the page twice? What is a page with that
URL has already been opened? What if there are two? Deferring to a Service
Workers solves these. The |notificationclick| event could be allowed to
open windows, too.

Thanks,
Peter



On Thu, Jul 10, 2014 at 9:04 AM, Andrew Wilson  wrote:

> On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking  wrote:
>
> > Hi All,
> >
> > We've on and off discussed various features added to notifications.
> > It'd be great to move forward with some of these improvements.
> >
> > I think the most low hanging fruit would be to add the following as
> > data that can be displayed in a notification:
> >
> > * Progress bar
> > * Lists of title/body pairs
> > * Date (for things like "event will happen in 10 minutes")
> >
> >
> So, many of these cases were what the original HTMLNotification API was
> supposed to address. This was eventually shot down for a number of (good)
> reasons: too much complexity on the implementation side, and more
> importantly, the fact that these more complex notifications aren't
> compatible with various platform notification frameworks and so this would
> be a source of platform/UA incompatibility. It's not clear to me that
> re-adding support for these use cases one at a time as distinct
> notification types is really a good path forward, or that it's necessarily
> "low-hanging fruit" unless we have a good idea for how to deal with the
> platform-compatibility issue.
>
>
> >
> > Second, we really need to figure out the story around handling user
> > clicking notifications after the user has closed the original page.
> >
> > At the very least we need the ability to send a message to a
> > ServiceWorker when the user clicks a notification. This way the SW can

Re: [whatwg] Questions about the Fetch API

[Juan Ignacio Dopazo]

On Wednesday, July 9, 2014 3:02 AM, Tab Atkins Jr.  wrote:





On Tue, Jul 8, 2014 at 11:35 AM, Juan Ignacio Dopazo
 wrote:
> - And more importantly, why does fetch() return a Promise instead 
> of a Response?
Because you aren't allowed to do network fetches sync.  (And if you
have an async action, returning a Promise for its result is the
idiomatic way to do it, rather than, say, making the object itself
asynchronous in some way.)


That makes sense considering Response is representing the actual response from 
the server. You get the response once you get the first answer from the server 
and that response contains the headers. However, my first thought when looking 
at the API was: why can't I just do fetch(url).asJSON().then(...)? I'd say 
that, while headers will be super useful for certain kinds of apps and for 
stuff like Service Workers, at least 80% of XHR requests in the web are about 
getting data and just ignore the headers. So instead of just getting the data, 
we either have to write library code or write something like:

fetch(url).then(function (response) {
  return response.body.asJSON();
}).then(...);

Would it be to crazy to get fetch(url).asJSON() to work? Either by not having 
fetch() return a promise (and return something that has a function that returns 
a promise for the headers) or by having it return a subclass of Promise that 
contains those utility methods?

Also, my question about the Request class is because I don't see a way to get a 
writable stream for the body of the request. It'd be nice if we had that for 
uploaders for example.

Thanks,

Juan

Re: [whatwg] Notifications improvements

[Andrew Wilson]

On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking  wrote:

> Hi All,
>
> We've on and off discussed various features added to notifications.
> It'd be great to move forward with some of these improvements.
>
> I think the most low hanging fruit would be to add the following as
> data that can be displayed in a notification:
>
> * Progress bar
> * Lists of title/body pairs
> * Date (for things like "event will happen in 10 minutes")
>
>
So, many of these cases were what the original HTMLNotification API was
supposed to address. This was eventually shot down for a number of (good)
reasons: too much complexity on the implementation side, and more
importantly, the fact that these more complex notifications aren't
compatible with various platform notification frameworks and so this would
be a source of platform/UA incompatibility. It's not clear to me that
re-adding support for these use cases one at a time as distinct
notification types is really a good path forward, or that it's necessarily
"low-hanging fruit" unless we have a good idea for how to deal with the
platform-compatibility issue.


>
> Second, we really need to figure out the story around handling user
> clicking notifications after the user has closed the original page.
>
> At the very least we need the ability to send a message to a
> ServiceWorker when the user clicks a notification. This way the SW can
> decide if UI should be shown, and if so if an existing window can be
> reused or not.
>
> SW integration will require some other changes too.
>
> We need to change the GC behavior. Right now it seems like if a
> Notification object is created, but no event listeners are attached,
> because the page is expecting to use the SW event to listen for
> clicks, the notification won't be kept alive and so the SW can't get
> to any of its data.
>
> We also need to keep state on the Notification object if the user has
> clicked the notification or not.
>
> We should also consider enabling passing a URL to the Notification
> constructor which is opened when the user clicks the notification.
> Probably this should attempt to reuse an existing tab with said URL if
> one is open.
>
>
> Third, we should look at enabling minimal user input through the
> Notification. It's very common for notifications to support having one
> or more buttons that the user can click. It would also be good to
> enable putting a simple text-input in the notification. This area is
> definitely more complex though so happy to put this last.
>
> I think if we want to address the "more complex data type" use cases
above, then this needs to be part of that proposal - for example, I'm not
sure how valuable having something like a "Date/Event" notification would
be without a "Snooze" button.