[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.

[dmitriid]

> Say something connected to reality.

Easy. I even gave links to show how modern web "standards" work. To quote myself: "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?"

All this with response to literally what has been happening for the past several years: Chrome ships its own non-standards (even if it spits out a spec doesn't make it a standard), developers start using them, due to Chrome dominance its now a de facto standard.

To think otherwise is to be completely oblivious to what's happening in web standards.

Edit. As to "then someone writes a standard". This also happens. See Web HID timeline: https://github.com/mozilla/standards-positions/issues/459#is... Same happened to WebRTC, by the way. Stable spec version was finally complete in 2018, 7 years after Chrome spat it out and called it a standard. And so on and so on.

[pwdisswordfish9]

None of that matters. What matters is whether the standardization process "is" the process described in this comment: https://news.ycombinator.com/item?id=33989349

And the answer is, "no, that's not the standardization process", and furthermore, "that comment was hyperbole". If you can't admit this, then you are disconnected from reality.

None of your words or links will make the original comment true.