Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove beforeinstallprompt and appinstalled events. #836

Merged
merged 18 commits into from Apr 1, 2020
Merged

Conversation

marcoscaceres
Copy link
Member

@marcoscaceres marcoscaceres commented Dec 13, 2019

Closes #835
Closes #843
Closes #692

These should be relocated:
Closes #627
Closes #578
Closes #691

This change (choose one):

  • Breaks existing normative behavior (please add label "breaking")

Implementation commitment (delete if not making normative changes):

  • Safari - never implemented.
  • Chrome (link to issue)
  • Firefox - never shipped BIP, remove onappinstalled.
  • Edge (public signal)

Web platform tests:

Commit message:

As discussed in #835, the proposal is to remove "beforeinstallprompt" and leave it to browsers to provide better UI to surface installability of web applications. It also removes the window.appinstalled event handler. This also removes install prompting and the installation algorithm itself.


馃挜 Error: 500 Internal Server Error 馃挜

PR Preview failed to build. (Last tried on Apr 1, 2020, 12:54 PM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

馃毃 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.

馃敆 Related URL

Navigation timeout of 30000 ms exceeded

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

@marcoscaceres marcoscaceres added the breaking Use for changes that break existing normative behavior label Dec 13, 2019
@dominickng
Copy link
Collaborator

It would be good to let @mgiuca weigh in as well as the Edge folks before this lands.

@mgiuca
Copy link
Collaborator

mgiuca commented Dec 13, 2019

Sorry, I've had a hell of a week and haven't seen the thread #835 until just now. (I am sick now so I'm not going to try and figure out a rational position at this hour on a Friday night.)

Can we hold off on this until next week? Reading over the thread, there are reasonable arguments on both sides, so ultimately it should come down to whether there are enough browsers implementing the standard for it to remain in.

I'll make a couple of quick points:

  • Unlike other APIs, where the existence or absence of a method causes potential compatibility issues between browsers that sites have to deal with, BIP is an event that is specified as firing at the UA's discretion, which could be never. Therefore, sites do not need to explicitly account for the possibility that a UA hasn't implemented BIP (e.g., by detecting the presence of a method). They can just hook an event listener and if it never fires, oh well.
  • When we tried to modify BIP into a different API several years ago, we faced resistance from the fact that it wasn't just Chrome implementing. From memory, Samsung Internet and Opera and maybe other browsers had independently implemented this method. Now I suspect (but haven't confirmed) that Edge-on-Chromium will also include this feature. This may or may not be considered sufficient implementor interest, but it should give us pause before removing something from the standard. This isn't just a Chrome-proprietary feature.

@marcoscaceres
Copy link
Member Author

am sick now so I'm not going to try and figure out a rational position at this hour on a Friday night.

Absolutely, the proposal is for discussion and to reach consensus. No rush! Get well and we pick this up when you are back and feeling better!

@othermaciej
Copy link
Member

othermaciej commented Dec 13, 2019

Code to implement this event exists in Chromium, with a significant part, i.e. the event itself, lying in Blink:

https://cs.chromium.org/search/?q=beforeinstallprompt&sq=package:chromium&type=cs

Is there evidence that implementations in non-Chrome but Chromium-based browsers are or would be independent?

(In my view, independently implemented prompts or install actions that nonetheless use this shared code would not count as independent implementations, since the specification only deals with the event and its dispatch, not with whatever native prompt may be related to it.)

@dominickng
Copy link
Collaborator

Edge is an interesting case here, and I'd love for Microsoft folks (@aarongustafson) to weigh in here and make sure my understanding is correct.

Edge has a separate downstream repository that is kept up to date with Chromium, but my understanding is that Edge will ship features from the web platform layer upwards that Chromium does not have (where we diverge in opinions or the ability to accept implementations in Chromium at the time Microsoft implements them). Similarly, Edge would disable features that Chromium introduces for similar reasons, or adjust the implementation to suit their views.

Even if the actual code implementing the feature is shared inside Blink from Chromium, it still seems like Edge is making conscious choices about the web platform it chooses to ship, and not simply replicating what Chromium is doing. It seems a little harsh to say that they aren't independent when they do actually exhibit control and opinion down to the web platform layer.

@dominickng
Copy link
Collaborator

Also, I know one could argue that pretty much all Chromium derivatives have their own repositories and theoretically could diverge their web platform implementations, but Edge is possibly one of the few that are committed to doing so.

@rniwa
Copy link

rniwa commented Dec 14, 2019

Even if the actual code implementing the feature is shared inside Blink from Chromium, it still seems like Edge is making conscious choices about the web platform it chooses to ship, and not simply replicating what Chromium is doing. It seems a little harsh to say that they aren't independent when they do actually exhibit control and opinion down to the web platform layer.

The part where you say "actual code implementing the feature is shared inside Blink from Chromium" is the thing that says Edge does not constitute an independent implementation.

Consider this. Almost every port of WebKit ships a different set of features. In fact, Apple's macOS port and iOS port of WebKit ship a different set of features, and some features are even implemented in completely different code (e.g. anything related to touch or pointer events). Yet, I don't think we would consider each port of WebKit as an independent implementation of whatever Web feature.

