Intent to Experiment: Web app HTML install element
Lia Hiscock
Contact emails
liahi...@microsoft.com, krist...@microsoft.com, li...@microsoft.com
Explainer
Specification
No information provided
Summary
Allows a website to declaratively prompt users to install a web app. The element optionally accepts two attributes which allows installation of content from a different origin.
Blink component
Web Feature ID
Search tags
webinstall, webappinstallation, webinstallapi, installelement
TAG review
https://github.com/w3ctag/design-reviews/issues/1051 (This is technically the early design review for the imperative navigator.install – we went through several rounds of feedback off of this that influenced the shape of the installation capability significantly. The same origin capability was rated 'satisfied with concern' and only the cross-origin capability was rated 'unsatisfied'. This review is still relevant for this declarative HTML install element, as it’s simply a new entry point.)
TAG review status
Pending
Goals for experimentation
1 - Gather developer feedback on the ergonomics and usability (e.g. styling options) of the element.
2 - Compare data (including developer feedback) on the element-based install, with the imperative Web Install API (navigator.install), to inform future direction.
As part of navigator.install, 2 new UKMs and 2 UMAs were added. We've updated these so we can differentiate between the two entry points for direct comparison.
See experimentation goals for navigator.install - https://chromestatus.com/feature/5183481574850560
Risks
Interoperability and Compatibility
Interop - Low risk. This is a new entry point to the Web Install API that installs web apps, which are supported by other browsers.
The no-attribute version of the element (installs the current document) has enough support to be merged into the W3C web app manifest spec - https://github.com/w3c/manifest/pull/1175. It has also been reviewed favorably by TAG - https://github.com/w3ctag/design-reviews/issues/1051.
While the attribute versions of the element (installing a cross-origin document) are still under discussion in WICG, we have no reason to believe there will be interop risk with these additions.
Compatibility - Low risk. This is a new element that requires explicit developer action to use.
Gecko: No signal (Web Install capability · Issue #1179 · mozilla/standards-positions)
WebKit: No signal (Web Install API · Issue #463 · WebKit/standards-positions)
Web developers: Positive (Principle: The Web should not owned by anyone · Issue #120 · w3ctag/ethical-web-principles)
Other signals: pwastore.io -
pwastore.io - the PWA focused marketplace everyone deserve : r/PWA
Ergonomics
This could be used in conjunction with the navigator.getInstalledRelatedApps API, which tells a developer if any related web apps are installed for their site, before rendering the install element. There is overlap between this install element and the BeforeInstallPrompt event. This element is more ergonomic, and we think developers will prefer its declarative format. See this thread - https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1055
Activation
No activation risks. It should be relatively easy for developers to take advantage of this feature immediately, as-is. The element was designed with ergonomics in mind, and we have multiple places with instructions for developers (two test sites, and the explainer itself)
Security
The element proposal came out of security concerns with imperative APIs, specifically that an API to trigger the PWA installation flow cannot provide a strong enough signal of user intent to install an app, thereby increasing the risk of abuse and annoyance to users.
<install> inherits from a base capability element, which has many security protections. Some examples include (1) restrictions on element styling/sizing (eg. it cannot be fully transparent, and it has a minimum and maximum size), (2) preventing activation if out of view, or recently attached to the tree, and (3) preventing clipping/occlusion/distortion.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
N/A
Ongoing technical constraints
None
Debuggability
Existing DevTools support for HTML elements. The base capability element also raises customized DevTools issues if the browser believes it cannot safely allow the element to be activated. No new DevTools support is needed.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No
Windows, Mac, Linux, and ChromeOS will be shipped first. Android will be supported later, due to significant technical deviation in the web app ecosystem -
https://issues.chromium.org/issues/424497410. As of now, no plan to support Android WebView.
Is this feature fully tested by web-platform-tests?
No
The element's base behavior (styling/activation restrictions, etc) can be tested. See https://wpt.fyi/results/html/semantics/permission-element. However, web app installs are currently not supported by automated tests, as they require user interaction to confirm the installation. Manual web app testing instructions can be published.
Flag name on about://flags
web-app-install-element
Finch feature name
InstallElement
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/454827186
Measurement
We have a JavaScript use counter that tracks how often the element is found in pages (regardless of whether it can be activated). We also have chromium UMAs and UKMs.
Estimated milestones
|
Origin trial desktop first |
148 |
|
Origin trial desktop last |
153 |
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5152834368700416?gate=5998917676302336
This intent message was generated by Chrome Platform Status.