10 ms·

Google is killing the open web, part 2

• andsoitis 11mo ago
  I don’t know. The author makes some arguments I could get entertain and get behind, but they also enumerate the immense complexity that they want web browsers to support (incl. Gopher). Whether or not Google deprecating XSLT is a “political” decision (in authors words), I don’t know that I know for sure, but I can imagine running the Chrome project and steering for more simplicity.
  • PaulHoule 11mo ago
    The case for JPEG XL is much better than that for XSLT. On the other hand, people who program in C will always be a little terrified of XML and everything around it since the parsing code will be complex and vulnerable.
    • _sr6i 11mo ago
      Having a background in C/C++, that was the problem I ran into when I had to learn XSLT at translation company that used it to style documents across multiple formats. The upside of using XML was that you could store semantically rich info into the tags for the translators and designers. The downside, of course, with all the metadata, was that the files could be really large and the XSLT was usually specifically programmed for that particular document and very verbose so the XSLT template might only be used a couple times.
      • PaulHoule 11mo ago
        XSLT is really strange in that it's not really what people think it is. It's really a pattern-matching and production rules system right out of the golden age of AI but people think it is just an overcomplicated Jinja2 or handlebars.
  • coldpie 11mo ago
    The drama around the XSLT stuff is ridiculous. It's a dead format that no one uses[1], no one will miss, no one wants to maintain, and that provides significant complexity and attack surface. It's unambiguously the right thing to do to remove it. No one who actually works in the web space disagrees. Yes, it's a problem that Chrome has too much market share, but XSLT's removal isn't a good demonstration of that. [1] Yes, I already know about your one European law example that you only found out exists because of this drama.
    • bryanrasmussen 11mo ago
      >Yes, I already know about your one European law example What example is that?
      • coldpie 11mo ago
        This page is styled via an XSLT transform: https://www.europarl.europa.eu/politicalparties/index_en.xml https://www.europarl.europa.eu/politicalparties/index_en.xml The drama mongers like to bring it up as an example of something that will be harmed by XSLT's removal, but it already has an HTML version, which is the one people actually use.
    • Analemma_ 11mo ago
      Another bit of ridiculousness is pinning the removal on Google. Removing XSLT was proposed by Mozilla and unanimously supported with no objections by the rest of the WHATWG. Go blame Mozilla if you want somebody to get mad at, or least blame all the browser vendors equally. This has nothing to do with Chrome’s market share.
      • troupo 11mo ago
        Google are the ones immediately springing into action. They only started collecting feedback on which sites may break after they already pushed "Intention to remove" and prepared a PR to remove it from Chromium.
        • 11mo ago
  • ablob 11mo ago
    "Steering for more simplicity" would be a political decision. Keeping it is also a political decision. Removing a feature that is used, while possibly making chrome more "simple", also forces all the users of that feature to react to it, lest their efforts are lost to incompatibility. There is no way this can not be a political decision, given that either way one side will have to cope with the downsides of whatever is (or isn't) done. PS: I don't know how much the feature is actually used, but my rationale should apply to any X where X is a feature considered to be pruned.
    • crazygringo 11mo ago
      No, the idea is that "political decision" is used in opposition to a decision based on rational tradeoffs. If there isn't enough usage of a feature to justify prioritizing engineering hours to it instead of other features, so it's removed, that's just a regular business-as-usual decision. Nothing "political" about it. It's straightforward cost-benefit. However, if the decision is based on factors beyond simple cost-benefit -- maintaining or removing a feature because it makes some influential group happy, because it's part of a larger strategic plan to help or harm something else, then we call that a political decision. That's how the term "political decision" in this kind of context is used, what it means.
      • troupo 11mo ago
        > If there isn't enough usage of a feature to justify prioritizing engineering hours to it instead of other features, so it's removed, that's just a regular business-as-usual decision. Nothing "political" about it. It's straightforward cost-benefit. Then why is Google actively shoving multiple hardware APIs into the browser (against the objection of other vendors) if their usage is 10x less than that of XSLT? They have no trouble finding the resource to develop and maintain those
        • crazygringo 11mo ago
          You have to keep developing new things to see what proves useful in the long-run. When you have something that's been around for a long time and still shows virtually no usage, it's fine to pull the plug. It's a kind of evolution. You can kill things that are proven to be unpopular, while building things and giving them the time to see if they become popular. That's what product feature iteration is.
  • ForHackernews 11mo ago
    The company that invented "Web Bluetooth" doesn't have a leg to stand on whining about "immense complexity" in having to maintain old stable features in their browser implementation.
  • zzo38computer 11mo ago
    If you really want to improve the simplicity, there are better ways to do so rather than excluding Gopher. (Also, they could make XSLT (and many other things that are built-in) into an extension instead, therefore making the core system more simpler.)
    • joshuamorton 11mo ago
      > (Also, they could make XSLT (and many other things that are built-in) into an extension instead, therefore making the core system more simpler.) This appears to be what they are doing, in fact!
• wryoak 11mo ago
  I think imma convert my blog to XML/XSLT. Nobody reads it anyway, but now I’ll be able to blame my lack of audience on chrome.
• pjmlp 11mo ago
  It is Chrome OS Platform nowadays, powered by Chrome market share, and helped by everyone shipping Electron garbage.
• beanjuiceII 11mo ago
  [flagged]
• altmind 11mo ago
  Do you remember that chrome lost FTP support recently? The protocol was widely used and simple enough.
  • chb 11mo ago
    Widely used? By whom? Devs who don't understand rsync or scp? Give me a practical scenario where a box is running FTP but not SSH. Edit: then account for the fact that this rare breed of content uploader doesn't use an FTP client... there's absolutely no reason to have FTP client code in a browser. It's an attack surface that is utterly unnecessary.
    • Demiurge 11mo ago
      Also, the protocol is pretty much a holdover from the earliest days, before encryption, or complicated NATs. I remember using it with just telnet a few times. It's pretty cool, but absolutely nobody should be using FTP these days. I remember saying this back in the 2005, and here we are 20 years later, someone still lamenting dropping FTP support from a browser? I think we're decades overdue.
      • tracker1 11mo ago
        I'm not lamenting it being removed.. but will say that it was probably a huge multiple more popular and widely used than XSLT is in the browser.
        • Demiurge 11mo ago
          I'm genuinely curious about that. But, this says a lot more about how different these standards are. FTP really needed a good successor, which it never really got. So, there is a strong use case, but technical deficiency to the protocol. So, FTP was overcome by a meriad of web forms and web drive sites, as a way to fill the gap. Still, resumable chunked uploads are really hard to implement from scratch, even now. Dropping XSLT is about something different. It's not bad an in an obvious way. It's things like code complexity vs applicability. It's definitely not as clear of an argument to me, and I haven't touched XSLT in the past 20 years of web development, so I am not sure about the trade-offs.
• jamesbelchamber 11mo ago
  Do the up-and-coming new browsers/engines (Servo, Ladybird.. others?) plan to support XSLT? If they do already, do they want to remove it?
  • righthand 11mo ago
    Yes they are going to support it because there are modern libraries that do.
• krautburglar 11mo ago
  Everyone is in a rush to digest the old web into proprietary models--from Google & Bing's AI summaries to Elon's Grokipedia--harvesting the work of others without credit or compensation. Why does XSLT even matter at that point? Or even HTML & CSS, when the model can serialize the data any way you choose? Anything that puts Chrome on a diet is probably for the best.
• Aurornis 11mo ago
  I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them. > I will keep using XSLT, and in fact will look for new opportunities to rely on it. This is the closest I’ve seen, but it’s not an explanation of why it was important before the deprecation. It’s a declaration that they’re using it as an act of rebellion.
  • crazygringo 11mo ago
    Yeah, the idea that it's some kind of foundation of the "open web" is quite silly. I've used XSLT plenty for transforming XML data for enterprises but that's all backend stuff. Until this whole kerfuffle I never knew there was support for it in the browser in the first place. Nor, it seems, did most people. If there's some enterprise software that uses it to transform some XML that an API produces into something else client-side, relying on a polyfill seems perfectly reasonable. Or just move that data transformation to the back-end.
  • jerf 11mo ago
    What a horrible technology to wrap around your neck for rebellion's sake. XSLT didn't succeed because it's fundamentally terrible and was a bad idea from the very beginning. But I suppose forcing one's self to use XSLT just to spite Google would constitute its own punishment.
    • veeti 11mo ago
      It has nothing to do with the specifics of the technology. As a consumer of online content, I don't care one bit if it is styled with XSLT or CSS (though as a developer my condolences are with the author, if they worked with XSLT). However, what I do care about is that it _remains viewable and usable_. Imagine if Microsoft Word one day decided you couldn't open .doc or .rtf files from the early 2000's? The browser vendors have decided that the web is now an application delivery platform where developers must polyfill backwards compatibility, past documents be damned. And just as the article drives the point home, it doesn't have to be this way. They could just provide the polyfill within the browser, negating any purported security issues with ancient XML libraries.
• jll29 11mo ago
  Let's all move to Ladybird next August.
  • pessimizer 11mo ago
    Just in time for Apple to buy it.
  • GalaxyNova 11mo ago
    the article doesn't say kind things about it..
  • recursive 11mo ago
    Have to get everyone off Windows first. If you can do that, switching to Ladybird should be easy.
• nwellnhof 11mo ago
  Removing XSLT from browsers was long overdue and I'm saying that as ex-maintainer of libxslt who probably triggered (not caused) this removal. What's more interesting is that Chromium plans to switch to a Rust-based XML parser. Currently, they seem to favor xml-rs which only implements a subset of XML. So apparently, Google is willing to remove standards-compliant XML support as well. This is a lot more concerning.
  • xmcp123 11mo ago
    It’s interesting to see the casual slide of Google towards almost internet explorer 5.1 style behavior, where standards can just be ignored “because market share”. Having flashbacks of “<!--[if IE 6]> <script src="fix-ie6.js"></script> <![endif]-->”
    • granzymes 11mo ago
      The standards body is deprecating XSLT with support from Mozilla and Safari (Mozilla first proposed the removal). Not sure how you got from that to “Google is ignoring standards”.
      • andrewl-hn 11mo ago
        Probably if Mozilla didn't push for it initially XSLT would stay around for another decade or longer. Their board syphons the little money that is left out of their "foundation + corporation" combo, and they keep cutting people from Firefox dev team every year. Of course they don't want to maintain pieces of web standards if it means extra million for their board members.
        • echelon 11mo ago
          Mozilla's board are basically Google yes-people. I'm convinced Mozilla is purposefully engineered to be rudderless: C-suite draw down huge salaries, approve dumb, mission-orthgonal objectives, in order to keep Mozilla itself impotent in ever threatening Google. Mozilla is Google's antitrust litigation sponge. But it's also kept dumb and obedient. Google would never want Mozilla to actually be a threat. If Mozilla had ever wanted a healthy side business, it wasn't in Pocket, XR/VR, or AI. It would have been in building a DevEx platform around MDN and Rust. It would have synergized with their core web mission. Those people have since been let go.
• deleted 11mo ago
  [deleted]
• yegle 11mo ago
  Isn't the decision made by all the browser vendors (including Apple and Mozilla)?
  • etchalon 11mo ago
    They're obviously in on it. /s
• dfabulich 11mo ago
  In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser" Actually, you can make an RSS feed user-browsable by using JavaScript instead. You can even run XSLT in JavaScript, which is what Google's polyfill does. I've written thousands of lines of XSLT. JavaScript is better than XSLT in every way, which is why JavaScript has thrived and XSLT has dwindled. This is why XSLT has got to go: https://www.offensivecon.org/speakers/2025/ivan-fratric.html https://www.offensivecon.org/speakers/2025/ivan-fratric.html
  • ndriscoll 11mo ago
    > JavaScript is better than XSLT in every way Obviously not in every way. XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. It gives a very low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements. You link a template just like you link a CSS file to reuse styles. Obvious. The equivalent Javascript functionality's documentation[0] starts going on about classes and callbacks and shadow DOM, which is by contrast not at all approachable for someone who just wants to make a web page. Obviously Javascript is necessary if you want to make a web application, but those are incredibly rare, and it's expected that you'll need a programmer if you need to make an application. Part of the death of the open web is that the companies that control the web's direction don't care about empowering individuals to do simple things in a simple way without their involvement. Since there's no simple, open way to make your own page that people can subscribe to (RSS support having been removed from browsers instead of expanded upon for e.g. a live home page), everyone needs to be on e.g. Facebook. It's the same with how they make it a pain to just copy your music onto your phone or backup your photos off of it, but instead you can pay them monthly for streaming and cloud storage. [0] https://developer.mozilla.org/en-US/docs/Web/API/Web_components https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
    • dfabulich 11mo ago
      XSL is a Turing-complete functional programming language, not a declarative language. When you xsl:apply-template, you're calling a function. Functional programming languages can often feel declarative. When XSL is doing trivial, functional transformations, when you keep your hands off of xsl:for-each, XSL feels declarative, and doesn't feel that bad. The problem is: no clean API is perfectly shaped for UI, so you always wind up having to do arbitrary, non-trivial transformations with tricky uses of for-each to make the output HTML satisfy user requirements. XSL's "escape hatch" is to allow arbitrary Turing-complete transformations, with <xsl:variable>, <xsl:for-each>, and <xsl:if>. This makes easy transformations easy and hard transformations possible. XSL's escape hatch is always needed, but it's absolutely terrible, especially compared to JS, especially compared to modern frameworks. This is why JS remained popular, but XSL dwindled. > It gives a low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements. JavaScript is a much better low-effort high-power on-ramp to templated web pages with no build steps or server software. JavaScript is the natural fit for adding custom HTML elements (web components). Seriously, XSLT is worse than JavaScript in every way, even at the stuff that XSLT is best at. Performance/bloat? Worse. Security? MUCH worse. Learnability / language design? Unimaginably worse. EDIT: You edited your post, but the Custom Element API is for interactive client-side components. If you just want to transform some HTML on the page into other HTML as the page loads, you can use querySelectorAll, the jQuery way.
• apeters 11mo ago
  The day will come when DRM is used to protect the whole http body.
  • silon42 11mo ago
    Cutting us Linux users off the Web.
    • doublerabbit 11mo ago
      Probably a good thing. Allows us to use it as an opportunity to make a new "web" without the mess of HTTP.
• spankalee 11mo ago
  This page makes some wild claims, like Google wants to deprecate MathML, even though it basically just landed. Yeah, the Chrome team wasn't prioritizing the work and it came through Igalia, but the best time for Chrome to kill MathML would have been before it was actually usable on the web. The post also fails to mention that all browsers want to remove XSLT. The topic was brought up in several meetings by Firefox reps. It's not a Google conspiracy. I also see that the site is written in XHTML and think the author must just really love XML, and doesn't realize that most browser maintainers think that XHTML is a mistake and failure. Being strict on input in failing to render anything on an error is antithetical to the "user agent" philosophy that says the browser should try to render something useful to the user anyway. Forgiving HTML is just better suited for the messy web. I bet this fuels some of their anger here.
  • kstrauser 11mo ago
    I was all in on the concept of XHTML back in the day because it seemed obviously superior to chaotic, messy HTML. Nothing got me off that bandwagon as effectively as me converting a web app to emit pristine, validated XHTML and learning that no 2 browsers could process it the same way. Forget pixel-perfect layout and all that jazz. I couldn’t even get them to display the whole page reliably.
  • zzo38computer 11mo ago
    XHTML does have some advantages compared with ordinary HTML, such as the parsing being more consistent, since the file will specify where literal text is used and which commands are or are not a block that is expected to contain other things. (It could still try to render in case of an error, but display the error message as well, perhaps.)
    • spankalee 11mo ago
      HTML parsing is specified, including what to do for various errors, and very consistent across browsers. XML parsing may be more regular, but that's not really an advantage to users in any way, while HTML's resiliency is.
• pessimizer 11mo ago
  What you actually want is a web that isn't decided by the whims of massive monopolies, not XSLT. XSLT is not good. Google will not be caring that you do not comply, and that you don't install their polyfill; it's some real vote with your wallet middle-class style consumer activism. It's an illusion of control. If you don't eat the bugs, you'll starve, then everyone is eating the bugs. Try having an opposition party that isn't appointing judges like Amit Mehta. Or pardoning torturers, and people who engineered the financial crash, and people who illegally spied on everyone, etc., etc. But good luck with that, we can't even break up a frozen potato monopoly.
• thayne 11mo ago
  I don't disagree that Google is killing the open web. But XSLT is a pretty weak argument for showing that. It is an extremely complicated feature that is very seldom used. I am very doubtful dropping support is some evil political decision. It is much more likely they just don't want to sink resources into maintaining something that is almost never used. For the specific use case of showing RSS and Atom feeds in the browser, it seems like a better solution would be to have built-in support in the browser, rather than relying on the use of XSLT.
  • Fileformat 11mo ago
    Of course built-in support for RSS would be better. But what are the chances of that happening?
    • thayne 11mo ago
      Probably better than browser makers committing to maintaining an xslt library.
      • righthand 11mo ago
        They didn’t have to maintain it. There was a simpler solution and switch to a library that wasn’t broken.
    • homebrewer 11mo ago
      We already had it, both Firefox and the old Opera supported viewing (and subscribing to) RSS feeds.
  • AlotOfReading 11mo ago
    The sites that will be broken are disproportionately important though. Congress.gov/govinfo.gov, weather.gov, europa.gov, plus dozens of sites for libraries, and universities. Looking only at how many sites use a feature gives you an incomplete view. If a feature were only used by Wikipedia, it'd still be inappropriate to deprecate it with a breaking change and a short (1yr) migration window. You work with the important users to retire it and then start pulling the plug publicly to notify everyone you might have missed.
• ChrisArchitect 11mo ago
  Related large discussion: XSLT RIP https://news.ycombinator.com/item?id=45873434 https://news.ycombinator.com/item?id=45873434
• charcircuit 11mo ago
  >Mozilla bent over to Google's pressure to kill off RSS by removing the “Live Bookmarks” features from the browser They both were just responding to similar market demands because end users didn't want to use RSS. Users want to use social media instead. >This is a trillion-dollar ad company who has been actively destroying the open web for over a decade Google has both done more for and invested more into progressing the open web than anyone else. >The WHATWG aim is to turn the Web into an application delivery platform This is what web developers want and browsers our reacting to the natural demands of developers, who are reacting to demands of users. It was an evolutionary process that got it to that state. >but with their dependency on the Blink rendering engine, controlled by Google, they won't be able to do anything but cave Blink is open source and modular. Maintaining a fork is much less effort than the alternative of maintaining a different browser engine.
  • gbalduzzi 11mo ago
    I agree with everything, but just to be clear: > This is what web developers want I don't think it is what web developers want, it is what customers expect. Of course there are plenty of situation where the page is totally bloated and could be much leaner, but the overall trend to build web applications instead of web pages is dictated by user expectations and, as a consequence, requirements.
    • LtWorf 11mo ago
      Users say "the page shall not load in less than 15 seconds and shall not use less than 5% of my monthly dataplan"? Odd… are these people with us?
  • carlosjobim 11mo ago
    > They both were just responding to similar market demands because end users didn't want to use RSS. Users want to use social media instead. How does that become a market demand to remove RSS? There are tons of features within browsers which most users don't use. But they do no harm staying there.
  • Fileformat 11mo ago
• koakuma-chan 11mo ago
  I didn't know XSLT existed before this drama.
  • righthand 11mo ago
    That’s because they didn’t want you to know about it. Hence letting it languish for 20 years and 2 major versions. The players doing this have been intentionally doing it for a few decades.
  • canvas12 11mo ago
    me too
• et1337 11mo ago
  I’m no Google fan, but deprecating XSLT is a rare opportunity to shrink the surface area of the web’s “API” without upsetting too many people. It would be one less thing for independent browsers like Ladybird to worry about. Thus actually weakening Google’s chokehold on the browser market.
  • basscomm 11mo ago
    > but deprecating XSLT is a rare opportunity to shrink the surface area of the web’s “API” without upsetting too many people There's a lot of back and forth on every discussion about XSLT removal. I don't know if I would categorize that as 'without upsetting too many people'
    • kstrauser 11mo ago
      We are largely the nerds that other nerds picked on for being too nerdy. I’d bet that a hugely disproportionate share of all the people in the world who care about this subject at all are here in these conversations.
      • wpm 11mo ago
        Actual normies don’t think of the Internet at all. They open Facebook The App on their iPads and smartphones and that’s the internet for them. Passionate nerds giving a shit can build a far more rosy world than whatever that represents, so I don’t see why anyone should give a damn if this happens to be somewhat niche.
• kellengreen 11mo ago
  Today I Learned: There's a built-in class called XSLTProcessor.
• tiffanyh 11mo ago
  Isn't Google one of the few (if not only), major tech company that would want to keep alive the open web ... given their business model.
  • bilog 11mo ago
    Their business model is selling ads. They don't give a rats ass about the open web.
• joeldg 11mo ago
  [dead]
• jeffbee 11mo ago
  "Nobody wants my nerd bullshit, part 42"
• dpark 11mo ago
  This has nothing to do with the “open web”. I don’t know if the people saying this just don’t have a meaningful definition of what open means or what. “Open” doesn’t mean “supports everything anyone has ever shipped in a browser”. (Chrome should support Gopher, really? Gopher was literally never part of the World Wide Web.) What’s happening is that Google (along with Mozilla and Safari) are changing the html spec to drop support for xslt. If you want to argue that this is bad because it “breaks the web”, that’s fine, but it has nothing at all to do with whether the web is “open”. The open web means anyone can run a web server. Anyone can write a web site. Anyone can build their own compatible browser (hypothetically; this has become prohibitively expensive). It means anyone can use the tech, not that the tech includes everything possible. If you want to complain about Google harming the open web, there are some real examples out there. Google Reader deprecation probably hurt RSS more than anything else. AMP was/is an attempt to give Google tighter control over more web traffic. Chrome extension changes were pushed through seemingly to give Google tighter control over ad blockers. Gemini in the search results is an attempt to keep Google users from ever actually clicking through to web sites for information. XSLT in the browser has been dead for years. The reality is that no browser developer has cared about xslt since 1.0. Don’t blame Google for the death of xslt when xslt 2.0 was standardized before Chrome was even released and no one else cared enough to implement it. The removal of xslt doesn’t change the openness of the web and the reality is that it breaks very little while eliminating a source of real security errors.
  • shadowgovt 11mo ago
    > Google Reader deprecation probably hurt RSS more than anything else And, indeed, if the protocol was one killer app deprecation and removal away from being obsolete, the problem was the use case, not the protocol. (Personally, I don't think RSS is dead; it's very much alive in podcasting. What's dead is people consuming content from specific sites as a subscription model instead of getting most of their input slop-melanged in through their social media feeds; they don't care about the source of the info, they just want the info. I don't think that's something we fix with improved RSS support; it's a behavior issue looking for a better experience than Facebook, not for everyone to wake up one day and decide to install their own feed reader and stop browsing Facebook or Twitter or even Mastodon for links all day).
• gwbas1c 11mo ago
  For the past 10-15 years, every time I look at web standards, it always feels like someone is trying to make browsers support their specific niche use case. Seems like getting XSLT (and offering a polyfill replacement) is just a move in the direction of stopping applications from pushing their complexity into the browser.
• shadowgovt 11mo ago
  I don't think I'm plugged into the side of the Internet that considers XML "the backbone of an independent web." I think XML has some good features, but in general infatuation with it as either a key representation or key transmission protocol has waned over the years. Everything I see on the wire these days is JSON or some flavor of binary RPC like protobuffer; I hardly ever see XML on the wire anymore.
  • zzo38computer 11mo ago
    XML is not so good for most of the things it was used for, and JSON has some problems too (I prefer DER), but Google is doing many bad things with WWW and not only things relating to XML, whether or not XML is good.
• shadowgovt 11mo ago
  Okay, I was entertaining the author's position to a point, but I have to get off the train where they sing the praises of NPAPI. Hey fam. I remember NPAPI. I wrote a very large NPAPI plugin. The problem with NPAPI is that it lets people run arbitrary code as your browser. it was barely sandboxed. At best, it let any plugin do its level best to crash your browser session. At worst, it's a third-party binary blob you can't inspect running in the same thing you use to control your bank account. NPAPI died for a good reason, and it has little to do with someone wanting to control your experience and everything to do with protecting you, the user, from bad actors. I think the author tips their hand a little too far here; the world they're envisioning is one where the elite hackers among us get to keep using the web and everyone else just gets owned by mechanisms they can't understand, and that's fine because it lets us be "wild" and "free" like we were in the nineties and early aughts again. Coupled with the author's downplaying of the security concerns in the XSLT lib, the author seems comfortable with the notion that security is less important than features, and I think there's a good reason that the major browser creators and maintainers disagree. The author's dream, at the bottom, "a mesh of building blocks," is asking dozens upon dozens upon dozens of independent operators to put binary blobs in your browser outside the security sandbox. We stopped doing that for very, very good reasons.
  • zzo38computer 11mo ago
    > put binary blobs in your browser outside the security sandbox There are reasons to do this sometimes, but usually it would be better to put them inside of the security sandbox (if the security sandbox can be designed in a good way). The user (or system administrator) could manually install and configure any native code extensions (without needing to recompile the entire browser), but sandboxed VM codes would also be available and would be used for most stuff, rather than the native code.
    • shadowgovt 11mo ago
      We already have two infrastructures to do that: the JavaScript engine and wasm. And, indeed, part of the deprecation of XSLT proposal involves, in essence, moving XSLT processing from the browser-native layer to wasm as a polyfill that a site author can opt into.
• dang 11mo ago
  Prequel: Google is killing the open web - https://news.ycombinator.com/item?id=44949857 https://news.ycombinator.com/item?id=44949857 - Aug 2025 (181 comments) Also related. Others? XSLT RIP - https://news.ycombinator.com/item?id=45873434 https://news.ycombinator.com/item?id=45873434 - Nov 2025 (459 comments) Removing XSLT for a more secure browser - https://news.ycombinator.com/item?id=45823059 https://news.ycombinator.com/item?id=45823059 - Nov 2025 (337 comments) Intent to Deprecate and Remove XSLT - https://news.ycombinator.com/item?id=45779261 https://news.ycombinator.com/item?id=45779261 - Nov 2025 (149 comments) XSLT removal will break multiple government and regulatory sites - https://news.ycombinator.com/item?id=44987346 https://news.ycombinator.com/item?id=44987346 - Aug 2025 (146 comments) Google did not unilaterally decide to kill XSLT - https://news.ycombinator.com/item?id=44987239 https://news.ycombinator.com/item?id=44987239 - Aug 2025 (128 comments) "Remove mentions of XSLT from the html spec" - https://news.ycombinator.com/item?id=44952185 https://news.ycombinator.com/item?id=44952185 - Aug 2025 (535 comments) Should we remove XSLT from the web platform? - https://news.ycombinator.com/item?id=44909599 https://news.ycombinator.com/item?id=44909599 - Aug 2025 (96 comments)
• 1vuio0pswjnm7 11mo ago
  "The WHATWG aim is to turn the Web into an application delivery platform, a profit-making machine for corporations where the computer (and the browser through it) are a means for them to make money off you rather than for you to gain access to services you may be interested in." "Such vision is in direct contrast with that of the Web as a repository of knowledge, a vast vault of interconnected documents whose value emerges from organic connections, personalization, variety, curation and user control. But who in the WHATWG today would defend such vision?" "Maybe what we need is a new browser war. Not one of corporation versus corporation -doubly more so when all currently involved parties are allied in their efforts to enclose the Web than in fostering an open and independent one- but one of users versus corporations, a war to take back control of the Web and its tools." It should be up to the www user not the web developer to determine how they prefer the documents to appear on their screen Contrast this with one or a few software programs, i.e, essentially a predetermined selection (no choice), that purport to offer all possible preferences to all www users, i.e., the so-called "modern" browser. These programs are distributed by companies that sell ad services and their business partners (Mozilla) Documents can be published in a "neutral" format, JSON or whatever, and users can choose to convert this, if desired, to whatever format they prefer. This is more or less the direction the web has taken however at present the conversion is generally being performed by web developers using (frequently obfuscated) Javascript, intended to be outside the control of the user Although from a technical standpoint, there is nothing that requires (a) document retrieval and (b) document display to be performed by the same program, commercial interests have tried to force users toward using one program for everything (a "do everything program")^1 When users run "do everything programs" from companies selling ad services and their business partners to perform both (a) and (b), they end up receiving "documents" they never requested (ads) and getting tracked If users want such "do everything" corporate browsers, if they prefer "do everything programs", then they are free to choose them, but there should be other choices and it should be illegal to discriminate against other software as long as rules of "netiquette" are followed. A requirement to use some "do everything program" is not a valid rule "There's more to the Internet than the World Wide Web built around the HTTP protocol and the HTML file format. There used to be a lot of the Internet beyond the Web, and while much of it still remains as little more than a shadow of the past, largely eclipsed by the Web and what has been built on top of it (not all of it good) outside of some modest revivals, there's also new parts of it that have tried to learn from the past, and build towards something different." Internet subscribers pay a relatively high price for access in many countries According to one RFC author the www became the "the new waist" But to use expensive internet access only for "the web", especially a 100% commercial, obsessively surveilled one filled with ads, is also a "waste", IMHO 1. Perhaps the opposite of "do one thing well". America's top trillionaire wants to create another of these "do everything programs", one to rule them all. These "do everything programs" will always exist but they should never be the only viable options. They should never be "required"
• overgard 11mo ago
  This guy seems pretty focused on XML based standards, but I think the reason XML based standards are dying is because people don't like working with XML.
  • rhdunn 11mo ago
    The entire publishing and standards industries are built around XML (JATS and other XML formats). They use XSLT to generate HTML, PDF, EPUB, and other format files. I don't see the XML-based SVG image format going anywhere. The ODF, EPUB, and other formats also use XML. Those are not dying.
• pmdr 11mo ago
  Google is just one of the companies killing the open web. None of them will say it outright, but they'll just scrounge up enough "security" reasons for their decisions to seem palatable, even to the HN crowd. They're just turning up the heat, even more so since AI became a thing.
• rendall 11mo ago
  > ...just in case the questionable “no politics” policies —which consistently prove to be weasel words for “we're right-wingers but too chicken to come out as such”— weren't enough to stay away from it. I am sympathetic to the stance of the article, but this line really turned me off and made me wonder if I was giving the writer too much credit. This kind of "if you're not with me, then you suck" outlook is childish and off-putting. I know it's hard for some terminally political people to understand, but some of us really, really think it's a strength to work with teammates who hold different opinions than our own.
• zzo38computer 11mo ago
  I like the idea they mentioned of "a browser made up of composable components, protocol handlers separate from primary document renderers separate from attachment handlers", and I had the same idea. (Not all browsers will have to be implemented in this way, and they are not necessarily all the same, but this can be helpful when you want this.) There can be two kind of extensions, sandboxed VM codes (e.g. WebAssembly) and native codes; the app store will only allow sandboxed VM codes, and any native codes that you might want must be installed and configured manually. There is also the issue of such things as: identification of file formats (such as MIME), character sets, proxies, etc. I hade made up Scorpion protocol and file format which is intended to be between Gemini and "WWW as it should be if it was designed better". This uses ULFI rather than MIME (to avoid some of the issues of MIME), and supports TRON character code, and the Scorpion conversion file can be used to specify a way to handle unknown file formats (there are several ways that this can be specified, including by a uxn code). So, an implementation can be versatile to support things that can be useful beyond only MIME and Unicode etc. Adding some additional optional specifications to WWW might also help, e.g. a way to specify that certain parts of the document are supposed be overridden by the user specifications in the client when they are available (although in some cases the client could guess, e.g. if a CSS only selects by HTML commands and media queries and not by anything else (or no CSS at all), then it should be considered unnecessary and the user's specifications of CSS can be used instead if they have been specified). Something like the Scorpion conversion file would be another possibility to have, possibly by adding a response header. The previous "Google is killing the open web" article also mentions some similar things, but also a few others: > in 2015, the WHATWG introduces the Fetch API, purportedly intended as the modern replacement for the old XMLHttpRequest; prominently missing from the new specification is any mention or methods to manage XML documents, in favor of JSON Handling XML or JSON should probably better be a separate function than the function for downloading files, though. (Also, DER is better for many things) > in 2024, Google discontinues the possibility to submit RSS feeds for review to be included in Google News This is not an issue having to do with web browsers, although it is related to the issues that do have to do with web browsers (not) handling RSS. > in 2025, Google announces a change in their Chrome Root Program Policy that within 2026 they will stop supporting certificate with an Extended Key Usage that includes any usage other than server [...]; this effectively kills certificates commonly used for mutual authentication While I think they should not have stopped supporting such certificates (whoever the certificate is issued to probably should better make their own decision), it is usually helpful to use different certificates for client authentication anyways, so this is not quite as bad as they say, although it is still bad. (X.509 client authentication would also have many other benefits, which I had described several times in the past.) > in 2021, Google tried to remove [alert(), prompt(), and confirm()], again citing “security” as reason, despite the proposed changes being much more extensive than the purported security threat, and better solutions being proposed Another issue is blocking events and JavaScript execution (which can sometimes be desirable; in the case of frames it should be better to only block one frame though), and modal dialog boxes potentially blocking other functions in the browser (which is undesirable). For the former case, there other other things that can be done, though, such as a JavaScript object that controls the execution of another JavaScript context which can then be suspended like a generator function (without needing to be a generator function).
• Evidlo 11mo ago
  Why can't the polyfill be enabled by default? It would fix the security issues and we wouldn't have to worry about breaking websites. The JS polyfill also makes supporting modern XSLT feasible.
  • basscomm 11mo ago
    I tried the JS polyfill on some of the basic XSLT that I wrote, and it only kinda worked. I can't imagine how it would fail on anything with any complexity.
• tehjoker 11mo ago
  I don't get it, is XSLT used for anything important currently? I learned about it in uni, but I've basically never encountered it since.
• downsplat 11mo ago
  I'm sure there are plenty of problems with the open web, and that Google is not entirely a stranger to them... but removing an ancient language that basically failed to get traction is not one of them. No matter how elegant and advanced a certain class of nostalgic XML programmers find it. And no, XSLT doesn't have much to do with how much RSS thrives or not. RSS is basically consumed by RSS reader backends, not directly by users on their browser. One of the web platform's problems, is that it accumulates untold cruft from every failed experiment. The entire XHTML exercise turned out to be an expensive mistake, but we can't remove that because too many pages depend on it, and it ended up in a whole lot of places, including the EPUB definition. But at least XSLT could get removed. Yay for that.
• rldjbpin 11mo ago
  the op keeps highlighting how these actions affect rss feeds, including references to previous instances such as: > when Mozilla bent over to Google's pressure to kill off RSS by removing the “Live Bookmarks” features from the browser if hypothetically the browsers stop supporting the format, nothing stops dedicated rss/atom/json feed readers to work as normal. might be my myopic point of view but most users to still use the standard has predominantly used this approach since google reader days.
• deleted 11mo ago
  [deleted]