Re: [w3c/manifest] Remove beforeinstallprompt and appinstalled events. (#836)

@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](https://wicg.github.io/manifest-incubations/index.html#installation-events), 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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/836#issuecomment-1233652619
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/836/c1233652619@github.com>