Moves BeforeInstallPrompt and related text to a non-normative annex.

[mgiuca]

This change (choose one):

• Breaks existing normative behavior (please add label "breaking")
• Adds new normative requirements
• Adds new normative recommendations or optional items
• Makes only editorial changes (only changes informative sections, or
  changes normative sections without changing behavior)
• Is a "chore" (metadata, formatting, fixing warnings, etc).

Implementation commitment:

• Safari (commitment to not implement — beforeinstallprompt : Prompting user makes it to hard to discern whether the user truly wanted to "install" a web app #835)
• Chrome (acknowledgment of removal from standard — Remove beforeinstallprompt and appinstalled events. #836)
• Firefox (commitment to not implement — API to "install" a web application mozilla/standards-positions#84)
• Edge (acknowledgment of removal from standard — Remove beforeinstallprompt and appinstalled events. #836)

Commit message:

Due to lack of multiple implementations, BeforeInstallPrompt is being removed
from the standard.

However, the event is going to continue to exist in Chromium-based browsers, and
has widespread use on the web. Therefore, instead of removing it from this
specification document, it is being moved into a non-normative annex, which
clearly states that the feature does not need to be implemented for standards
compliance, but provides a place to host the text for implementations that wish
to participate.

This makes a few minor normative changes, notably that the spec previously said
the user agent "MUST" notify that an install prompt is available before showing
an automated install prompt; this text has been removed from the normative part
of the document (and the corresponding non-normative text says "SHOULD").

This also makes the "appinstalled" event non-optional again. It was erroneously
labelled as optional in October 2019 when beforeinstallprompt was.

Closes #835.

---

Preview | Diff

[mgiuca]

Counter-proposal to #836, suggested by @slightlyoff.

I have made sure that there are no references from the normative part of the document into the non-normative annex.

[marcoscaceres]

I'm not in favor of this, tbh... it will just confuse everyone and somewhat circumvents the standardization process.

[dominickng]

In what way will it confuse people? The text is clear that it's non-normative (so it is not required).

Additionally, we're trying to ensure that implementors who choose to add a developer-triggered prompting mechanism have strong guidance based what was previously in the spec (and shipped in several browsers).

[mgiuca]

it will just confuse everyone

I don't see how it could be confusing when it clearly explains what it's doing in that section.

It would be more confusing if developers went looking for the text specifying this feature which has been in multiple browsers for years and can't find it anywhere.

and somewhat circumvents the standardization process.

I hear you. We don't want random proprietary APIs living inside of standards documents as a general rule. This case is a bit different, though, because it has been exposed through multiple browsers (even if their implementation is not independent) for many years while being in the standard. It's more of a "soft touch" to downgrade it from being in the standard to being in a non-normative annex, than removing it entirely.

[marcoscaceres]

So, I'm a "no" on this because it feels like it's working around the problem/process that other implementers don't want to ship this feature. But I'm open to hearing from other implementers.

[marcoscaceres]

I don't see how it could be confusing when it clearly explains what it's doing in that section.

Sorry, I meant more generally in the community (not us standards folks). I'm thinking of random developers seeing BIP in the spec and wondering why it's not supported in multiple engines (not browsers).

It would be more confusing if developers went looking for the text specifying this feature which has been in multiple browsers for years and can't find it anywhere.

Yeah, this is were it gets murky and get circle back to the "but it's all just Blink, not independent implementations!"😭 Reality vs standards. Let's refrain from discussing that again: thus I'd rather we reach consensus on this based on the two proposals.

I'm also concerned about setting a precedence for this at the W3C. The ECMAScript annex hints at the problems (i.e., those things are only available on under certain conditions, for legacy reasons, on particular engines, etc.).

@dominickng wrote:

Additionally, we're trying to ensure that implementors who choose to add a developer-triggered prompting mechanism have strong guidance based what was previously in the spec (and shipped in several browsers).

This implies that there would be multiple independent implementations for the purpose of standardization, which is was not the case: that's what brought us to the original pull request to remove BIP.

@mgiuca wrote:

I hear you. We don't want random proprietary APIs living inside of standards documents as a general rule. This case is a bit different, though, because it has been exposed through multiple browsers (even if their implementation is not independent) for many years while being in the standard. It's more of a "soft touch" to downgrade it from being in the standard to being in a non-normative annex, than removing it entirely.

Yes, that's why I'm also open to leaving it if others feel we should leave it in as per this PR.

So to be clear: I'm a "no" on having this in the spec, but if other folks feel it's ok I won't definitely won't object to having it in there.

@rniwa, @aarongustafson, what say you? Leave it or ditch it?

[rniwa]

I agree with @marcoscaceres here. I don't think leaving it in appendix or non-normative section makes sense given there is exactly one implementation of this feature. As things stand, this is a Blink only proprietary feature.

We don't mention or add other proprietary APIs to the appendix of other specifications even if those were a part of draft standards at some point in the past so I don't see why beforeinstallprompt is special.

[slightlyoff]

@marcoscaceres's argument about "engines, not browsers" (to paraphrase) is deeply problematic in this instance. Nearly all of the work of providing UI for installation is browser specific. Samsung Internet, Chrome, UC, Opera, and others all have separate implementations of these surfaces.

A non-normative annex is already bending over backwards in this regard. Failing to weigh the independent implementations by many browser teams here is...uncouth.

[rniwa]

@marcoscaceres's argument about "engines, not browsers" (to paraphrase) is deeply problematic in this instance. Nearly all of the work of providing UI for installation is browser specific. Samsung Internet, Chrome, UC, Opera, and others all have separate implementations of these surfaces.

Whether UI itself has multiple implementations or not is irrelevant since that’s not a normative part of the specification (if it were, that would be also deeply troubling). What’s normative & observable by web content is the Web API surface, and that does not have multiple independent implementations.

Also, if we were to accept your argument that “UI is implemented independently,” then a similar argument can be made for any Web API that has significant platform integration. Almost everything related to form control rendering, UI events such as pointer events, and user interactions like drag & drop on iOS and macOS are implemented independently in WebKit. Yet, I don’t think we should consider Safari on iOS and Safari on macOS to be two independent implementations of respective specifications because the underlying engine which expose those API is the same.

[rniwa]

As another example, WebKit on iOS has a completely different compositing model than WebKit on macOS (compositing is done using different API in browser’s process in iOS but done in Web content’s process in macOS). As a result, any feature that affect stacking context, hit testing, or scrolling would need be implemented separately. Should we consider two of these WebKit ports to have multiple independent implementations of all relevant features? I don’t think so.

On top of that, we have two variants of WebKit integration layers in iOS and macOS: WebKit1 and WebKit2! All the things I said above apply here too.

Therefore, if we were to take your argument, we can say any feature that affects stacking context, hit testing, or scrolling implemented in WebKit would have 4 multiple independent implementations.

[erikmchut]

Adding my comment from #836

From a user privacy perspective, it is always better, (and frequently a legal requirement), to inform the user in clear, understandable terms what they are agreeing to. The beforeinstallprompt is a key component in user privacy for PWAs. beforeinstallprompt allows a website to clearly and concisely explain to the user what installing a specific app means and what the user benefit is for doing so.

If the beforeinstallprompt event is removed, the user is surprised by a prompt with little context due to the generic messaging in the default prompt. Frequently this default prompt comes at the wrong time in the user lifecycle and leads to user confusion. I've read through the above thread and linked issue, and it feels misguided -- the working group included beforeinstallprompt in the standard as an essential privacy-preserving component.

[aarongustafson]

My personal feeling is that we are still testing all of this PWA stuff out and we don’t know what will end up sticking and what won’t. We could remove this now and find out we really should have kept it later. Or not. If we move it to some sort of appendix to the spec and make it non-normative, it can hang out for a bit and we can always remove it (like an appendix) if it becomes clear we don’t need it.

I’ll circle the wagons on our side and come back with a more official position on this tomorrow.