Similarly, there are GTK+, WPE, WinCairo ports that are maintained by other companies, and each port ships their own browser (e.g. to PlayStation). All of these ports don't even share the same networking or graphics layer, and they also have a completely different backend for things like WebGL and storage. Yet we still wouldn't consider those ports as independent implementations either.

@othermaciej
Copy link
Member

Even if Microsoft was exercising some sort of editorial control, code from the same upstream repo implementing the same feature would still not be an independent implementation. The point of this general requirement is to demonstrate that the feature can be interoperably implemented from the spec, without having to copy specific code.

But even so, I'm not aware of Edge removing a significant number of (or really any) web-facing features that ship in Chrome.

@marcoscaceres
Copy link
Member Author

I agree. AFAIK, Microsoft folks have conceded that they are not an independent implementation for the purpose of standardization. However, @aarongustafson or @travisleithead can confirm.

Regardless, we wholeheartedly appreciate and value Microsoft鈥檚 input - as well as the input of any WebAppsWG member, which includes Samsung, and the developer community at large. However, we do have a (W3C) Process to follow and features that are not going to be interoperable due to lack of implementation must be removed from the spec.

@mgiuca
Copy link
Collaborator

mgiuca commented Dec 16, 2019

Hi Marcos,

As I wrote in #835, I'll leave the discussion of why folks are opposed to this API over there, and assume they Mozilla and Apple will not be implementing this.

Regardless, we wholeheartedly appreciate and value Microsoft鈥檚 input - as well as the input of any WebAppsWG member, which includes Samsung, and the developer community at large. However, we do have a (W3C) Process to follow and features that are not going to be interoperable due to lack of implementation must be removed from the spec.

Are you able to link me to the text of that process? Forgive my ignorance, I've never been very clear on what the exact rules are and it would be good to be speaking on the same page.

I'd like to clarify what Microsoft's role is now that they are using Chromium code. It seems unfortunate to me if two of the main browsers agree to implement something that we can't spec it on the grounds that those two browsers happen to share code.

Regardless, if this is taken out of the spec, I think it's unlikely it'll be removed from Chromium. There is too much developer demand for this feature, and we think we've found a good balance between developer demand and being respectful of the user. We would likely take the text of this API and move it into its own spec (maybe in WICG).

@rniwa
Copy link

rniwa commented Dec 16, 2019

See the following links I鈥檝e provided in the other issue:
W3C鈥檚 technical document requirement: https://www.w3.org/2019/Process-20190301/#implementation-experience
Web Apps WG鈥檚 working mode: https://www.w3.org/2019/05/webapps-charter.html#working-mode

Also please refer to my earlier comment about different ports of WebKit.

@marcoscaceres
Copy link
Member Author

See also the removal of features marked 鈥渁t risk鈥 as part of the CR phases. We are officially not in CR (for administrative reasons, because it would prevent us from iterating) - but for all intents and purposes we鈥檝e considered the API implementable for a while.

https://www.w3.org/2019/Process-20190301/#candidate-rec

https://www.w3.org/2019/Process-20190301/#revised-cr

@rniwa
Copy link

rniwa commented Dec 16, 2019

Regardless, if this is taken out of the spec, I think it's unlikely it'll be removed from Chromium. There is too much developer demand for this feature, and we think we've found a good balance between developer demand and being respectful of the user. We would likely take the text of this API and move it into its own spec (maybe in WICG).

FWIW, I don鈥檛 think moving to WICG is appropriate. WICG is a place for people to incubate ideas, not a place to hoard all the ideas that have failed or have been rejected (for the lack of better words) elsewhere.

In the case of a single vendor browser feature like this, producing a technical note or adding an obsolete section in the spec is what we鈥檇 usually do.

@mgiuca
Copy link
Collaborator

mgiuca commented Dec 16, 2019

Thanks for the links folks.

I'd like to get Microsoft's feedback on this (btw I checked, Edge Canary does support this feature) and continue discussing with Google web people. Since people are starting to go away on holidays (I will be out after this week ends) I would suggest we hold off on the removal until January.

WICG might not be the right place for it. We're essentially talking about maintaining a feature in Chromium long-term that is not a web platform standard (not something we usually try to do) so it's not clear what we'd do with the spec text. But I'd like for it to be hosted somewhere rather than this simply being an "undocumented" feature of Chromium-derived browsers.

@marcoscaceres
Copy link
Member Author

@rniwa wrote:

FWIW, I don鈥檛 think moving to WICG is appropriate. WICG is a place for people to incubate ideas, not a place to hoard all the ideas that have failed or have been rejected (for the lack of better words) elsewhere.

Essentially, what @rniwa writes this is correct. It would run into the same issue at the WICG: the WICG generally give incubations around year to mature and make progress, otherwise we archive them.

In the case of a single vendor browser feature like this, producing a technical note or adding an obsolete section in the spec is what we鈥檇 usually do.

My preference is keep them documented on MDN as Chrome-only feature clearly marked as non-standard. W3C Notes or otherwise on TR confuses people... alternatively, we host it as clearly marked "unofficial", similar to execCommand.

