[dmitriid]

> Very few people are using Chrome-only APIs which are not in the standards yet. So it's not really a concern.

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

Also, "not many people using something" is not as great an argument as you think it is. See, for example, the latest problem with browsers deciding to remove alert/prompt/confirm: https://dev.to/richharris/stay-alert-d

> The web is in business (and thriving) as an application platform because it's being pushed forward relentlessly.

A quote from the same article: "An ad company shouldn't have this much influence over something that belongs to all of us".

So somehow non-standards that Chrome pushes (many of which will never get a different implementation because both Safari and Mozilla consider them harmful) are good, and push the web forward. But SQlite is bad because there are no independent competing implementations.

Got it.

[scns]

From the first comment below the article:

> The Safari team did quite a lot of work re-styling their alerts and dialogs to be within the context of the webpage, yet phishing and scams that utilize this still run rampant on iOS. Repeated alerts are used to lock up the browser and make it unusable, forcing non-technical users to call a scam telephone number because they think their device was hacked.

A few bad actors ruining it even for totally different usecases.

[dmitriid]

> A few bad actors ruining it even for totally different usecases.

Same thing happened to Do Not Track... that was used for fingerprinting

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