From e887ddbabdae17c117630e1317ec3e85f3d4e062 Mon Sep 17 00:00:00 2001 From: diekus <73939538+diekus@users.noreply.github.com> Date: Thu, 27 Feb 2025 18:16:58 +0000 Subject: [PATCH 01/12] Expands on the declarative alternative * expands on declarative alternative and the reasons why we think starting with an imperative API works best. * adds details about the try-before-you-buy scenario as UA defined UX. --- WebInstall/explainer.md | 42 +++++++++++++++++++++++++++++++---------- 1 file changed, 32 insertions(+), 10 deletions(-) diff --git a/WebInstall/explainer.md b/WebInstall/explainer.md index 9d91188e..0ed29b68 100644 --- a/WebInstall/explainer.md +++ b/WebInstall/explainer.md @@ -328,6 +328,9 @@ The benefit of the defined error handling for this feature is that the invoking ### **Gating capability behind installation** A UA may choose to gate the `navigator.install` capability behind a requirement that the installation origin itself is installed. This would serve as an additional trust signal from the user towards enabling the functionality. +### **Showing try-before-you-buy UX** +The install UX can should a try-before-you-buy prompt. The UA may decide to show a prompt, some sort of rich-install dialog with additional information found in the manifest file, or load a preview of the app with the install confirmation. This is an implementation detail completely up to the UA. + ### **Feature does not work on Incognito or private mode** The install capability should not work on *incognito*, and the promise should always reject if called in a private browsing context. @@ -337,7 +340,7 @@ The install capability should not work on *incognito*, and the promise should al ### Declarative install -An alternate solution to allow installation of web apps is by allowing a new target type of `_install` to the HTML anchor tag. +**An alternate solution to allow installation of web apps is by allowing a new target type of `_install` to the HTML anchor tag.** `honk` @@ -345,13 +348,32 @@ Pros: * Platform fallback to navigate to the content automatically. * Does not need JavaScript. -Cons: -* Takes the user out of the current context. -* Limits the amount of information a developer can act upon that the promise provides, such as if the prompt was shown or if the origin has permissions to install apps. -* Can become cumbersome when specifying the parameters in the tag. -* Can't easily pass additional information like the referral-info. +Cons: +* Takes the user out of the current context, providing no alternative if the use case benefits from them staying in context. +* Limits the amount of information a developer can act upon that the promise provides, such as if the prompt was shown. +* Developers can't modify their UX to tailor to situations where the origin permission isn't granted. +* No support for the concept of an `install_url` (requires additional work to the HTML specification). +* Can't easily pass additional information like the referral-info. + +**Another alternate solution based in a declarative approach could see the use of the [rel](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel) attribute to hint to the UA that the url in the link should be installed.** + +`honk` + +Pros (same as above): +* Basic platform default fallback (navigation). +* Does not need JavaScript. + +Cons (same as above plus): +* Unintended navigation to `install_url`: If a UA doesn't implement the web install feature, and the `install_url` is used in the `href` value, it may fallback to navigate to that `install_url`, potentially leaving the end user in a blank document. (this could be resolved by creating more attributes to the `a` tag to define the additional parameters that the feature requires). +* Longer `a` tags: if we address the missing `install_url` and `manifest_id` parameters and decided to keep the `href` as a link then we could be potentially introducing lengthier and less readable tags similar to: `honk`. +* More complex combinations for the UA to take into account: additional attributes that act on a link HTML tag (`a`) like the target mean there is an increased set of scenarios that might have unintended consequences for end users. For example, how does a target of `_ top` differ from `_blank`? While we could look at ignoring the `target` attribute if a `rel` attribute is present, the idea is to use acquisition mecanisms that are already present in UAs. -The declarative solution is a simple and effective solution and future entry point for the API. It should be considered for a v2 of the capability. For the current solution, we've decided to go with an imperative implementation since it allows more control over the overall installation UX. +Having stated this, we believe that a declarative implementation is a simple and effective solution, and a future entry point for the API. It should be [considered for a v2](#future-work) of the capability. For the current solution, **we've decided to go with an imperative implementation since it allows more control over the overall installation UX**: +* Allows the source to detect if an installation occurred with ease. (resolves/rejects a promise). +* Supports `install_url`. This url can be an optimized url or the normal homepage that an application already has. The advantage is that unlike a declarative version, there is no scenario where an end user can be left stranded accidentally in a blank page that is meant to be a lightweight entry point to the app. +* Code can be used to detect if an origin has permission to install apps, and UX can be tailored to change accordingly (for example, remove a button or display a link instead). +* The developer ergonomics of handling a promise are better than responding to an `a` tag navigation. +* Keeps the user in the context, which *can* be beneficial in certain scenarios (if the developer *wants* to take the user out of the current context, they *can* do so with a `a` tag). ### `install_sources` manifest field @@ -361,16 +383,16 @@ The `install_sources` was a new manifest field that specified which domains coul * Should we have custom error types like `IDMismatchError`? -No, we are grouping all error cases into 2 different errors (`DataError` and `AbortError`). This will reduce the possibility for a bad actor to determine if a user was logged-in to a site that has a manifest behind a login. It also complicates knowing the reason why an application's installation fails. + No, we are grouping all error cases into 2 different errors (`DataError` and `AbortError`). This will reduce the possibility for a bad actor to determine if a user was logged-in to a site that has a manifest behind a login. It also complicates knowing the reason why an application's installation fails. * Is it correct for the permission when calling the `install` method to be required for all background document installations, and not just cross-origin installations? -Yes, we are now requiring any installation apart from _current document_ ones to come from an origin that has the permission to install. + Yes, we are now requiring any installation apart from _current document_ ones to come from an origin that has the permission to install. * Should we allow an [`AbortController`](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) to enable cancelling the installation if the process takes too long? * Can we remove power from the developer to query if the app is installed by offloading to the UA the knowledge of which apps are installed? - * Is there any form of attribute that can be added to a DOM element to signal this distinction/difference? + * Is there any form of attribute that can be added to a DOM element to signal this distinction/difference? ## Future Work From c4f27e76a244871790bd79e564eb9d391be3b2a0 Mon Sep 17 00:00:00 2001 From: Diego Gonzalez <73939538+diekus@users.noreply.github.com> Date: Thu, 27 Feb 2025 21:16:10 +0000 Subject: [PATCH 02/12] Update WebInstall/explainer.md Co-authored-by: Howard Wolosky --- WebInstall/explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/WebInstall/explainer.md b/WebInstall/explainer.md index 0ed29b68..af0946f8 100644 --- a/WebInstall/explainer.md +++ b/WebInstall/explainer.md @@ -329,7 +329,7 @@ The benefit of the defined error handling for this feature is that the invoking A UA may choose to gate the `navigator.install` capability behind a requirement that the installation origin itself is installed. This would serve as an additional trust signal from the user towards enabling the functionality. ### **Showing try-before-you-buy UX** -The install UX can should a try-before-you-buy prompt. The UA may decide to show a prompt, some sort of rich-install dialog with additional information found in the manifest file, or load a preview of the app with the install confirmation. This is an implementation detail completely up to the UA. +The install UX can show a try-before-you-buy prompt. The UA may decide to show a prompt, some sort of rich-install dialog with additional information found in the manifest file, or load a preview of the app with the install confirmation. This is an implementation detail completely up to the UA. ### **Feature does not work on Incognito or private mode** The install capability should not work on *incognito*, and the promise should always reject if called in a private browsing context. From d7b965be112d733c183bd29871b5bc03a189f7c0 Mon Sep 17 00:00:00 2001 From: Diego Gonzalez <73939538+diekus@users.noreply.github.com> Date: Thu, 27 Feb 2025 21:17:09 +0000 Subject: [PATCH 03/12] Update WebInstall/explainer.md Co-authored-by: Howard Wolosky --- WebInstall/explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/WebInstall/explainer.md b/WebInstall/explainer.md index af0946f8..d1f94079 100644 --- a/WebInstall/explainer.md +++ b/WebInstall/explainer.md @@ -350,7 +350,7 @@ Pros: Cons: * Takes the user out of the current context, providing no alternative if the use case benefits from them staying in context. -* Limits the amount of information a developer can act upon that the promise provides, such as if the prompt was shown. +* Limits the amount of information a developer can act upon that the promise provides, such as if the installation was successful. * Developers can't modify their UX to tailor to situations where the origin permission isn't granted. * No support for the concept of an `install_url` (requires additional work to the HTML specification). * Can't easily pass additional information like the referral-info. From 80d1c793d9a9eddda2e3d7ae2ee83bbc532d4c97 Mon Sep 17 00:00:00 2001 From: Diego Gonzalez <73939538+diekus@users.noreply.github.com> Date: Thu, 27 Feb 2025 21:17:22 +0000 Subject: [PATCH 04/12] Update WebInstall/explainer.md Co-authored-by: Howard Wolosky --- WebInstall/explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/WebInstall/explainer.md b/WebInstall/explainer.md index d1f94079..8069882e 100644 --- a/WebInstall/explainer.md +++ b/WebInstall/explainer.md @@ -351,7 +351,7 @@ Pros: Cons: * Takes the user out of the current context, providing no alternative if the use case benefits from them staying in context. * Limits the amount of information a developer can act upon that the promise provides, such as if the installation was successful. -* Developers can't modify their UX to tailor to situations where the origin permission isn't granted. +* Developers can't easily detect UA declarative support in order to be able to tailor their UX to different situations. * No support for the concept of an `install_url` (requires additional work to the HTML specification). * Can't easily pass additional information like the referral-info. From cd538bd8dec52108512af7472f82bbc3a93aea32 Mon Sep 17 00:00:00 2001 From: Diego Gonzalez <73939538+diekus@users.noreply.github.com> Date: Thu, 27 Feb 2025 21:17:33 +0000 Subject: [PATCH 05/12] Update WebInstall/explainer.md Co-authored-by: Howard Wolosky --- WebInstall/explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/WebInstall/explainer.md b/WebInstall/explainer.md index 8069882e..671b4f7e 100644 --- a/WebInstall/explainer.md +++ b/WebInstall/explainer.md @@ -353,7 +353,7 @@ Cons: * Limits the amount of information a developer can act upon that the promise provides, such as if the installation was successful. * Developers can't easily detect UA declarative support in order to be able to tailor their UX to different situations. * No support for the concept of an `install_url` (requires additional work to the HTML specification). -* Can't easily pass additional information like the referral-info. +* No clear way to pass additional information intended for the UA (like the referral-info). **Another alternate solution based in a declarative approach could see the use of the [rel](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel) attribute to hint to the UA that the url in the link should be installed.** From ddaabc94d139d915c54909ec5b095cd05668f621 Mon Sep 17 00:00:00 2001 From: Diego Gonzalez <73939538+diekus@users.noreply.github.com> Date: Thu, 27 Feb 2025 21:17:44 +0000 Subject: [PATCH 06/12] Update WebInstall/explainer.md Co-authored-by: Howard Wolosky --- WebInstall/explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/WebInstall/explainer.md b/WebInstall/explainer.md index 671b4f7e..0696d8d2 100644 --- a/WebInstall/explainer.md +++ b/WebInstall/explainer.md @@ -352,7 +352,7 @@ Cons: * Takes the user out of the current context, providing no alternative if the use case benefits from them staying in context. * Limits the amount of information a developer can act upon that the promise provides, such as if the installation was successful. * Developers can't easily detect UA declarative support in order to be able to tailor their UX to different situations. -* No support for the concept of an `install_url` (requires additional work to the HTML specification). +* No support for the concept of an `install_url` (requires additional work to the HTML specification). Using an `install_url` as the `href` could confusingly land the user on a seemingly blank page for UA's that don't support declarative install. * No clear way to pass additional information intended for the UA (like the referral-info). **Another alternate solution based in a declarative approach could see the use of the [rel](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel) attribute to hint to the UA that the url in the link should be installed.** From e3f8de57e1bc1388eaa8f25d400d95fde126c6e5 Mon Sep 17 00:00:00 2001 From: Diego Gonzalez <73939538+diekus@users.noreply.github.com> Date: Thu, 27 Feb 2025 21:17:58 +0000 Subject: [PATCH 07/12] Update WebInstall/explainer.md Co-authored-by: Howard Wolosky --- WebInstall/explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/WebInstall/explainer.md b/WebInstall/explainer.md index 0696d8d2..bc106eaf 100644 --- a/WebInstall/explainer.md +++ b/WebInstall/explainer.md @@ -370,7 +370,7 @@ Cons (same as above plus): Having stated this, we believe that a declarative implementation is a simple and effective solution, and a future entry point for the API. It should be [considered for a v2](#future-work) of the capability. For the current solution, **we've decided to go with an imperative implementation since it allows more control over the overall installation UX**: * Allows the source to detect if an installation occurred with ease. (resolves/rejects a promise). -* Supports `install_url`. This url can be an optimized url or the normal homepage that an application already has. The advantage is that unlike a declarative version, there is no scenario where an end user can be left stranded accidentally in a blank page that is meant to be a lightweight entry point to the app. +* Supports `install_url`. This url can be an optimized url or the normal homepage that an application already has. The advantage is that unlike a declarative version, there is no scenario where an end user can be left stranded accidentally in a blank page that is meant to be a lightweight entry point to the app. * Code can be used to detect if an origin has permission to install apps, and UX can be tailored to change accordingly (for example, remove a button or display a link instead). * The developer ergonomics of handling a promise are better than responding to an `a` tag navigation. * Keeps the user in the context, which *can* be beneficial in certain scenarios (if the developer *wants* to take the user out of the current context, they *can* do so with a `a` tag). From 7abd3db4bae3ad9c0695e93391e2a469d3749560 Mon Sep 17 00:00:00 2001 From: diekus <73939538+diekus@users.noreply.github.com> Date: Thu, 27 Feb 2025 21:29:45 +0000 Subject: [PATCH 08/12] Rewrite of declarative alternate * Streamlines the declarative alternative explanation --- WebInstall/explainer.md | 23 +++++++---------------- 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/WebInstall/explainer.md b/WebInstall/explainer.md index bc106eaf..9c4219e4 100644 --- a/WebInstall/explainer.md +++ b/WebInstall/explainer.md @@ -340,40 +340,31 @@ The install capability should not work on *incognito*, and the promise should al ### Declarative install -**An alternate solution to allow installation of web apps is by allowing a new target type of `_install` to the HTML anchor tag.** +An alternate solution is to have a declarative way to install web apps. This can be achieved by allowing a new `target` type of `_install` to the HTML anchor tag. It can also use the [`rel`](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel) attribute to hint to the UA that the url in the link should be installed `honk` -Pros: +`honk` + +*Pros:* * Platform fallback to navigate to the content automatically. * Does not need JavaScript. -Cons: +*Cons:* * Takes the user out of the current context, providing no alternative if the use case benefits from them staying in context. * Limits the amount of information a developer can act upon that the promise provides, such as if the installation was successful. * Developers can't easily detect UA declarative support in order to be able to tailor their UX to different situations. * No support for the concept of an `install_url` (requires additional work to the HTML specification). Using an `install_url` as the `href` could confusingly land the user on a seemingly blank page for UA's that don't support declarative install. * No clear way to pass additional information intended for the UA (like the referral-info). - -**Another alternate solution based in a declarative approach could see the use of the [rel](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel) attribute to hint to the UA that the url in the link should be installed.** - -`honk` - -Pros (same as above): -* Basic platform default fallback (navigation). -* Does not need JavaScript. - -Cons (same as above plus): -* Unintended navigation to `install_url`: If a UA doesn't implement the web install feature, and the `install_url` is used in the `href` value, it may fallback to navigate to that `install_url`, potentially leaving the end user in a blank document. (this could be resolved by creating more attributes to the `a` tag to define the additional parameters that the feature requires). * Longer `a` tags: if we address the missing `install_url` and `manifest_id` parameters and decided to keep the `href` as a link then we could be potentially introducing lengthier and less readable tags similar to: `honk`. * More complex combinations for the UA to take into account: additional attributes that act on a link HTML tag (`a`) like the target mean there is an increased set of scenarios that might have unintended consequences for end users. For example, how does a target of `_ top` differ from `_blank`? While we could look at ignoring the `target` attribute if a `rel` attribute is present, the idea is to use acquisition mecanisms that are already present in UAs. Having stated this, we believe that a declarative implementation is a simple and effective solution, and a future entry point for the API. It should be [considered for a v2](#future-work) of the capability. For the current solution, **we've decided to go with an imperative implementation since it allows more control over the overall installation UX**: * Allows the source to detect if an installation occurred with ease. (resolves/rejects a promise). * Supports `install_url`. This url can be an optimized url or the normal homepage that an application already has. The advantage is that unlike a declarative version, there is no scenario where an end user can be left stranded accidentally in a blank page that is meant to be a lightweight entry point to the app. -* Code can be used to detect if an origin has permission to install apps, and UX can be tailored to change accordingly (for example, remove a button or display a link instead). +* Code can be used to detect if an origin has [permission](#new-installation-permission-for-origin) to install apps, and UX can be tailored to change accordingly (for example, remove a button or display a link instead). * The developer ergonomics of handling a promise are better than responding to an `a` tag navigation. -* Keeps the user in the context, which *can* be beneficial in certain scenarios (if the developer *wants* to take the user out of the current context, they *can* do so with a `a` tag). +* Keeps the user in the context, which *can* be beneficial in certain scenarios (if the developer *wants* to take the user out of the current context, they *can* do so with a `a` tag). ### `install_sources` manifest field From c5345d3dc71c8a839792b82ffaf1d6cfc8b34921 Mon Sep 17 00:00:00 2001 From: Diego Gonzalez <73939538+diekus@users.noreply.github.com> Date: Fri, 28 Feb 2025 10:08:41 +0000 Subject: [PATCH 09/12] Update WebInstall/explainer.md Co-authored-by: Howard Wolosky --- WebInstall/explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/WebInstall/explainer.md b/WebInstall/explainer.md index 9c4219e4..269dcf9b 100644 --- a/WebInstall/explainer.md +++ b/WebInstall/explainer.md @@ -340,7 +340,7 @@ The install capability should not work on *incognito*, and the promise should al ### Declarative install -An alternate solution is to have a declarative way to install web apps. This can be achieved by allowing a new `target` type of `_install` to the HTML anchor tag. It can also use the [`rel`](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel) attribute to hint to the UA that the url in the link should be installed +An alternate solution is to have a declarative way to install web apps. This can be achieved by allowing a new `target` type of `_install` to the HTML anchor tag. It can also use the [`rel`](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel) attribute to hint to the UA that the url in the link should be installed. `honk` From 38051d7fe6c0e2fdddce42c1f39061ae1e97bbf4 Mon Sep 17 00:00:00 2001 From: Diego Gonzalez <73939538+diekus@users.noreply.github.com> Date: Fri, 28 Feb 2025 10:08:56 +0000 Subject: [PATCH 10/12] Update WebInstall/explainer.md Co-authored-by: Howard Wolosky --- WebInstall/explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/WebInstall/explainer.md b/WebInstall/explainer.md index 269dcf9b..0c3bb884 100644 --- a/WebInstall/explainer.md +++ b/WebInstall/explainer.md @@ -357,7 +357,7 @@ An alternate solution is to have a declarative way to install web apps. This can * No support for the concept of an `install_url` (requires additional work to the HTML specification). Using an `install_url` as the `href` could confusingly land the user on a seemingly blank page for UA's that don't support declarative install. * No clear way to pass additional information intended for the UA (like the referral-info). * Longer `a` tags: if we address the missing `install_url` and `manifest_id` parameters and decided to keep the `href` as a link then we could be potentially introducing lengthier and less readable tags similar to: `honk`. -* More complex combinations for the UA to take into account: additional attributes that act on a link HTML tag (`a`) like the target mean there is an increased set of scenarios that might have unintended consequences for end users. For example, how does a target of `_ top` differ from `_blank`? While we could look at ignoring the `target` attribute if a `rel` attribute is present, the idea is to use acquisition mecanisms that are already present in UAs. +* More complex combinations for the UA to take into account: additional attributes that act on a link HTML tag (`a`) like the target mean there is an increased set of scenarios that might have unintended consequences for end users. For example, how does a target of `_ top` differ from `_blank`? While we could look at ignoring the `target` attribute if a `rel` attribute is present, the idea is to use acquisition mechanisms that are already present in UAs. Having stated this, we believe that a declarative implementation is a simple and effective solution, and a future entry point for the API. It should be [considered for a v2](#future-work) of the capability. For the current solution, **we've decided to go with an imperative implementation since it allows more control over the overall installation UX**: * Allows the source to detect if an installation occurred with ease. (resolves/rejects a promise). From 49a564e2d6cf315e6ec68384ba00b2de0e80a259 Mon Sep 17 00:00:00 2001 From: Diego Gonzalez <73939538+diekus@users.noreply.github.com> Date: Fri, 28 Feb 2025 10:09:11 +0000 Subject: [PATCH 11/12] Update WebInstall/explainer.md Co-authored-by: Howard Wolosky --- WebInstall/explainer.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/WebInstall/explainer.md b/WebInstall/explainer.md index 0c3bb884..a8d06e8a 100644 --- a/WebInstall/explainer.md +++ b/WebInstall/explainer.md @@ -362,7 +362,8 @@ An alternate solution is to have a declarative way to install web apps. This can Having stated this, we believe that a declarative implementation is a simple and effective solution, and a future entry point for the API. It should be [considered for a v2](#future-work) of the capability. For the current solution, **we've decided to go with an imperative implementation since it allows more control over the overall installation UX**: * Allows the source to detect if an installation occurred with ease. (resolves/rejects a promise). * Supports `install_url`. This url can be an optimized url or the normal homepage that an application already has. The advantage is that unlike a declarative version, there is no scenario where an end user can be left stranded accidentally in a blank page that is meant to be a lightweight entry point to the app. -* Code can be used to detect if an origin has [permission](#new-installation-permission-for-origin) to install apps, and UX can be tailored to change accordingly (for example, remove a button or display a link instead). +* Code can be used to detect if an origin has [permission](#new-installation-permission-for-origin) to install apps, as well as if the UA supports the API, and UX can be tailored to change accordingly (for example, remove a button or display a link instead). +* ``` * The developer ergonomics of handling a promise are better than responding to an `a` tag navigation. * Keeps the user in the context, which *can* be beneficial in certain scenarios (if the developer *wants* to take the user out of the current context, they *can* do so with a `a` tag). From 7a9fe1465657131f5cfc4bab473b80e23e7ee4cc Mon Sep 17 00:00:00 2001 From: diekus <73939538+diekus@users.noreply.github.com> Date: Fri, 28 Feb 2025 10:23:00 +0000 Subject: [PATCH 12/12] Adds context example * Adds mention of a use case where it makes sense to keep the context for the end user while installing. --- WebInstall/explainer.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/WebInstall/explainer.md b/WebInstall/explainer.md index a8d06e8a..a7605e2e 100644 --- a/WebInstall/explainer.md +++ b/WebInstall/explainer.md @@ -352,6 +352,7 @@ An alternate solution is to have a declarative way to install web apps. This can *Cons:* * Takes the user out of the current context, providing no alternative if the use case benefits from them staying in context. + * For example, in an online app repository, if the user is installing applications, they do not expect to navigate away from said repository. This is a scenario where keeping context is important as it can provide the end user with a level of trust. * Limits the amount of information a developer can act upon that the promise provides, such as if the installation was successful. * Developers can't easily detect UA declarative support in order to be able to tailor their UX to different situations. * No support for the concept of an `install_url` (requires additional work to the HTML specification). Using an `install_url` as the `href` could confusingly land the user on a seemingly blank page for UA's that don't support declarative install. @@ -363,9 +364,8 @@ Having stated this, we believe that a declarative implementation is a simple and * Allows the source to detect if an installation occurred with ease. (resolves/rejects a promise). * Supports `install_url`. This url can be an optimized url or the normal homepage that an application already has. The advantage is that unlike a declarative version, there is no scenario where an end user can be left stranded accidentally in a blank page that is meant to be a lightweight entry point to the app. * Code can be used to detect if an origin has [permission](#new-installation-permission-for-origin) to install apps, as well as if the UA supports the API, and UX can be tailored to change accordingly (for example, remove a button or display a link instead). -* ``` * The developer ergonomics of handling a promise are better than responding to an `a` tag navigation. -* Keeps the user in the context, which *can* be beneficial in certain scenarios (if the developer *wants* to take the user out of the current context, they *can* do so with a `a` tag). +* Keeps the user in the context, which *can* be beneficial in certain scenarios (importantly, if the developer *wants* to take the user out of the current context, they *can* do so by navigating). ### `install_sources` manifest field