@marcoscaceres
Copy link
Member Author

marcoscaceres commented Dec 16, 2019

@mgiuca, waiting to next year for all stakeholders is fine. I'd also really like to hear from other folks. I'm also away all of from the 22nd of Dec until ~20th of January.

@aarongustafson
Copy link
Collaborator

Catching up鈥

But even so, I'm not aware of Edge removing a significant number of (or really any) web-facing features that ship in Chrome.

Nor am I.

I am in this week, but many of my colleagues are out through the 6th (or so) of January. I think we (Microsoft) need to have a chat about our overall position on BIP. I personally think it鈥檚 (potentially) useful, but I鈥檓 not sure it needs to be explicitly part of this spec. That said, I don鈥檛 have an objection to including a note in the spec about UAs being free to implement some form of prompting event, perhaps even with a specific callout of the existing (in this event "non-standard") beforeinstallprompt event name. I don鈥檛 know that any of us can claim to know how useful this particular event will be going into the future. Perhaps it will eventually claim multiple interoperable implementations and become a standard (like XHR did), but maybe not as part of this spec.

That said, this is purely my personal opinion. Let me see if there are conflicting views from others in Microsoft. I鈥檒l circle the wagons and respond in the new year.

Of course none of this changes the reality that we are not an independent rendering engine anymore鈥 but that鈥檚 another conversation for another day (and probably needs to happen in another venue).

@mgiuca
Copy link
Collaborator

mgiuca commented Dec 19, 2019

@aarongustafson

I personally think it鈥檚 (potentially) useful, but I鈥檓 not sure it needs to be explicitly part of this spec.

It doesn't need to be part of any spec in particular (it could, for instance, be its own spec document, which is where I'll put it if it gets removed from Manifest, though I'm not sure where to host it). But being part of Manifest seems like the most appropriate place for it, if it's going to be standard.

That said, I don鈥檛 have an objection to including a note in the spec about UAs being free to implement some form of prompting event, perhaps even with a specific callout of the existing (in this event "non-standard") beforeinstallprompt event name.

That doesn't sound good. That would mean different UAs could implement different, incompatible events, with different names, or with the same name but different methods, or with the same prompt() method but different semantics. That's precisely why we have standards, to establish a contract between developers and the web platform, so they don't have to write code specific to each browser.

