And Chrome is not interested.
And yet, when they release a standard all other browsers object to, they justify that... because it's used by 0.8% page loads (exclusively on Google properties, implemented exclusively by Google devs) [1]
And yet, when other browsers consider standards harmful, [2] Chrome just ships them [3]
[1] https://twitter.com/justboriss/status/1220428902071447552
But sure, try to weaponize anything related to web components at every opportunity.
The only thing that was said there: "we released this API into the world against multiple objections by multiple parties. This feature is used exclusively by our own developers and almost exclusively on our own properties. It's used on a whopping 0.8% pageviews (once again, almost exclusively on our properties). So now we will not remove it".
> But sure, try to weaponize anything related to web components at every opportunity.
No. That was a very recent example, and that example had a number of pageviews in it, so it serves as an interesting comparison of approaches.
0.8% pageviews by Google's own devs for a standard Google rammed through despite objections? Oh, it's good, ain't gonna remove it. 1-2% pageviews by people outside Google for a standard Google had no say in? Oh, not gonna do anything about it.
And if you paid a grain of attention, I also have this to say about Google's hypocrisy (with links to Mozilla's stance on standards and to Chromes feature list page):
--- quote ---
when other browsers consider standards harmful, Chrome just ships them
--- end quote ---
Which is a fact of life regardless of my feelings towards particular standards.
I can add another link, of course: Web API counts across browsers [1] It's so nice to see Chrome shipping in total over 1000 more APIs than competition, of them many considered harmful, and including over 600 browser-specific APIs. Because it's all for the greater good.
If the feature is changed, change the name so existing sites don't break. You're extrapolating far too much from that, as did Rich Harris and other persistent web component haters.
There is no backwards compatibility for a feature that was released just a few days ago and that had been behind a flag prior to the release.
> If the feature is changed, change the name so existing sites don't break. You're extrapolating far too much from that
There's nothing to extrapolate. These are facts.
----
Also, note: "Rich Harris and other persistent web component haters". This is the continuous incessant vitriol that spews out of Google. Coupled with Chrome playing increasingly dirty, no wonder people feel resentment towards Google and its representatives.
I like XML, XHTML, XPath, XSLT. But I don't understand your argument. Maybe it would look better with a list of harmful Chrome only APIs standardized by WHATWG. Even then it is not a reason to follow bad example.
You'll see most of them already released publicly. And people like @spankalee will call you a hater when you start calling Google out. And then clueless web devs will complain how "Safari is holding the web back" even though Safari and Mozilla can barely hold back the floodgates of poorly specified standards that are being pushed through at neck-breaking speed.
https://wicg.github.io/webusb/
https://webbluetoothcg.github.io/web-bluetooth/
https://www.w3.org/2012/nfc/web-api/
https://www.w3.org/TR/html-imports/ # that one scrapped
That is not WHATWG.
WebReflection shows a great example of civilized discourse [1]. If excuse not to extend feature is low usage we'd better provide competing arguments how it is useful. If problem is usability we should address it first [2].
[1] https://github.com/whatwg/dom/issues/903#issuecomment-707828...