[pwdisswordfish0]

This is not really true. Chrome's extensions to the Web platform comprising its Page Lifecycle APIs are coherent, well-reasoned, and valuable/inoffensive, yet other browsers have not implemented them (yet; but the proposed APIs are old enough now that if what you're saying were true it'd already be a done deal).

[dmitriid]

> This is not really true.

This is 100% true.

The latest example is WebTransport. Which isn't even on the standards track. Yet Chrome already released it, and calls it "an emergent standard".

And this goes for multiple other Chrome-only non-standards.

Good thing you found an API that you decided was reasonable. Doesn't make it a standard, or that there's a consensus, or that other browsers agree with your assessment. Age of the proposal doesn't factor into it.

[pwdisswordfish0]

Sorry, try again. That's not how proof-by-contradiction works.

> This is 100% true.

It literally is not, unless you think 100% means "less than 100%".

[dmitriid]

The way Chrome works especially in the past many years is 100% correctly described by the comment you were replying to: https://news.ycombinator.com/item?id=33989349

You "counterpoint" isn't even a counterpoint, but just reinforces the original comment.

It literally says in the actual document about Page Lifecycle API: "It is not a W3C Standard nor is it on the W3C Standards Track." https://wicg.github.io/page-lifecycle/spec.html

Literally not a standard shipped in Chrome, literally is something Chrome came up with and implemented on its own, literally only shipped in Chrome without any consensus or input from other browser implementers...

And yet "no, this isn't true, this isn't how Chrome works at all".

Is this true for 100% of things that Chrome is shipping? No. But it's so asymptotically close that the difference doesn't matter. They ship 40 to 70 new web APIs in each version. That is, 40 to 70 new Web APIs every month. Over 500 new APIs a year. How many do you imagine they even pretend to be a standard? https://web-confluence.appspot.com/#!/confluence

[pwdisswordfish0]

> You "counterpoint" isn't even a counterpoint, but just reinforces the original comment.

This sleight of hand is not going to work.

> Literally not a standard shipped in Chrome, literally is something Chrome came up with and implemented on its own, literally only shipped in Chrome without any consensus or input from other browser implementers

... and literally hasn't gotten "someone to type up something that describes the Chromium implementation into the standard". Your choice to ignore this does not bode well for whether you should be taken seriously on matters of intellectual honesty.

The fact that other browser vendors have not been forced to implement it by now contradicts what you are arguing to be true.

All of the Chrome-proprietary APIs that shipped once upon a time in Chrome but were later removed from Chrome (incl. no remaining signs in subsequent draft standards) also contradicts it.

Does Chrome ship non-standard stuff? Yes. So has Gecko. Webkit, too. Has Mozilla in particular been forced to implement some things for no reason other than it because became unavoidable at some point after it started shipping in Chrome? Yes. Does the standardization process merely consist of Chrome doing whatever it wants and the eventual result is a new standard (with nobody else being able to influence this or contribute anything of their own)? No.

> And yet "no, this isn't true, this isn't how Chrome works at all".

Nice strawman. The moment where you resort to putting words in someone else's mouth is the moment you forfeit. Goodbye.

[dmitriid]

> This sleight of hand is not going to work.

It's not a sleight of hand. It's a fact.

> and literally hasn't gotten "someone to type up something that describes the Chromium implementation into the standard".

And literally exists as a spec that I even linked. Which gives Chrome and gullible devs the license to say things like "oh look at this beautiful reasonable standard that other browsers have not implemented"

> All of the Chrome-proprietary APIs that shipped once upon a time in Chrome but were later removed from Chrome

Of course they haven't. By default everything that Google ships and is not a standard is Chrome-only.

So let's look at your example, Page Lifecycle API.

- Is it a standard? No.

- Is it even on a standards track? No

- Is it shipped only in Chrome? Yes.

- Has Chrome dropped it? No.

- Does this make it a Chrome-only non-standard? Yes.

- Does Chrome drop this and hundreds of other such APIs? Of course not.

Thankfully, we can check that from two sources:

- Chrome's own Web APIs dashboard. https://web-confluence.appspot.com/#!/confluence If you click "Browser Specific", you will see that Chrome ships over a thousand Chrome-specific APIs, and that number grows rapidly.

And this is, undoubtedly on top of APIs that they pretend are standard. This is where the second source comes in

- MDN Web APIs list https://developer.mozilla.org/en-US/docs/Web/API

This one lists both actual existing APIs and "experimental APIs". Those experimental APIs? Most of them are "not a standard, not on a standard track" but are shipped in Chrome. I checked the letter B on that page. There are 4 experimental APIs. All of them are "not a standard, not on a standard track". All of them are shipped in Chrome.

> The moment where you resort to putting words in someone else's mouth is the moment you forfeit.

Which I of course didn't. I did paraphrase it for dramatic effect, but "this is not really true" and "all chrome-only proprietary APIs were dropped" amount to the same thing.

> Goodbye

Adieu

[pwdisswordfish0]

> Of course they haven't.

Of course they haven't what?

> "this is not really true" and "all chrome-only proprietary APIs were dropped"

First of all, that's insane, but secondly, no one is even claiming the latter. It's easy to make up things all day. Say something connected to reality.