I took another look and it looks like the reflected attributes can return null: https://github.com/web-platform-tests/wpt/blob/1b81534c42533f63bf293db633598f9ff9ab6aba/html/semantics/permission-element/install/install-element-url-attributes.tentative.html#L10-L15
That never happens for other HTML elements with reflected URL attributes AFAICT, so I think this is also important to change as it's part of the API surface. On Wed, Sep 30, 2026 at 5:51 PM Philip Jägenstedt <[email protected]> wrote: > LGTM2 > > Can you please file an issue on https://github.com/whatwg/html/issues > about integrating this into the HTML spec if implementer interest from > Gecko or WebKit materializes? > > I looked over the spec with a "what if this were a HTML PR" lens and filed > these two issues: > https://github.com/WICG/install-element/issues/36 > https://github.com/WICG/install-element/issues/37 > > At least the first is about the API shape, so if you agree can please you > make that change to spec and impl before shipping? (For the second I'm not > sure if null is ever returned by the implementation, and if not it's just a > matter of clearer Web IDL types.) > > On Wed, Sep 30, 2026 at 5:03 PM Rick Byers <[email protected]> wrote: > >> LGTM1 >> >> As for the install API >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/6pb1UvLMXko?e=48417069>, >> I believe all API owner requirements have been met. >> >> This is exactly the sort of scenario capability elements were designed >> for: they give us a mechanism that is both user-initiated and >> browser-UI-controlled while also enabling site developers to PLACE and TIME >> the UI appropriately for their application. From all the evidence and public >> debate >> <https://open-web-advocacy.org/apple-dma-review/#implement-web-app-install-prompts-for-ios-safari-and-wKWebView-browsers> >> I have seen (including Safari's rich support for promoting native app >> install >> <https://developer.apple.com/documentation/webkit/promoting-apps-with-smart-app-banners>), >> I believe WebKit's opposition to this has more to do with what's best for >> Apple's business model than what's in the best interest of users and >> developers of the web. >> >> Rick >> >> On Mon, Sep 21, 2026 at 11:38 AM 'Lia Hiscock' via blink-dev < >> [email protected]> wrote: >> >>> *Contact emails* >>> >>> [email protected], [email protected], [email protected] >>> >>> *Explainer* >>> >>> https://aka.ms/installelement >>> >>> *Specification* >>> >>> https://wicg.github.io/install-element >>> >>> *Design docs* >>> >>> https://docs.google.com/document/d/1rGvLhD4SR8Y9M1wVmqgyesPNkbZGU7HOqlttjEFJ5Vo/edit?tab=t.tmx19oox759l#heading=h.j3tt49hqiuck >>> >>> *Summary* >>> >>> Triggers a request for the browser to install a web app, given a >>> manifest URL and optional manifest ID. The <install> element enables >>> cross-origin web app installation without JavaScript and provides a better >>> developer experience than handling beforeinstallprompt events. The >>> element is proposed to ship together with navigator.install(), the >>> imperative entry point to the same installation capability: >>> https://chromestatus.com/feature/5183481574850560 >>> >>> >>> >>> Enterprises can control this in two ways - (1) Enterprise policy, >>> WebAppInstallByUserEnabled, can disable user web app installs broadly, >>> including installs initiated via navigator.install() and <install>. Or (2) >>> Permissions Policy, web-app-installation, can allow or disallow use of this >>> feature on origins the enterprise controls (for example, internal >>> sites/iframes). >>> >>> *Blink component* >>> >>> Blink>AppManifest >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EAppManifest%22> >>> >>> *Web Feature ID* >>> >>> install <https://webstatus.dev/features/install> >>> >>> *Motivation* >>> >>> The web currently lacks the ability for a site to offer installation of >>> a web app identified by a cross-origin manifest. Limited support exists for >>> eligible same-origin web apps via ambient installation affordances and the >>> beforeinstallprompt event. However, the existent browser-provided entry >>> points are difficult for developers to use and users to discover. >>> >>> >>> >>> This capability lets developers distribute web apps across the web >>> without proprietary protocols or platform-specific stores. It brings web >>> app distribution closer to the reach developers expect from other >>> application models while preserving browser-controlled safeguards and >>> explicit user choice. >>> >>> >>> >>> *Initial public proposal* >>> >>> https://aka.ms/installelement >>> >>> *Search tags* >>> >>> webinstall <https://chromestatus.com/features#tags:webinstall>, >>> webappinstallation >>> <https://chromestatus.com/features#tags:webappinstallation>, >>> webinstallapi <https://chromestatus.com/features#tags:webinstallapi>, >>> installelement <https://chromestatus.com/features#tags:installelement> >>> >>> *TAG review* >>> >>> https://github.com/w3ctag/design-reviews/issues/1245 >>> >>> >>> >>> *TAG review status* >>> >>> Issues open >>> >>> >>> >>> Review was requested two months ago with updates addressing concerns >>> raised in the earlier design review: >>> https://github.com/w3ctag/design-reviews/issues/1051. The TAG has not >>> yet provided substantive feedback on the updated API shape or design. A >>> recent TAG meeting agreed to develop a finding about the broader capability >>> of web app installation and prompting. That work remains open, and we will >>> continue participating in it. >>> >>> *Origin Trial Name* >>> >>> HTML Install Element >>> >>> *Chromium Trial Name* >>> >>> InstallElement >>> >>> *Link to origin trial feedback summary* >>> >>> >>> https://docs.google.com/document/d/1B21htNQFmhEhhIpnIU7z_jOeH9wEF1Hz9XSKlMWW3a0/edit?pli=1&tab=t.0 >>> >>> >>> *Origin Trial documentation link* >>> >>> Demos/pwa-install-element/README.md at main · MicrosoftEdge/Demos >>> <https://github.com/MicrosoftEdge/Demos/blob/main/pwa-install-element/README.md> >>> >>> *WebFeature UseCounter name* >>> >>> WebDXFeature::install >>> >>> *Risks* >>> >>> >>> >>> *Interoperability and Compatibility* >>> >>> These are additive entry points to web app installation, a capability >>> browsers already provide through browser-controlled UI. The primary >>> interoperability risk is uneven cross-browser availability rather than >>> conflicting behavior for existing content: other engines have not committed >>> to these entry points, and WebKit opposes site-initiated web app >>> installation. >>> >>> >>> WebKit opposes these entry points because it considers installation a >>> user decision whose flow should begin in browser UI. We acknowledge this >>> substantive difference in approach. However, origin-trial partners, public >>> developer reports, and standards discussions consistently identified >>> existing web app installation as difficult for users to discover and >>> cumbersome for developers to offer. Developers expressed strong support for >>> a direct and predictable installation path while retaining >>> browser-controlled confirmation UI and existing installability requirements. >>> >>> >>> >>> Our designs preserve browser control over installation through required >>> user activation, explicit consent in browser-controlled UI, and the user >>> agent’s ability to suppress the flow. The <install> element further >>> provides user-agent-controlled rendering. Detailed abuse, privacy, and >>> security protections are described in our explainer and our TAG review >>> request. Given those safeguards and the demonstrated developer and user >>> need, we believe shipping in Chromium is appropriate while standards >>> discussions continue. >>> >>> >>> >>> *Gecko*: No signal ( >>> https://github.com/mozilla/standards-positions/issues/1179) >>> >>> *WebKit*: Oppose ( >>> https://github.com/WebKit/standards-positions/issues/463) >>> >>> *Web developers*: Positive ( >>> https://github.com/w3ctag/ethical-web-principles/issues/120#issuecomment-2285348765) >>> >>> https://github.com/w3ctag/ethical-web-principles/issues/120#issuecomment-2285431557 >>> >>> *Other signals*: pwastore.io - >>> https://www.reddit.com/r/PWA/comments/1o1excp/comment/niit2jh/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button >>> >>> *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, such as (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. >>> >>> >>> >>> See explainer's security section - >>> https://github.com/WICG/install-element/blob/main/explainer-manifest-url.md#accessibility-localization-privacy-and-security-considerations >>> >>> *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 >>> >>> >>> >>> *Debuggability* >>> >>> Existing DevTools support for HTML elements applies. The base capability >>> element also reports customized DevTools Issues when the browser cannot >>> safely allow activation. In addition, Web Install failures for eligible >>> same-origin manifests are reported in the Issues panel using bounded >>> failure categories, such as manifest fetch or parse failure, invalid >>> start_url, and missing required fields. Cross-origin and internal failure >>> details are not reported. >>> >>> See Debuggability doc - >>> >>> https://docs.google.com/document/d/1rGvLhD4SR8Y9M1wVmqgyesPNkbZGU7HOqlttjEFJ5Vo/edit?tab=t.i3gxb63o1ngb >>> >>> >>> >>> *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* >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> *?* >>> >>> No >>> The element's base styling/activation restrictions are tested - >>> https://wpt.fyi/results/html/semantics/permission-element/install. >>> 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. >>> >>> *DevTrial instructions* >>> >>> >>> https://github.com/MicrosoftEdge/Demos/blob/main/pwa-install-element/README.md >>> >>> *Flag name on about://flags* >>> >>> web-app-install-element >>> >>> *Finch feature name* >>> >>> InstallElement >>> >>> *Rollout plan* >>> >>> Will ship enabled for all users >>> >>> *Requires code in //chrome?* >>> >>> False >>> >>> *Tracking bug* >>> >>> https://issues.chromium.org/issues/454827186 >>> >>> *Launch bug* >>> >>> https://launch.corp.google.com/launch/4495880 >>> >>> *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. >>> >>> *Availability expectation* >>> >>> Feature is available only in Chromium browsers for the foreseeable >>> future. >>> >>> *Adoption expectation* >>> >>> Feature is used by specific partner(s) to provide functionality within >>> 12 months of launch in Chrome. >>> >>> *Adoption plan* >>> >>> We are in communication with partners. We plan to post an update on >>> developer.chrome.com and blogs.windows.com, and add AI guidance for Web >>> Install to github.com/GoogleChrome/modern-web-guidance. >>> >>> *Non-OSS dependencies* >>> >>> *Does the feature depend on any code or APIs outside the Chromium open >>> source repository and its open-source dependencies to function?* >>> >>> No. >>> >>> *Estimated milestones* >>> >>> Shipping on desktop >>> >>> 156 >>> >>> Origin trial desktop first >>> >>> 148 >>> >>> Origin trial desktop last >>> >>> 153 >>> >>> >>> >>> *Anticipated spec changes* >>> >>> *Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way).* >>> >>> N/A >>> >>> *Link to entry on the Chrome Platform Status* >>> >>> https://chromestatus.com/feature/5152834368700416?gate=6500019899334656 >>> >>> *Links to previous Intent discussions* >>> >>> Intent to Experiment: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/N1AjeFmVF4U/m/YrAdZgaIAAAJ >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB2659F34720E44CB1DB438CD6D3842%40CH4PR00MB2659.namprd00.prod.outlook.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB2659F34720E44CB1DB438CD6D3842%40CH4PR00MB2659.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_tJGHbDgu3hS8%3Drt5WWsJP8WwBr6TmeK4kDfC1zvDW8g%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_tJGHbDgu3hS8%3Drt5WWsJP8WwBr6TmeK4kDfC1zvDW8g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYehH%2BKxCm-e5CbjwDz4JpreGBK7CPOSVu9CgKdU%2Bc8yJw%40mail.gmail.com.
