Remove beforeinstallprompt and appinstalled events. #836
Conversation
marcoscaceres
added
the
breaking
|
It would be good to let @mgiuca weigh in as well as the Edge folks before this lands. |
|
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:
|
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! |
|
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.) |
|
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. |
|
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. |
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. |
|
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. |
|
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’s 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. |
|
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.
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). |
|
See the following links I’ve provided in the other issue: Also please refer to my earlier comment about different ports of WebKit. |
|
See also the removal of features marked “at 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’ve considered the API implementable for a while. |
FWIW, I don’t 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’d usually do. |
|
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. |
|
@rniwa wrote:
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.
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. |
|
@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. |
|
Catching up…
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’s (potentially) useful, but I’m not sure it needs to be explicitly part of this spec. That said, I don’t 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’t 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’ll 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’s another conversation for another day (and probably needs to happen in another venue). |
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 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 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 |
|
"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. 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. |
|
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? |
|
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. |
|
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. |
|
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 ( 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)
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. |
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.
|
So that is it ? |
|
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 |
|
@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. |
|
@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. |
|
We also publish an installable PWA. In Firefox it’s not installable, of course, and we document in our FAQ that the application isn’t installable from all browsers, but to date I’ve 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’t 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 “the gap” is reversed — PWAs have a fantastic capability in this regard that native apps lack.) So your comment made me curious @briantbutton: what does “not support Firefox” mean for your app in practice? Do you mean:
Again, just curious — I haven’t heard of doing anything but the first before. Hopefully OP will forgive a bit of topic drift — it’s 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 ... :( |
|
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. |
|
@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. |
|
@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). |
|
@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. |
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:
Is certainly something we should address - but we should tackle this as unrelated to this whole "installation" thing. |
|
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. |
|
@Jaifroid All chromium-based browsers = 1. The recent activity here led me to think about this
The questions I ask:
|
|
@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). |
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.
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".
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.
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. |
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!
Today, yes. It gives us a base set of interoperability.
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, 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.
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. |
|
I've read this whole thread. It is a hell lot of reading. Taking and/or keeping in a standard a feature that is supported by a wide range of browsers is wrong. 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. 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. 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. Not saying that BIP is good or bad, just the way it is being treated is wrong. |
|
@msimic Mostly agree (disclosure: I work for Google, one of the big browser developers you say should have less power :))
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:
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. |
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". |
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. |
|
@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 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.
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 :) |
You don't have to license any standard, hardware of software. 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. |
|
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:
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. |
|
BIP is inherently tied to a particular install flow (showing a banner or
modal prompt), and not all browsers have that UI flow.
This is not true, every browser has HTML which does this.
And there are repercussions to excluding it because it prevents web sites
that host their own PWAs inside their own dialogs from installing their
PWAs, since browsers use the manifest if present from the url where the
site is hosted itself and not from sub-url. That makes it so you can only
install the website itself and not a useful standalone module of it.
…On Thu, Sep 1, 2022 at 8:42 AM Marcos Cáceres ***@***.***> wrote:
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 <https://github.com/mgiuca> eluded to, the fact that it's not
in the main spec doesn't mean that it's not specified. As @mgiuca
<https://github.com/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 <https://github.com/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
<https://www.w3.org/2022/04/webapps-wg-charter.html> justify its removal.
To quote:
In order to advance to Candidate Recommendation
<https://www.w3.org/Consortium/Process/#RecsCR> 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 <https://github.com/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.
—
Reply to this email directly, view it on GitHub
<#836 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABHCCP5Q2CENKDWCDM5J7DV4BF5FANCNFSM4J2IVW4A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Closes #835
Closes #843
Closes #692
These should be relocated:
Closes #627
Closes #578
Closes #691
This change (choose one):
Implementation commitment (delete if not making normative changes):
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.appinstalledevent 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
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.