[jeswin]

> Ah yes. But SQlite not having competing independent implementations somehow is?

Except that's not why it was culled. The reasons are discussed in great detail on this thread and elsewhere.

> non-standards that Chrome pushes (many of which will never get a different implementation because both Safari and Mozilla consider them harmful) are good

I'm saying nobody uses those Chrome only APIs, until they become standards (which requires acceptance by other vendors). Or are you against experimentation?

[dmitriid]

> I'm saying nobody uses those Chrome only APIs, until they become standards

Ah yes. Once Chrome releases something in stable, literally no one ever uses those APIs, no one. And even Google's propaganda machine doesn't tell you to use them (example: https://web.dev/usb/)

> Or are you against experimentation?

I'm not. What Google does isn't experimentation.

[jeswin]

My assumption is that a very small percentage of developers participate in it. Feel free to prove me wrong if you have any numbers.

> I'm not. What Google does isn't experimentation.

So the way this is done now (with origin trials to collect feedback from developers) is not good enough? What exactly is your definition of experimentation?

[dmitriid]

> My assumption is that a very small percentage of developers participate in it.

It doesn't really matter how many. It means that people are already using this functionality, and depend on it. I didn't link to an article on removing alert just for the fun of it.

> So the way this is done now (with origin trials to collect feedback from developers) is not good enough? What exactly is your definition of experimentation?

Running this as origin trial is a very good way of doing it. What's not a good way is:

- having an unrealistic timeline.

Example: Mozilla was asked for position on WebHID three months before Chrome released in stable. The "standard" was so badly written that Mozilla engineers couldn't understand it. Chrome still released it, and updated the "standard" two months after it was already in the wild.

- ignoring any and all objections, and favoring own needs only

Example: Constructible Stylesheets. The spec has a trivially reproducible problem. Several developers (not only from Mozilla and Safari) pointed this out, and proposed several changes to the spec that would get rid of the problem. However, Google's own lit-html was interested in the spec. So they released it in stable, said that "0.8% of pageviews now use this" (reality: only lit-html used it at the time), and refused to hide it back under a flag. Safari simply said they are not going to implement the spec in this shape.

- completely ignoring the realities and needs of the web

See https://dev.to/richharris/stay-alert-d and my comment here: https://dev.to/dmitriid/comment/1h5bh

- presenting these "standards" as fait accompli even if other browser vendors will never ever implement them

They have co-opted web.dev as a propaganda machine. The site presents itself as a neutral resource for web develoeprs. It's not, it's a Chrome-only vehicle. They present various specs as already available and never specify issues with those specs. For example, WebUSB: https://web.dev/usb/

See, e.g., Mozilla's position on various specs. Scroll down to "harmful": https://mozilla.github.io/standards-positions/ I'll let you guess how many of those have already been shipped in Chrome. Then you can find what web.dev says about it

- gaslighting other browser vendors

I won't link to specific tweets because I don't need to be angry. But almost every single of Google's high visibility "standards people" and "developer advocates" and "community managers" will always, and I mean absolutely always paint all other browsers in as negative light as possible (as lagging behind, as hurting the web, as damaging the web, as being a detriment to the web etc.)