I agree with the premise of the title and some practices Google employs. But, I can't help but feel that this article is heavily colored by the author's bias and preference for certain...
I agree with the premise of the title and some practices Google employs. But, I can't help but feel that this article is heavily colored by the author's bias and preference for certain technologies. This in turn effectively mixes up cause and effect for a variety of things they string together to come to their narrative.
It makes for a confused bit of reading, burying some valid points the author does raise.
Both the "little bit of history" and "Google's war on XML as a proxy for the war against the open web" paragraphs heavily feature examples that don't belong in the list. Some things that stood out:
The author presents this as the first shot in a deliberate war to kill RSS. This mixes up cause and effect. In my mind it is equally likely (and less of a conspiracy) that user habits were already shifting towards platforms like Twitter and Facebook at the time. The shutdown probably didn't help with that trend, that is for sure, but I doubt it was part of a war against XML. In fact, if reader had a meaningful user base, I'd expect that Google would have kept it around and focussed on somehow monetizing this user base better.
The author somehow mixes in Mozilla a few times as a stand in for Google as well (Yes, Mozilla relies on the search engine deal, that doesn't make them a Google subsidiary) and also here mixes cause and effect.
Throwing in fetch as an example that Google hates XML. It is clear the author really likes XML. Which, from a structured data standpoint I can get behind. But in the context of the web JSON is a very valid format for probably a majority of the data that is being send around. Even more so since JSON natively maps to javascript objects. So, in the javascript runtime it makes sense to deal with JSON and not XML.
Including AMP as though it were about XML. AMP is problematic for centralization and control reasons, but it has nothing to do with XML being sidelined.
What is JPEG XL even doing in the timeline? Whatever you think of Google killing JPEG XL, it has nothing to do with XML/XSLT, and lumping it in just causes confusion.
The HTTPS push is a complex security issue with legitimate arguments on both sides. It also, again, has nothing do with XML.
Manifest V3 while highly anti-competitive also has nothing to do with XML. The author acknowledges this, but basically says "I am going to shoehorn it in anyway".
There are a few points where I do agree with the author in regard to the title.
XMPP federation closure was genuinely an anticompetitive move that hurt the open web
XSLT being stuck at version 1.0 since 1999 while newer versions exist is suspicious, odd to say the least. Though I should note that Chrome wouldn't be around for almost a decade after 1999.
The removal of MathML support was questionable and took a decade to reverse
There is a real trend toward centralization where Google heavily participates in.
So yeah Google is trying very hard to kill the open web, but I am highly confused why the author things this is centered around XML
Most of us use JSON these days but I guess there are some XML diehards. XML support is not the same as "support for the open web" despite what they claim. You can still load data into a browser...
Most of us use JSON these days but I guess there are some XML diehards. XML support is not the same as "support for the open web" despite what they claim.
You can still load data into a browser using whatever data format you like, but you'll need to use JavaScript libraries to do it. After transitioning away from built-in browser API's, that will be more resilient because nobody's going cancel JavaScript.
JSON also has the benefit of numerous heavily battle tested encoders and decoders, some of which are included out of the box with newer programming languages (zero dependencies!). 99% of whatever...
JSON also has the benefit of numerous heavily battle tested encoders and decoders, some of which are included out of the box with newer programming languages (zero dependencies!). 99% of whatever you’re doing will just work with these implementations with zero caveats or fuss.
Compare this to XML which is one of the biggest bags of caveats and corner cases you’ll ever encounter in software. Encoding and decoding is a lot more painful and error prone and a lot of the time you’ll end up doing things by hand.
To me this makes JSON a better fit for an open web simply because it’s reliable and accessible. Is it as powerful or flexible as XML? No, but this may be a case of, “worse is better”.
I don’t find it too bad for simpler XML, but readability rapidly degrades as both level of nesting and number of attributes increases. Machine generated XML can be particularly painful, as anybody...
I don’t find it too bad for simpler XML, but readability rapidly degrades as both level of nesting and number of attributes increases. Machine generated XML can be particularly painful, as anybody who’s had to untangle a merge-conflicted iOS XIB or storyboard knows. Even XAML isn’t all that fun to read in my opinion.
The same complaints about nesting and attributes can also be said of JSON, though. We just solve most of those issues with formatting - but we can do the same thing with XML. Many of the things...
The same complaints about nesting and attributes can also be said of JSON, though. We just solve most of those issues with formatting - but we can do the same thing with XML. Many of the things that display XML will actually do so automatically.
I think one of the reasons why I hate XML less than most people is that I primarily used it in the context of Java enterprise applications, where tools to handle XML data make needing to manually alter XML files essentially unnecessary most of the time. The only times I would have to edit XML manually were for a handful of applications that used XML for configuration (which feels like it should have been a lot more common, but I didn't see it much). When the tools handle the markup for you it's hard to complain.
Libraries like Spring have been moving from XML to annotation-based configurations for good reason. Even with rendering and linking extensions, it's more challenging to deal with a separated...
The only times I would have to edit XML manually were for a handful of applications that used XML for configuration (which feels like it should have been a lot more common, but I didn't see it much).
Libraries like Spring have been moving from XML to annotation-based configurations for good reason. Even with rendering and linking extensions, it's more challenging to deal with a separated config file in a huge code base.
It's difficult to navigate huge XML files imo. It's easier to fold and unfold different levels of nesting in JSONs.
I disagree with some of the authors takes, mostly cases where they leave out info that would force a different interpretation or assign malicious intent where it was unlikely to have existed. On...
I disagree with some of the authors takes, mostly cases where they leave out info that would force a different interpretation or assign malicious intent where it was unlikely to have existed. On balance, though, I agree with their points.
There is a lot of valuable info to be found in the post about the history of the web and Google's increasingly negative impact on it. Early on Google was a undeniably a force for good on so many levels. They improved the user and developer experience on the web, they fought legal battles that no one else could have afforded to fight (outside of corps that wouldn't even consider taking up a battle that didn't directly impact their quarterlies) and they did an amazing job of making the web accessible to the mainstream through their search engine.
Those days are long gone of course and the thing to learn from it, which many presciently pointed out long ago in response to "do no evil", is that in a big enough corporate environment good never lasts. Eventually it becomes solely about the profits and the enshittification begins.
For the reminder of that lesson alone I applaud the post. The best time to apply this lesson is before a company is big enough to have the widespread impact that Google does, at which point it's kinda too late. It should be baked into our understanding of technology so that it influences our tech and stack choices even when the corp in question is still relatively small.
Back to the post's core point: XML should continue to be supported. I have no argument there, nothing wrong with XML. People are still using it, keep supporting it. I don't think, though, that it's a particularly key part of the open web as long as there are other standards that accomplish the same goal in an open way. JSON, for example, seems to do that. But that's kind of a nitpick as either way there's no good reason to be against XML.
IMO the premise that Google is an opponent of the open web is undeniably true. They proved that conclusively with Manifest V3.
The author is weirdly obsessed with XML and XSLT and is judging everything through this one weird lens. Has anyone used XSLT voluntarily within a webpage for anything but an obscure tech demo in...
The author is weirdly obsessed with XML and XSLT and is judging everything through this one weird lens. Has anyone used XSLT voluntarily within a webpage for anything but an obscure tech demo in this millennium? (Has a non-tech-demo webpage ever been linked on Tildes that relied on browser support for XSLT? Would a list of "top 10,000 historical websites" contain even one that relied on XSLT?) Why should browsers support or further develop these entire separate page and styling formats in addition to HTML and CSS? Do they offer any specific power that the current web platform lacks? This is like getting mad at modern PC manufacturers for not including PS/2 ports for ancient keyboards and mice. Roughly 0% of users or working web developers want it and the remaining people can use an adapter (like a separate program or a page with embedded JS that renders XML+XSLT). Anything else about Chrome development is more consequential than this.
It's a weird bit for them to rail on Google about backing out from JPEG XL support, when the whole initiative to include it was from Google, they were the only browser to even implement it, and they backed out because no other browsers were interested in implementing it at the time and Google wanted to avoid fragmenting the web in this way. Also Google has successfully pushed other new efficient media formats like WebP and WebM, so it's not like they're consistently a blocker to progress. (Everything negative anyone ever says about WebP is just about other software not supporting it, which is an issue that would face any new format including JPEG XL. Just bringing this up because weirdly often I see people get really deranged into some kind of team sports mindset where they label WebP as a bad and evil thing that Google pushed on the world and JPEG XL as this pure and great thing that Google killed, and none of that framing makes any sense except as an excuse to have an information-free rant about Google.)
The only real substantial point is about RSS support being removed, but I struggle to blame the browsers for it. Were RSS features in the browser actually used by many people? Firefox's support IIRC was just that you could make a bookmark folder be populated by RSS, and it was an extremely lackluster experience! Is it specifically the browser developer's job to develop a compelling RSS reader? Anyone could make an RSS reader, and if nobody has made a successful and compelling RSS reader, then it feels weird to fault browser developers for not being the first to do so. (Okay, people do often point at the long-dead Google Reader, but if its design was so good, where are its successful clones? I mean I'm sure it has a few but they're not successful enough for me to have heard of them, and I don't agree that it's every browser's job to push that system to users.) I really get the impression that far more people like to bring up RSS to rant about the death of the "open web" or such than people actually use RSS.
I do feel like there’s a hole in web standards that XSLT was designed to fill, even if it ultimately never filled it. It’s probably worth considering designing something more aligned with the...
I do feel like there’s a hole in web standards that XSLT was designed to fill, even if it ultimately never filled it. It’s probably worth considering designing something more aligned with the current ecosystem to meet those needs, though.
Agreed on RSS, though some browsers used to display indicators when a site made RSS feeds available, making it easier to add them to your preferred reader, and particularly handy for when the site admin forgot to put the appropriate linked badge on the site. It would be nice to see those indicators come back, but full reader capability probably isn’t necessary.
[...] back on August 1st, Mason Freed of Google opened issue #11523 on WHATWG’s HTML repository, asking if XSLT should be removed from browsers and giving a condensed set of reasons why it might be a good idea. He also included a WASM-based polyfill he’d written to provide XSLT support, should browsers remove it, and opened “ Investigate deprecation and removal of XSLT” in the Chromium bug tracker.
...
[...] [W]hile Mason was the one to open the issue, this was done because the idea was raised in a periodic WHATNOT meeting (call), where someone at Mozilla was actually the one to bring it up, after it had come up in various conversations over the previous few months. After Mason opened the issue, members of the Mozilla and WebKit teams expressed (tentative, mostly) support for the idea of exploring this removal. Basically, none of the vendors are particularly keen on keeping native XSLT support in their codebases, particularly after security flaws were found in XSLT implementations.
This isn’t the first time they’ve all agreed it might be nice to slim their codebases down a little by removing something that doesn’t get a lot of use (relatively speaking), and it won’t be the last. I bet they’ve all talked at some point about how nice it would be to remove BMP support.
...
Second of all, the issue was opened to start a discussion and gather feedback as the first stage of a multi-step process, one that could easily run for years. Google, as I assume is true for other browser makers, has a pretty comprehensive method for working out whether removing a given feature is tenable or not.
I always appreciate Eric's takes. Styling RSS feeds is literally the only thing I've ever seen XSLT used for. I've run it across it maybe once or twice in 20 years, and I love weird obscure stuff...
I always appreciate Eric's takes.
Styling RSS feeds is literally the only thing I've ever seen XSLT used for. I've run it across it maybe once or twice in 20 years, and I love weird obscure stuff like that. It just doesn't seem very important to the foundation of the web. I can completely understand why the vendors would want to remove it -- especially if it has any security exposure.
I agree with the premise of the title and some practices Google employs. But, I can't help but feel that this article is heavily colored by the author's bias and preference for certain technologies. This in turn effectively mixes up cause and effect for a variety of things they string together to come to their narrative.
It makes for a confused bit of reading, burying some valid points the author does raise.
Both the "little bit of history" and "Google's war on XML as a proxy for the war against the open web" paragraphs heavily feature examples that don't belong in the list. Some things that stood out:
There are a few points where I do agree with the author in regard to the title.
So yeah Google is trying very hard to kill the open web, but I am highly confused why the author things this is centered around XML
Most of us use JSON these days but I guess there are some XML diehards. XML support is not the same as "support for the open web" despite what they claim.
You can still load data into a browser using whatever data format you like, but you'll need to use JavaScript libraries to do it. After transitioning away from built-in browser API's, that will be more resilient because nobody's going cancel JavaScript.
JSON also has the benefit of numerous heavily battle tested encoders and decoders, some of which are included out of the box with newer programming languages (zero dependencies!). 99% of whatever you’re doing will just work with these implementations with zero caveats or fuss.
Compare this to XML which is one of the biggest bags of caveats and corner cases you’ll ever encounter in software. Encoding and decoding is a lot more painful and error prone and a lot of the time you’ll end up doing things by hand.
To me this makes JSON a better fit for an open web simply because it’s reliable and accessible. Is it as powerful or flexible as XML? No, but this may be a case of, “worse is better”.
And it's not very readable. Formatted JSONs are easy to understand.
I don't know about that; I find XML to be pretty easy to read.
I don’t find it too bad for simpler XML, but readability rapidly degrades as both level of nesting and number of attributes increases. Machine generated XML can be particularly painful, as anybody who’s had to untangle a merge-conflicted iOS XIB or storyboard knows. Even XAML isn’t all that fun to read in my opinion.
The same complaints about nesting and attributes can also be said of JSON, though. We just solve most of those issues with formatting - but we can do the same thing with XML. Many of the things that display XML will actually do so automatically.
I think one of the reasons why I hate XML less than most people is that I primarily used it in the context of Java enterprise applications, where tools to handle XML data make needing to manually alter XML files essentially unnecessary most of the time. The only times I would have to edit XML manually were for a handful of applications that used XML for configuration (which feels like it should have been a lot more common, but I didn't see it much). When the tools handle the markup for you it's hard to complain.
Libraries like Spring have been moving from XML to annotation-based configurations for good reason. Even with rendering and linking extensions, it's more challenging to deal with a separated config file in a huge code base.
It's difficult to navigate huge XML files imo. It's easier to fold and unfold different levels of nesting in JSONs.
I disagree with some of the authors takes, mostly cases where they leave out info that would force a different interpretation or assign malicious intent where it was unlikely to have existed. On balance, though, I agree with their points.
There is a lot of valuable info to be found in the post about the history of the web and Google's increasingly negative impact on it. Early on Google was a undeniably a force for good on so many levels. They improved the user and developer experience on the web, they fought legal battles that no one else could have afforded to fight (outside of corps that wouldn't even consider taking up a battle that didn't directly impact their quarterlies) and they did an amazing job of making the web accessible to the mainstream through their search engine.
Those days are long gone of course and the thing to learn from it, which many presciently pointed out long ago in response to "do no evil", is that in a big enough corporate environment good never lasts. Eventually it becomes solely about the profits and the enshittification begins.
For the reminder of that lesson alone I applaud the post. The best time to apply this lesson is before a company is big enough to have the widespread impact that Google does, at which point it's kinda too late. It should be baked into our understanding of technology so that it influences our tech and stack choices even when the corp in question is still relatively small.
Back to the post's core point: XML should continue to be supported. I have no argument there, nothing wrong with XML. People are still using it, keep supporting it. I don't think, though, that it's a particularly key part of the open web as long as there are other standards that accomplish the same goal in an open way. JSON, for example, seems to do that. But that's kind of a nitpick as either way there's no good reason to be against XML.
IMO the premise that Google is an opponent of the open web is undeniably true. They proved that conclusively with Manifest V3.
The author is weirdly obsessed with XML and XSLT and is judging everything through this one weird lens. Has anyone used XSLT voluntarily within a webpage for anything but an obscure tech demo in this millennium? (Has a non-tech-demo webpage ever been linked on Tildes that relied on browser support for XSLT? Would a list of "top 10,000 historical websites" contain even one that relied on XSLT?) Why should browsers support or further develop these entire separate page and styling formats in addition to HTML and CSS? Do they offer any specific power that the current web platform lacks? This is like getting mad at modern PC manufacturers for not including PS/2 ports for ancient keyboards and mice. Roughly 0% of users or working web developers want it and the remaining people can use an adapter (like a separate program or a page with embedded JS that renders XML+XSLT). Anything else about Chrome development is more consequential than this.
It's a weird bit for them to rail on Google about backing out from JPEG XL support, when the whole initiative to include it was from Google, they were the only browser to even implement it, and they backed out because no other browsers were interested in implementing it at the time and Google wanted to avoid fragmenting the web in this way. Also Google has successfully pushed other new efficient media formats like WebP and WebM, so it's not like they're consistently a blocker to progress. (Everything negative anyone ever says about WebP is just about other software not supporting it, which is an issue that would face any new format including JPEG XL. Just bringing this up because weirdly often I see people get really deranged into some kind of team sports mindset where they label WebP as a bad and evil thing that Google pushed on the world and JPEG XL as this pure and great thing that Google killed, and none of that framing makes any sense except as an excuse to have an information-free rant about Google.)
The only real substantial point is about RSS support being removed, but I struggle to blame the browsers for it. Were RSS features in the browser actually used by many people? Firefox's support IIRC was just that you could make a bookmark folder be populated by RSS, and it was an extremely lackluster experience! Is it specifically the browser developer's job to develop a compelling RSS reader? Anyone could make an RSS reader, and if nobody has made a successful and compelling RSS reader, then it feels weird to fault browser developers for not being the first to do so. (Okay, people do often point at the long-dead Google Reader, but if its design was so good, where are its successful clones? I mean I'm sure it has a few but they're not successful enough for me to have heard of them, and I don't agree that it's every browser's job to push that system to users.) I really get the impression that far more people like to bring up RSS to rant about the death of the "open web" or such than people actually use RSS.
I do feel like there’s a hole in web standards that XSLT was designed to fill, even if it ultimately never filled it. It’s probably worth considering designing something more aligned with the current ecosystem to meet those needs, though.
Agreed on RSS, though some browsers used to display indicators when a site made RSS feeds available, making it easier to add them to your preferred reader, and particularly handy for when the site admin forgot to put the appropriate linked badge on the site. It would be nice to see those indicators come back, but full reader capability probably isn’t necessary.
No, Google Did Not Unilaterally Decide to Kill XSLT
...
...
I always appreciate Eric's takes.
Styling RSS feeds is literally the only thing I've ever seen XSLT used for. I've run it across it maybe once or twice in 20 years, and I love weird obscure stuff like that. It just doesn't seem very important to the foundation of the web. I can completely understand why the vendors would want to remove it -- especially if it has any security exposure.