Given Chrome's status as the new IE6 in terms of market share and outsized influence over the technological direction of the web, there's a real risk of moves like this being unilateral.
On the other hand, the last two comments re: libxml being their primary concern do give some hope.
Agreed. I find it rather alarming that an influential member of the Chrome team is talking like this. All our e2e test suites are built around Chrome and XPath because of its expanded abilities over CSS
I really don't understand this opinion. Like, I mean, I get the frustration from the perspective of a web developer that wants to use a particular feature but are different browsers not allowed to be different?
Like if Firefox didn't want to implement WebUSB, Safari didn't want to implement WebPush, or Lynx didn't want to implement Canvas is that outrageous?
> are different browsers not allowed to be different?
The web (and open standardisation in general) has pioneered an ecosystem where the primary differentiation between browser is in user-facing UX & features (and ancillary factors such as performance, etc.), rather than developer-facing web-tech support.
This is quite different to a lot of other commercial "competitive" spaces as it substitutes vendor lock-in on patents & trade-secrets for actual innovation in the user-facing space. It's not all rosy: competing browsers still stray from this on the regular, but the ideal is one of the primary selling points of the web as a platform.
Browsers differentiating themselves on user features while maintaining cross-competitor consistency on web standards is the dream that differentiates the web, so seeing its erosion is something to call out.
> Like if Firefox didn't want to implement WebUSB, Safari didn't want to implement WebPush, or Lynx didn't want to implement Canvas is that outrageous?
What's particularly different here is that this isn't about the addition of a feature. The ticket opened is about adding XPath2 support but the quoted line is about removing existing XML support.
This may sound a bit like I'm supporting Microsoft's old "don't break the web" adage, but the big difference here is MS was reluctant to remove features competitors didn't have for fear of breaking IE-only websites (that had relied on them due to IE's dominance). This is about Chrome removing standardised features that browsers, servers, and applications of all varieties have supported interoperably for decades.
I believe it is about rewriting implementation, not removing API [0].
> Deprecate, and consider removing, XSLT
> The consensus last time we considered this was that xml and xslt are too important for enterprise and we cannot remove them from the platform. Closing this bug to match that reality. We'll open a new bug if we ever decide to do this. [1] (Feb 22, 2019)
If I remember correctly, Mozilla didn't want to support video DRM but ended up adding it to Firefox[0] in fear of losing marketshare because Netflix required DRM video playback[1].
Today's browsers are just trying to keep up with whatever Chrome decides to adopt.
Chrome is not "a different browser", it's the dominant browser. Google worked hard to achieve this state of things, and they now have a clear responsibility in terms of steering web standards. With great market share comes great responsibility.
> it does seem that about 1-2% of page views end up using XPath
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]
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.
I've decided to put this here rather than the WhatWG proposal as focusing on the Chrome statement overly much starts to see a derail.
When a Chrome representative says " The XML parts of our pipeline are in maintenance mode and we would love to eventually deprecate and remove them" I am not particularly surprised, if I were them I think I would like to get rid of these technologies too, based just on my feeling for how much they are used any more (assuming Chrome has stats and these stats bear our my feeling of low usage).
This of course also makes me sad in that I have quite a bit of experience with these technologies and their remove establishes their irrelevance in the present day ( or argues strongly for their increasing irrelevance, too strong a word choice might invite complaint). Believe me I would love if XPath was improved because maybe I might see ads for developers with advanced XPath again and I could increase my rates.
However I don't think it has ever been stated before that this is what Chrome would like. As such I think it falls under the rubric "Things everybody knows but nobody says", which generally nobody says these things because nobody wants to go through the onerous work of dealing with the implications. But as it has been said I start to wonder what those implications are/would be.
SVG has already been mentioned in the linked thread, I don't know if that is actually a problem because I don't know if SVG has been implemented using libxml in Chrome, I could totally see a point not to implement SVG with that - but then again I could see that if you have libxml and you need to implement the SVG DOM, maybe you use libxml to do it - so does getting rid of libxml impact SVG in Chrome?
Obviously applications working with RSS and other associated feed formats in the browser would probably stop to work. Of course people could write applications for these formats on the server, but it certainly seems a setback for RSS.
The same thing applies for RDF, and linked data applications running client side. Not many I know but hey, a nail in the coffin as it were.
MathML - which has never been implemented by Chrome has client side implementations, for example https://pshihn.github.io/math-ml/ I wonder if these would continue working, I would guess probably not.
What about XHTML, is anything there part of the Chrome XML stack - for example DTDs?
I can think of a few other things, but this seems like a reasonable start to think of what the implications would be.
> Chrome is not interested in this. The XML parts of our pipeline are in maintenance mode and we would love to eventually deprecate and remove them
> -- https://github.com/whatwg/dom/issues/903#issuecomment-707748...
Given Chrome's status as the new IE6 in terms of market share and outsized influence over the technological direction of the web, there's a real risk of moves like this being unilateral.
On the other hand, the last two comments re: libxml being their primary concern do give some hope.