Make BeforeInstallPrompt optional #797
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -562,10 +562,14 @@ <h3> | |
| </p> | ||
| </section> | ||
| </section> | ||
| <section class="atrisk"> | ||
| <h2> | ||
| Installation Events | ||
| </h2> | ||
| <p> | ||
| Installation events and supporting the {{BeforeInstallPrompt}} is | ||
|
Collaborator
There was a problem hiding this comment. I'm not sure why "installation events" (which includes appinstalled) is optional. I don't think there's anything particularly controversial about appinstalled is there? We should get that supported everywhere. I'm happy to mark BIP as optional, since it's effectively optional already, as it's up to the user agent to decide when and if to fire it (so any user agent that doesn't implement it could claim conformance already). Marking it as optional just makes that clear (and also makes it legal for window.BeforeInstallPromptEvent to not exist).
Collaborator
There was a problem hiding this comment. Is there any privacy risk with
Collaborator
There was a problem hiding this comment. We (me, @dominickng and @marcoscaceres ) couldn't think of any. You're going to get a CSS media query telling you that the window is standalone as soon as you open the window (which in Chrome Desktop is immediately upon install) anyway, so this doesn't give you any additional information.
Collaborator
There was a problem hiding this comment. I’m good then. Merge away! |
||
| OPTIONAL. | ||
| </p> | ||
| <p> | ||
| DOM events <a>fired</a> by this specification use the <dfn>application | ||
| life-cycle task source</dfn>. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has there been any more discussion about the "at risk" status of this feature? I don't think we can just deprecate it at this point; too many sites rely on it (though as I say below, I think it's fine for it to be perpetually optional).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don‘t have a strong feeling on "at risk". Keeping it optional also leaves the door open for browsers to decide to never do anything with it or to remove support is they have it an are unhappy with it. If we get to the point that no UA is interested in supporting it anymore, we can label it "at risk" and begin to let folks know they may want to consider dropping it from their code.