You continue to grind your axe, but they only thing I was saying there was that backwards should be considered when potentially changing an API because the feature is used in the wild.
But sure, try to weaponize anything related to web components at every opportunity.
> they only thing I was saying there was that backwards should be considered when potentially changing an API
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.
Thank you for web-confluence, I've got similar question this May, researched with BrowserStack too [1].
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.
The web is not just WHATWG. Chrome rams multiple standards through several standards bodies. Scroll down in Mozilla's standards positions [1]. Then search for the harmful standards in Chrome features: [2]
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.
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].
I'm not in a position to remove or not remove an API - I just use it, and the only thing I'm saying there is to _consider_ backwards compatibility.
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.
> I'm not in a position to remove or not remove an API - I just use it, and the only thing I'm saying there is to _consider_ backwards compatibility.
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.
But sure, try to weaponize anything related to web components at every opportunity.