If there is only one implementation (in Chromium), then it doesn't need to be (/ isn't allowed to be) in a W3C standard, because there aren't going to be several divergent implementations. But if ever a second independent implementation happens (say Mozilla changes their mind, or Microsoft rips out our code and writes their own implementation of beforeinstallprompt), then at that point, we will want an agreed standard. It doesn't make sense for the spec to non-normatively suggest beforeinstallprompt. It is either part of the standard (developers code against the standard), or it is not (developers can code against Chromium's implementation).

@briantbutton
Copy link

"and leave it to browsers to provide better UI to surface installability of web applications"

As a developer, it shocked me to read that coming from Mozilla. Back to the wild west, eh? I may have misunderstood the Mozilla mission.

May I ask what the Firefox browser plans to provide? On Firefox for Android, I have found nothing.
Is there a counter-proposal from Mozilla? Perhaps, rather than junking beforeinstallprompt, identify if there are specific deficiencies that can be repaired to make it "OK".

AFAIK, the "App Install" conveys no new privileges; so I don't see a security problem. Currently, users must click "yes" twice in succession to get an install on Chrome. So, the notion of an "accidental install" seems a bit spurious.

The nature of our App is that users will use it intensively and frequently for a few weeks; and when they use it, the "standalone" formatting is critical to a good experience. So we need the Web App installation.

Currently we deal with two different install mechanisms. One more won't hurt . . . much. But it really surprised me to see us making a policy to drive that way.

@mgiuca
Copy link
Collaborator

mgiuca commented Jan 20, 2020

Hi Marcos,

I've discussed the issue internally with various colleagues on Chrome.

@slightlyoff suggested as a compromise position that BeforeInstallPrompt be removed from the normative part of the spec, and placed into a "non-normative annex" at the bottom. He cited ECMAScript which has done this (e.g. https://www.ecma-international.org/ecma-262/5.1/#sec-B).

This annex would basically say "this is not part of the standard, and you do not need to implement it to comply with the standard, but, if you do implement it, you might want to implement this API rather than designing your own."

That would allow browsers that do implement it to remain in agreement (without having to go off and find a side document). Basically what @aarongustafson suggested earlier but it wouldn't be a vague note, it would be a complete non-normative specification. What do you think of that counter-proposal?

@mgiuca
Copy link
Collaborator

mgiuca commented Jan 20, 2020

I have put up a counter-proposal PR at #843. The normative effect of which should be largely the same as this PR, but it preserves the text of BeforeInstallPrompt non-normatively.

Also, I think this PR was over-zealous with its removal; it not only removes BeforeInstallPrompt but all of the normative prose surrounding install prompts, which I think is worth keeping. My PR keeps the non-BIP-related part of install prompting in the normative part of the document.

@erikmchut
Copy link

erikmchut commented Jan 29, 2020

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.

@david0178418
Copy link

As yet another web developer commenting on this, I greatly oppose this PR and favor @mgiuca's compromise in #843 (Honestly, I'm shocked that this functionality is being put on the chopping block at all).

As mentioned several times, the ability to badge an app as installable has immense value to both the users and developers. We need to begin to educate users that they don't need to go to the app store to get our apps. They are looking at it now and can install it to their device like any other app. Burying the option in the browser UI (especially browsers that conveniently further bury the option below the fold...) is essentially killing the functionality. Yes, every site can be installed. But giving this feature the same level of visibility in the context of a personal blog as you would a shopping list application or game that works entirely offline is just turning it into white noise that that the user will ignore.

Is the automatic prompt associated with the "beforeinstallprompt" event appropriate? I don't know. I feel like it shouldn't be automatic. After reviewing thread, the original issue raised by @rniwa (#835 "beforeinstallprompt : Prompting user makes it to hard to discern whether the user truly wanted to "install" a web app") does not seem to be the heart of the matter. This could be addressed with a counter proposal that would require user interaction before prompting the native WebAPK install/Add to Homescreen functionality. but as stated here: #835 (comment)

The real issue is the automatic "mini info bar" which shouldn't be automatic (or shouldn't exist at all) but let the developer decide when he can inform the user that the application is installable (and allow him to install it with the same experience despite browsers differences) is a must have.

I understand you and some other developers feel that way, but this is precisely what we're objecting. We don't want to give away that control to web apps / sites.

A lot of time could have been saved if the original issue had been stated as "beforeinstallprompt: Sites should not be allowed to prompt installability".

With that appearing to be the heart of the matter, like others, I'm having a very difficult time following the reasoning behind opposing this control. And judging from the other comments from web developers, I'm not the only one.

christianliebel pushed a commit to christianliebel/manifest that referenced this pull request May 27, 2020
As discussed in w3c#835, the proposal is to remove "beforeinstallprompt" and leave it to browsers to provide better UI to surface installability of web applications. It also removes the `window.appinstalled` event handler. This also removes install prompting and the installation algorithm itself.
@atjn atjn mentioned this pull request Sep 7, 2020
@Pauldb8
Copy link

Pauldb8 commented May 15, 2021

So that is it ?
Mozilla, the "champion" of the web, simply removed one of the most important features to gain traction for PWAs, and yet make the case for open web ? And all this without due diligence, with high developers support, high user demande for ui friendliness.
Nothing stated against make sense or adds up.
It feels like relegating the install button to share button behind the second row of icons is what Apple can do best, yet I understand, their business models is apps, but coming from Mozilla ?
I want this feature back, now. Implement it, nobody asked you what you thought, the web will prevail, and we will not be let down because of fake excuses. Proprietary apps store will lose market share because of this, good. User interaction will be improved, and Mozilla should better start backing up the web again. Come one why do we have to say this ?
And don't start with your 'we have it in mozilla preview'... Who uses that ? What is it even never heard that, we want it where users are. Today. Make the web worth it.

@dmurph
Copy link
Collaborator

dmurph commented May 15, 2021

I have a pull request to add it to the manifest-incubations spec. Might be able to get that in next week depending on my workload
WICG/manifest-incubations#9

@bathos
Copy link

bathos commented May 15, 2021

@dmurph I recently needed to consult the original spec text and it was pretty challenging to find the most recent version where it had still been specified, so it's greatly appreciated that you're giving it a proper home again.

@briantbutton
Copy link

briantbutton commented May 16, 2021

@Pauldb8, good to hear your comments. The conclusion reached above seems unsupportive of an open Web with consistent features supported cross-browsers and independent of OS. But not really our business . . . we have a job to do . . .

We are publishing a PWA that, with an in-house server that allows folks to do high performance sharing in non-urban environments. (http://www.button.network/usage.mp4; forward to 3:20). Initially marketed toward resort/retreats, we are also getting interest from the scads of schools worldwide that have sub-optimal Internet.

The conclusion reached here simply made us decide to not support Firefox. We didn't see any other another choice. We direct users to one of two browsers, depending on whether they are using IOS or not. This is not sentimental. We are fans of Mozilla and I have donated to it. This is business.

It does seem that a lot of other teams will be in our situation, and many will make the same decision. Strange that we are at this point.

@bathos
Copy link

bathos commented May 16, 2021

We also publish an installable PWA. In Firefox it鈥檚 not installable, of course, and we document in our FAQ that the application isn鈥檛 installable from all browsers, but to date I鈥檝e thought of this as falling somewhere in the progressive enhancement realm sorta. The application remains usable in Firefox, just as it remains usable in Chrome, etc, without installation. This seems pretty important given the user can choose not to install even in a browser where installation is supported, and likely wouldn鈥檛 want to install until first using it enough to decide that doing so would be worthwhile. (To me this seems like the rare case where 鈥渢he gap鈥 is reversed 鈥 PWAs have a fantastic capability in this regard that native apps lack.)

So your comment made me curious @briantbutton: what does 鈥渘ot support Firefox鈥 mean for your app in practice? Do you mean:

  • 鈥渨e don鈥檛 sweat it that FF users can鈥檛 install鈥
  • 鈥渂ecause FF doesn鈥檛 have this feature, we officially don鈥檛 consider FF supported, but the app might work there anyway鈥
  • 鈥渨e prompt users to use a different browser (but they can dismiss the prompt)鈥
  • 鈥渨e outright block FF usage鈥
  • something else

Again, just curious 鈥 I haven鈥檛 heard of doing anything but the first before. Hopefully OP will forgive a bit of topic drift 鈥 it鈥檚 good to learn more about how people are really responding to the state of things I think.

FF usage seems to be getting so low now that all of this might be theoretical in another year or two anyway, for better or worse ... :(

@Pauldb8
Copy link

Pauldb8 commented May 16, 2021

Incredibly, they are not even providing an alternative, that would prove that they at least cared. Does not seem like, so please: implement it (major support), propose an alternative, or just die already Firerox. If Firefox does not support open web, I'm uninstalling it. Tell me what should I do ? I would go to Ungoogled Chromium and I would also start recommending it to my users as well, hope we don't get there.
Same could go for Safari Explorer (the new IE...)

@briantbutton
Copy link

@bathos, "the middle one". We just notify them this won't do what they need and suggest a working alternative depending on their OS, but take no other steps. It happens as they open the App, as I recall. Even though we use Firefox in some of our S/W test, we don't want users to get started with it if they cannot get the advantage of an "installable WebApp".

I have no rancor on this any more. We have one browser solution for each OS (two for Windows). That is enough. Barely.

My personal opinion, as summarized in my post of January 19 2020 (above), still stands. Won't repeat it here.

@marcoscaceres
Copy link
Member Author

marcoscaceres commented May 18, 2021

@Pauldb8, I understand you are frustrated, and we welcome your participation - but I kindly remind you of our code of conduct ... inflammatory statements like "Firefox does not support open web" and "Safari Explorer (the new IE...)" are inappropriate.

Regarding "beforeinstallprompt", as shown by various browsers, the ability to install a web application is not gated on an install prompt. A user can simply "add to homescreen" any web page they choose - so even if all browsers supported the BIP event, one might still need to handle a situation where BIP is cancelled, and then the user manually chooses to install a web application without BIP (i.e., progressive enhancement to Safari)... Similarly, a user may choose not to install the application at all (progressive enhancement to Firefox).

@briantbutton
Copy link

@marcoscaceres, if what you are saying is that browsers will handle PWAs as they see fit, I agree. I don't consider that a good outcome.

For example, on IOS there is an incantation (several incantations, depending on your precise arrangement) but only if your browser is Safari. Each other OS has a very specific, and different, set of options. We must maneuver through these, guiding our users as best we can.

"Installation" is more than just a matter of putting a button on your desktop. Both Chrome and Safari respect the Manifest differently on an "installed Web App" versus a regular web page. The uninstalled version tends to overflow the screen because of a bunch of browser control buttons and orientation (critical to our App) is uncontrolled. On a phone, with its tiny real estate, the difference in user experience is huge.

@marcoscaceres
Copy link
Member Author

The uninstalled version tends to overflow the screen because of a bunch of browser control buttons and orientation (critical to our App) is uncontrolled. On a phone, with its tiny real estate, the difference in user experience is huge.

Understood, but that seems unrelated to "installation". If I'm reading what you are saying correctly, this appears to the an issues with detecting the display mode or if a set of UI controls are available (which coincidently are affected by the application being installed and the manifest being applied.)

Put differently, "applying a manifest" (having the manifest affect the behavior or presentation) is not inherently tied to installation or "add to home screen". This is also why I'm confused about how all this relates to "beforeinstallprompt", which is yet something totally unrelated.

I think solving for the problem you describe:

"overflow the screen because of a bunch of browser control buttons and orientation (critical to our App) is uncontrolled"

Is certainly something we should address - but we should tackle this as unrelated to this whole "installation" thing.

@Jaifroid
Copy link

I realize W3C has rules on the number of browsers required for a feature to be standardized, and that's fine, but from what I can tell we have: Chrome, Edge, Opera, the mobile versions of these and Samsung Internet all implementing these install events. It seems to leave a minority of Firefox and Safari not having implemented.

Safari, I understand (even if I don't like it) because PWAs undermine Apple's investment in its App Store. I have to say I find the Firefox stance on these install events and on PWAs more broadly to be self-defeating. It could so easily have been at the forefront of these developments which promote an open, non-commercial model for Web applications. I don't really know what Mozilla stands for any more... Tant pis.

@madmoizo
Copy link

madmoizo commented May 31, 2021

@Jaifroid All chromium-based browsers = 1.

The recent activity here led me to think about this

leave it to browsers to provide better UI to surface installability of web applications

The questions I ask:

  • Should a standard rely on something unreliable (browser's UI) for feature discovery?
  • Should a standard conform to vendors interests or commons interests?
  • Is it possible to conform to commons interests if vendors write the standard?

@Jaifroid
Copy link

@frlinw This raises the broader issue of how W3C can decide sensibly on specifications in a market overwhelmingly populated by Chromium-based browsers (which is not a return to the old domination by Internet Explorer, because the Chromium-based browsers are all forking off their own implementations and doing something slighlty different). Something is awry when I look around and see a diversity of independent browser implementations but they are all counted as a single browser. How much does a codebase have to be forked for it to become a separate browser? I'm sure W3C has thought carefully about these things, but current policy does seem to be leading to counterintuitive decisions.

(FWIW, Personally I don't think the mobile versions should be counted as the same version. They often implement things differently, only complete part of a specification, or else add specific features that are different from the parent browser.)

This is quite related to the quesitons you ask, I think. There is a balance to be struck between vendor implementations and an overseeing body that can set aspirations for a common standard (or a standard for the good of all / the commons).

@marcoscaceres
Copy link
Member Author

Should a standard rely on something unreliable (browser's UI) for feature discovery?

I don't know what this means, or who judges "unreliable"? However, the aim is for discoverability to be as good as implementers make it, and it's something browser vendors compete on.

Should a standard conform to vendors interests or commons interests?

We try to strike a balance. However, the balance is always tipped towards implementers - because if we put stuff into the spec that only one implementer supports, then the W3C Process forces us to remove the feature. Case in point: "beforeinstallprompt".

Is it possible to conform to commons interests if vendors write the standard?

That's another good question. We have a few checks and balances in place, including the W3C's need for "wide review". The working group Chair is supposed to operate from a vendor neutral perspective (I'm the Chair, I work for the W3C... though I used to work for Mozilla). I also edit the spec, and don't represent the vendor. Similarly, the other editors are a mix of folks, but we all contribute to different engines.

Further, we have a (newish) PULL_REQUEST_TEMPLATE that forces us to check that there is consensus (and no objections!) amongst all implementers before we put stuff into the standard.

How much does a codebase have to be forked for it to become a separate browser? I'm sure W3C has thought carefully about these things, but current policy does seem to be leading to counterintuitive decisions.

We don't consider "chromiums" as independent implementations: we consider WebKit, Chromium, and Gecko as separate implementations.... I should really update PULL_REQUEST_TEMPLATE to make this more clear.

@Jaifroid
Copy link

Jaifroid commented Jun 1, 2021

We don't consider "chromiums" as independent implementations: we consider WebKit, Chromium, and Gecko as separate implementations.... I should really update PULL_REQUEST_TEMPLATE to make this more clear.

I understand that, but the market has become distorted with so many different Blink implementations that it seems some other way of working out at what point a previously approved standard gets dropped is needed. Is it really enough that one engine-developer decides it doesn't have the resources to complete an implementation, or that it's not a priority, and pulls it (especially when we know the other competitor will never implement the spec due to commercial interest)? I understand that this is difficult and that the browser landscape is shifting, but it seems to me that dropping a standard should have a higher bar than that, or else you indeed risk one vendor dominating the landscape with proprietary but widely used features. The genuine consternation caused by the decision behind this PR ought to be food for thought IMHO.

@marcoscaceres
Copy link
Member Author

I understand that, but the market has become distorted with so many different Blink implementations that it seems some other way of working out at what point a previously approved standard gets dropped is needed.

Yes. Those discussions are happening at every level of the W3C: from the Advisory Board, to all over the community. Unfortunately, I can't find a link to the repo where that discussion is happening... I'll drop a link if I find it!

Is it really enough that one engine-developer decides it doesn't have the resources to complete an implementation, or that it's not a priority, and pulls it (especially when we know the other competitor will never implement the spec due to commercial interest)?

Today, yes. It gives us a base set of interoperability.

I understand that this is difficult and that the browser landscape is shifting, but it seems to me that dropping a standard should have a higher bar than that, or else you indeed risk one vendor dominating the landscape with proprietary but widely used features.

We can't really stop any vendor from shipping proprietary things. They all do it. Not just one vendor, but every browser vendor are equally as guilty... just some do it more than others, and not for nefarious reasons. Often time, the proprietary things get picked up by other browser vendors: for example, the proprietary Web Share API and the new Contacts API from Google got implemented by Apple, so they got moved or are getting moved to the W3C Standards track. But similarly, <meta vieport> was an Apple thing, and so was theme-color, if I recall correctly... ApplePayJS paved the way for the W3C Payment Request API, but ApplePayJS still ships in Safari.

The point is that sometimes some ideas won't stick. That's ok... Google is not about to yank "beforeinstallprompt", but neither should we expect other browsers to support how Chrome does installation if they don't want, or need, to.

The genuine consternation caused by the decision behind this PR ought to be food for thought IMHO.

Believe me. This, or any other decision as to what goes into this this spec, wasn't taken lightly. I get a little nauseous thinking about the number of emails, bugs, and meetings (physical and virtual), we've had about this feature across various organizations over the last 5 years or so.

@msimic
Copy link

msimic commented Sep 1, 2022

I've read this whole thread. It is a hell lot of reading.
If there is one thing I've understood, it's that the way something is paved for a standard is wrong.

Taking and/or keeping in a standard a feature that is supported by a wide range of browsers is wrong.
Wide adoption should have absolutely no impact on what goes into a standard.

A widely implemented feature does not mean that the feature is good for future the web, it just means it is good for most of the companies developing browsers.

A feature that could be good for the future of the web could also nefariously be not implemented on purpose by one browser, since there are currently three browser engines in total (WebKit, Chromium, Gecko.
A minority (or majority) could be blocking features that can be useful.

Democracy does not work when you have three voters, especially three voters of which one is actually a handful (browsers based on Chromium). The current situation is really bad. Mozilla and Apple are basically overruling Microsoft and Opera. The latter two have no say in what goes or doesn't go into the standard because they are using an engine developed by Google. That's completely silly - Microsoft and Opera can easily remove the event in question in their implementation if they did not like it.

The W3C needs to have their own stance about a feature. Is the feature good for the web or not? If yes have it in the standard, if not remove it.
Anybody who has affiliation with one of the companies developing the engines should not have a word in this.

Somebody from the W3C can look at some browser, see something they like. If the W3C agrees, mandate that all other browsers implement it by making it a standard. The problem is that the W3C has too many people affiliated with the browser developers and for this reason cannot agree themselves - and that means that a feature is rejected even if it could be good. If there are people affiliated with some browser developer they should be voting personally and not keep the stance of the organization, although preferably have no word in it at all.

The W3C needs to be more powerful than the browser developers.
One implementation regarded as good by the consortium should be enough.
Browsers can be sources of ideas for the standard, without having the power of veto (and that's what is basically happening here - Apple vetoing because they want the AppStore and Mozilla most likely because they can't get their sh*t together).

Not saying that BIP is good or bad, just the way it is being treated is wrong.

@mgiuca
Copy link
Collaborator

mgiuca commented Sep 1, 2022

@msimic Mostly agree (disclosure: I work for Google, one of the big browser developers you say should have less power :))

Democracy does not work when you have three voters

I agree. It's hard to get useful things done when it only takes 2 "votes" to oppose. An important point though about the intention of this system: this is not technically a democracy. Features don't get accepted or rejected based on the majority vote. Rather, features get accepted if there are at least 2 implementations. (e.g. if there were 100 browser vendors, we wouldn't need 51 implementations to get it into the standard, we would just need 2).

The reason for this rule is sound: it keeps features from becoming standards that are too locked to one specific vendor, or too tied to the details of one engine. Once you have two implementations, you can figure out what are the core concepts that need to be standardized and what can be implementation-specific. With just one, the standard would just be writing down what one browser does. That's also why all the Chromium-based browsers count as one "vote" -- because they only prove a single implementation.

(Whether this rule is right or wrong, I am not offering an opinion, just explaining why it is this way.)

The problem is that that idea was made when there were 4 or 5 engines actively being developed. Now there are just 3, the "rule of two" has turned into a very weak democracy, as you say, with three voters, and any two voters can veto a standard.

On the other hand, the fact that this feature isn't written down in the W3C standard doesn't mean it is going away (as Marcos said). It just means we wrote it down somewhere else, and it works in Chromium-based browsers. Even if it were in the standard, that wouldn't force Apple and Mozilla to implement it. So from the user/developer standpoint, the result is the same. That brings me to the next misconception:

Somebody from the W3C can look at some browser, see something they like. If the W3C agrees, mandate that all other browsers implement it by making it a standard.

The W3C does not mandate that browsers implement anything. They simply recommend (that's why W3C standards are called "Recommendations"). When someone writes a web browser (anyone technically can, that's why all the documents are public), they do not have to sign a contract that says you implement everything in the spec. They just voluntarily implement the W3C recs for the sake of compatibility with other browsers. That means if you're a browser vendor, it's generally a good idea to implement everything you can (otherwise you risk falling behind), but if feel strongly about anything, you don't have to implement it.

By necessity, browser vendors have the power to decide what goes into the browser, just as anybody who builds anything has the power to decide what features they have. Consumers have the power to choose which product they use based on what features it has.

That's my standpoint (as the guy who wrote a lot of this standard and argued for its inclusion): I disagree with the decision to remove it, but I understand the reason for this process and ultimately which document it's written in won't affect which browsers support it, which means it doesn't change things for users or developers.

@msimic
Copy link

msimic commented Sep 1, 2022

The W3C does not mandate that browsers implement anything. They simply recommend (that's why W3C standards are called "Recommendations"). When someone writes a web browser (anyone technically can, that's why all the documents are public), they do not have to sign a contract that says you implement everything in the spec. They just voluntarily implement the W3C recs for the sake of compatibility with other browsers. That means if you're a browser vendor, it's generally a good idea to implement everything you can (otherwise you risk falling behind), but if feel strongly about anything, you don't have to implement it.

Perhaps the word "mandate" I used is not the right one. But if you don't follow the standard you are asking for trouble, so it becomes indirectly a "mandation".
I for example can make a card that slots into a computer PCI express bus even though I'm not adhering to the standard.
It could work or it could not. But when it does not work it will be my problem. The person that will experience the problem will complain to me. So I'm better of adhering to it.
Here if we compare how this topic is addressed, instead "I and some others" are complaining to the PCI consortium to remove a feature I did not implement in my card in order to make it fit my needs.
And if I chose to outsource my card manufacturing to another company (like Microsoft and Opera for the engine) I am not able to participate in discussions about what should go into the standard.
It is mind boggling.

@fabricedesre
Copy link

That's my standpoint (as the guy who wrote a lot of this standard and argued for its inclusion): I disagree with the decision to remove it, but I understand the reason for this process and ultimately which document it's written in won't affect which browsers support it, which means it doesn't change things for users or developers.

So you're saying all these discussions and standards are kind of useless, because in the end browsers do what they want? :)

@msimic
Copy link

msimic commented Sep 1, 2022

That's my standpoint (as the guy who wrote a lot of this standard and argued for its inclusion): I disagree with the decision to remove it, but I understand the reason for this process and ultimately which document it's written in won't affect which browsers support it, which means it doesn't change things for users or developers.

So you're saying all these discussions and standards are kind of useless, because in the end browsers do what they want? :)

Let them do what they want. That's not the issue here. It is only about how standards are being created.
They are being created to fit the browser vendors (and even that not in a fair way), and not to fit the users.
If the standards are good, users will gravitate to the vendors that are adhering to it.
Internet explorer being dead is a confirmation of that.

@mgiuca
Copy link
Collaborator

mgiuca commented Sep 1, 2022

@msimic I don't know much about hardware standards. Some standards you need to license and a condition of the license is that you follow them precisely -- W3C standards don't work that way since they are public standards.

If the PCI standard needs to be licensed, then it's a different situation since card manufacturers need to comply in order to keep their license. If not, then it's basically the same here: you could make a non-compliant card but then it wouldn't work as expected and customers would complain.

That's basically how web standards work: you could make a browser that doesn't support <b> but then pages would look funny in your browser and users would complain and switch browsers. The more fringe APIs, like this one, the less important that becomes, and at some point, it's fine for browsers to pick and choose which APIs they support, especially if they don't impact the core experience of the site.

Then it just becomes about whether it's worth having in the standards document. Arguably, if only one engine supports an API, there's no point having it in the document, because there's nothing for it to be compatible with. But if another vendor does want to support it in the future, well we've written it down, they can implement that, and then we would make a case that it can go into the standard now.

So you're saying all these discussions and standards are kind of useless, because in the end browsers do what they want? :)

In some sense, yes. If two or more engines are trying to implement something, then the standards discussions are highly relevant, because we need to agree on how it works. If only one engine is implementing, it doesn't really matter where we write it down, it's a tree falling in the forest :)

@msimic
Copy link

msimic commented Sep 1, 2022

@msimic I don't know much about hardware standards. Some standards you need to license and a condition of the license is that you follow them precisely -- W3C standards don't work that way since they are public standards.

You don't have to license any standard, hardware of software.
You have to do it if you want to have a certification/badge to show off, or if such is required by the implementations.
If you want to manufacture a product that slots into something that is standardized, and you are not breaking any laws while doing it you are free to do it.
An example of breaking laws is: patents, or not paying royalties if an implementation requires it. Like for example HDMI or DolbyVision. But this does not apply here. Or not following safety regulations that affect the implementation (like producing an electrical component that is a fire hazard) which is again not an issue here.

For example if BIP was part of the standard then Firefox and Safari would not get a W3C certification, but would still be able to follow parts of the standard and develop without any issue, except for those that their users would file because they are not following it 100%.

And regarding certification: for how things are done here that would never work for the case of Chromium.
It is being treated for standards sake that all browsers based on it are the same.
So if BIP was part of the standard and Chromium implemented BIP then Edge would get a certification.
But Edge is free to override anything that is implemented in Chromium (window.onbeforeinstallprompt = () => {};).
Would an Edge with disabled BIP be certified because Chromium is?

@marcoscaceres
Copy link
Member Author

Can I please respectfully ask we keep this on topic (BIP)? 馃檹 I'm worried we will spin off into the nuances of standardization and add more walls of text to what's already a very lengthy topic.

As @mgiuca eluded to, the fact that it's not in the main spec doesn't mean that it's not specified. As @mgiuca said, that it doesn't have an independent implementation means (today) that it's not in the spec. If tomorrow some other engine decides "oh! we need that!", then we would just revert this change.

@msimic, please understand that a lot of thought went into both the creation (and ultimate removal) of this feature. I was also involved in helping specify it and still believe it has merit. However, the rules of both the W3C Process and those working group membership agrees by signing up based on our Charter justify its removal. To quote:

In order to advance to Candidate Recommendation and to add features after reaching Candidate Recommendation, each feature is expected to be supported by at least two implementations, which may be judged by factors including existing implementations, expressions of interest, and lack of opposition.

Despite the Editors' best efforts (which includes me), we were not able to overcome the strong opposition and convince implemented this feature is critical. And as @mgiuca said, even if we had it in the spec, there are well articulated reasons why BIP is not a good fit (and doesn't make any sense) for certain user agents.

BIP is inherently tied to a particular install flow (showing a banner or modal prompt), and not all browsers have that UI flow.

@msimic
Copy link

msimic commented Sep 1, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking Use for changes that break existing normative behavior
Projects
None yet