- This isn't Chrome doing this unilaterally. https://github.com/whatwg/html/issues/11523 shows that representatives from every browser are supportive and there have been discussions about this in standards meetings: https://github.com/whatwg/html/issues/11146#issuecomment-275...
- You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time.
- Opening a PR doesn't necessarily mean that it'll be merged. Notice the unchecked tasks - there's a lot to still do on this one. Even so, give the cross-vendor support for this is seems likely to proceed at some point.
It's an issue open on the HTML spec for the HTML spec maintainers to consider. It was opened by a Chrome engineer after at least two meetings where a Mozilla engineer raised the topic, and where there was apparently vendor support for it.
This is happening after some serious exploits were found: https://www.offensivecon.org/speakers/2025/ivan-fratric.html
And the maintainer of libxslt has stepped down: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913
[1] https://blog.startifact.com/posts/xee/
It's not just a matter of replacing the libxslt; libxslt integrates quite closely with libxml2. There's a fair amount of glue to bolt libxml2/libxslt on to Blink (and WebKit); I can't speak for Gecko.
Even when there's no work on new XML/XSLT features, there's a passive cost to just having that glue code around since it adds quirks and special cases that otherwise wouldn't exist.
My understanding is that browsers specifically use the 1999 version and changing this would break compat
To be completely honest, though, I'm not sure what people expect to get out of it. I dug into this a while ago for a rather silly reason and I found that it's very inside baseball, and unless you really wanted to get invested in it it seems like it'd be hard to meaningfully contribute.
To be honest if people are very upset about a feature that might be added or a feature that might be removed the right thing to do is probably to literally just raise it publicly, organize supporters and generally act in protest.
Google may have a lot of control over the web, but note that WEI still didn't ship.
Everyone likes to complain as a user of open source. Nobody likes to do the difficult work.
XSLT is used on the web. That's why people are upset about Google & friends removing it while ignoring user feedback.
Outside of this is a whole universe.
It’s been years since I’ve touched it, but clicking the congressional bill XML link and seeing a perfectly formatted and readable page reminded me of exactly why XSLT has a place. To do the same thing without it, you’d need some other engine to parse the XML, convert it to HTML, and then ensure the proper styles get applied - this could of course be backend or frontend, either way it’s a lot of engineering overhead for a task that, with XSLT, requires just a stylesheet.
No, you can use <?xml-stylesheet ?> directives with CSS to attach a css stylesheet directly to an xml file.
CSS is not as flexible as xslt, but this seems to be very simple formatting which is well within what css is capable of.
It has no process for discussing removal of features or for speaking out against a feature
The bug trackers are also a fine place to provide community feedback. For example there's plenty of comments providing use cases that weren't hidden. But if you read the hidden ones (especially on the issue rather than PR) there's some truly unhinged commentary that rightly resulted in being hidden and unfortunately locking of the thread.
Ultimately the way the community can influence decisions is to not be completely unhinged.
Like someone else said the other way would be to just use XSLT in the first place.
Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize the word "credible" here. You are facing an extremely uphill battle from the visible lack of support for the development; any truly credible offer should have come many years ago. Big projects are well aware of the utility of last-minute, emotionally-driven offers of support in the midst of a burst of publicity, viz, effectively zero.
I don't know that the power is as imbalanced as people think here so much as a very long and drawn out conversation has been had by the web as a whole, on the whole the web has agreed this is not a terribly useful technology by vast bulk of implementation work, and this is the final closing chapter where the browsers are basically implementing the will of the web. The standard for removal isn't "literally 0 usage in the entire world", and whatever the standard is, if XSLT isn't on the "remove" side of it, that would just be a sign it needs to be tuned up because XSLT is a complete non-entity on the web. If you are not feeling like your voice is being respected it's because it's one of literally millions upon millions; what do you expect?
[1]: I know exceptions are reading this post, but you are exceptions. And not terribly common ones.
I have a hard time buying the idea that document templating is some niche use-case compared to pretty much every modern javascript api. More realistically, lots of younger people don't know it's there. People constantly bemoan html's "lack" of client side includes or extensible component systems.
There's probably half-a-dozen other things that could stand serious thought about removal.
There is one major difference though, which is that if you remove webusb, the functionality is just gone, whereas XSLT can be done through Javascript/WebASM just fine.
Document templating is obviously not a niche case. That's why we've got so many hundreds of them. We're not lacking in solutions for document templating, we're drowning in them. If XSLT stands out in its niche, it is as being a particularly bad choice, which is why nobody (to that first approximation we've all heard so much about) uses it.
edit: I see Simon mentioned it - https://simonwillison.net/2025/Aug/19/xslt/ - e.g., https://www.congress.gov/119/bills/hr3617/BILLS-119hr3617ih.... - the site seems to be even less popular than Longhorn Steakhouse in Germany.
My guess is that they'll shuffle people to PDF or move rendering to the server side, which is a common (and, with today's computing power, extremely cheap) way to generate HTML from XML.
Further, PDF and server-side are fine for achieving the same display, but it removes the XML of it all - that is to say, someone might be using the raw XML to lower tools, feeds, etc. if XSLT goes away and congress drops the XML links in favor of PDFs etc, that breaks more than just the pretty formatting
2. One should still be able to retrieve the raw XML document. It's just that it won't be automatically transformed client-side.
It's been a standard part of the Web platform for years. The only question should be, "Is _anyone_ using it?", not whether it's being "used like crazy" or not.
Don't break the Web.
But useful websites are much less likely to be infested by the all consuming Goo admalware.
Seriously, i doubt this.
There was a time where the standard way to build a highly interactive SPA was using SOAP services on the backend combined with iframes on the front end that executed XSLT in the background to update the DOM.
Obviously such an approach is extremely out of date and you won't find it on any websites you use. But, a lot of critical enterprise software was built this way and is kind of stuck like this.
Afaik IE 5 did not support XSLT. It supported a proprietary similar language that was different. I think IE6 was first version to support XSLT.
I feel like when i see enterprise xslt a lot of it is serverside.
It's not for the public to identify these sites. It's for the arrogant Googlers to do a modicum of research
The congress one appears to be the first legit example i have seen.
At first glance the congress use case does seem like it would be fully covered by CSS [you can attach CSS stylesheets to generic xml documents in a similar fashion to xslt]. Of course someone would have to make that change.
Of course. And yet none of the people from Google even seem to be aware of
> The congress one appears to be the first legit example i have seen.
There are more. E.g. podcast RSS feeds are often presented on the web with XSLT: https://feeds.buzzsprout.com/231452.rss
Again, none of the people from Google even seem to be aware of these use cases, and just power through regardless of any concerns.
I don't see any reason to assume that. I don't think anyone from google is claiming the literal number of sites is 0, just that it is insignificant.
I am very sure the people at google are aware of the rss feed usage.
Don't confuse people disagreeing with you with people not understanding you.
No. No they aren't. As you can see in the discussion: https://github.com/whatwg/html/issues/11523 where the engineer who proposed this literally updates his "analysis" as people point out use cases he missed.
Quote:
--- start quote ---
albertobeta: there is a real-world and modern use case from the podcasting industry, where I work. Collectively, we host over 4.5 million RSS feeds. Like many other podcast hosting companies, we use XSLT to beautify our raw feeds and make them easier to understand when viewed in a browser.
mfreed7, the Googler https://github.com/whatwg/html/issues/11523#issuecomment-315... : Thanks for the additional context on this use case! I'm trying to learn more about it.
--- end quote ---
And then just last week: https://github.com/whatwg/html/issues/11523#issuecomment-318...
--- start quote ---
Thanks for all of the comments, details, and information on this issue. It's clear that XSLT (and talk of removing it) strikes a nerve with some folks. I've learned a lot from the posts here.
--- end quote ---
> Don't confuse people disagreeing with you with people not understanding you.
Oh, they don't even attempt to understand people.
Here's him last week adding a PR to remove XSLT from the spec: https://github.com/whatwg/html/pull/11563
Did he address any of the issues? Does he link to any actual research pointing out how much will be broken, where it's used etc.?
Nope.
But then another Googler pulls up, says "good work, don't forget to remove it everywhere else". End of discussion.
You're angry you didn't get your way, but the googler's decision seems logical, i think most software developers maintaining a large software platform would have made a similar decision given the evidence presented (as evidenced by other web browsers making the same one).
The only difference here between most software is that google operates somewhat in the open. In the corporate world there would be some customer service rep to shield devs from the special interest group's tantrum.
Just like they did the last time when they tried to remove confirm/prompt[1] and were surprised to see that their numbers don't paint the full picture, as literally explicitly explained in their own docs: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...
You'd think that the devs of the world's most popular browser would have a little more care than just citing some numbers, ignoring all feedback, and moving forward with whatever they want to do?
Oh. Speaking, of "not just Google".
The question was raised in this meeting: https://github.com/whatwg/html/issues/11146#issuecomment-275... Guess what.
--- start quote ---
dan: even if the data were accurate, not enough zeros for the usage to be low enough.
brian: I'm guessing people will have objections... people do use it and some like it
--- end quote ---
[1] See, e.g. https://gomakethings.com/google-vs.-the-web/
But as far as I know, there were absolutely zero efforts by browser vendors before to support newer versions of the language, while there was enormous energy to improve JavaScript.
I don't want to imply that if they had just added support for XSLT 3.0 then everyone would be using XSLT instead of JavaScript today and the latest SIMD optimizations of Chrome's XPath pipeline would make the HN front-page. The language is just too bad for that.
But I think it's true that there exists a feedback loop: Browsers can and do influence how much a technology is adopted, by making the tech less or more painful to use. Then turning around and saying no one is using the tech, so we'll remove it, is a bit dishonest.
XSLT never took off. Ever. It has never been a major force on the web, not even for five minutes. Even during the "XML all the things!" phase of the software engineering world, with every tailwind it would ever had, it was never a serious player.
There was, at no point, any reason to invest in it any farther.
Moreover, even if you push a button and rewrite history so that even so it was heavily invested in anyhow, I see no reason to believe it would have ever been a major force in that alternate history either. I would personally contend that it has always been a bad idea, and if anything, it has been unduly propped up by the browsers and overinvested in as it is. But perhaps less inflammatorily and more objectively, it has always been a foreign paradigm that most programmers have no experience in, and this was even more true in the "XML all the things!" era which predates the initial Haskell burst that pushed FP forward by a good solid decade, and the prospects of it ever being popular were never all that great.
Then browser devs could treat it like an extension (plus some small shims in the core) while the public API wouldn't have to change.
in order to create a menu where the current active page is highlighted and not a link, i need to do this:
<a>
<xsl:choose>
<xsl:when test="@name='home'">
<xsl:attribute name="class">selected</xsl:attribute>
</xsl:when>
<xsl:otherwise>
<xsl:attribute name="href">/</xsl:attribute>
</xsl:otherwise>
</xsl:choose>
home
</a> |
<a>
<xsl:choose>
<xsl:when test="@name='about'">
<xsl:attribute name="class">selected</xsl:attribute>
</xsl:when>
<xsl:otherwise>
<xsl:attribute name="href">/about.xhtml</xsl:attribute>
</xsl:otherwise>
</xsl:choose>
about
</a> |
<xsl:variable name="nav-menu-items">
<item href="foo.xhtml"><strong>Foo</strong> Page</item>
<item href="bar.xhtml"><em>Bar</em> Page</item>
<item href="baz.xhtml">Baz <span>Page</span></item>
</xsl:variable>
<xsl:template match="nav-menu">
<nav>
<ul>
<xsl:apply-templates select="$nav-menu-items/item">
<xsl:with-param name="current" select="@current-page"/>
</xsl:apply-templates>
</ul>
</nav>
</xsl:template>
<xsl:template match="item">
<xsl:param name="current"/>
<li>
<xsl:choose>
<xsl:when test="@href=$current">
<a class="selected"><xsl:apply-templates/></a>
</xsl:when>
<xsl:otherwise>
<a href="{@href}"><xsl:apply-templates/></a>
</xsl:otherwise>
</xsl:choose>
</li>
</xsl:template>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<xsl:mode on-no-match="shallow-copy"/>
<xsl:variable name="menu-items">
<item href="foo.xhtml"><strong>Foo</strong> Page</item>
<item href="bar.xhtml"><em>Bar</em> Page</item>
<item href="baz.xhtml">Baz <span>Page</span></item>
</xsl:variable>
<xsl:template match="nav-menu">
<nav>
<ul>
<xsl:apply-templates select="$menu-items/item"/>
</ul>
</nav>
</xsl:template>
<xsl:template match="item">
<li>
<xsl:variable name="current-page" select="tokenize(base-uri(/),'/')[last()]"/>
<a href="{if (@href = $current-page) then '' else @href}"
class="{if (@href = $current-page) then 'selected' else ''}">
<xsl:apply-templates/>
</a>
</li>
</xsl:template>
<xsl:template match="nav-menu">
<nav>
<ul>
<li><a href="foo.xhtml">Foo</a></li>
<li><a href="bar.xhtml">Bar</a></li>
<li><a href="baz.xhtml">Baz</a></li>
</ul>
</nav>
</xsl:template>
your last example is what i started out with, including the pass through template. you may remember this message from almost two months ago: https://news.ycombinator.com/item?id=44398626
one comment for the xslt 3 example: href="" doesn't disable the link. it's just turns into a link to self (which it would be anyways if the value was present). the href attribute needs to be gone completely to disable the link.
nodes you output don't have type "node-set" - instead, they're what is called a "result tree fragment". You can store that to a variable, and you can use that variable to insert the fragment into output (or another variable) later on, but you cannot use XPath to query over it.
the xsl documentation https://www.w3.org/TR/xslt-10/#variables says:
Variables introduce an additional data-type into the expression language. This additional data type is called result tree fragment. A variable may be bound to a result tree fragment instead of one of the four basic XPath data-types (string, number, boolean, node-set). A result tree fragment represents a fragment of the result tree. A result tree fragment is treated equivalently to a node-set that contains just a single root node. However, the operations permitted on a result tree fragment are a subset of those permitted on a node-set. An operation is permitted on a result tree fragment only if that operation would be permitted on a string (the operation on the string may involve first converting the string to a number or boolean). In particular, it is not permitted to use the /, //, and [] operators on result tree fragments.
so using apply-templates on a variable doesn't work. this is actually where i got stuck before. i just was not sure because i could not verify that everything else was correct.
i wonder if it is possible to load the menu from a second document: https://www.w3.org/TR/xslt-10/#document
edit: it is!
<xsl:apply-templates select="document('nav-menu.xml')/menu">
Adding xmlns:exsl="http://exslt.org/common" to your xsl:stylesheet and doing select="exsl:node-set($nav-menu-items)/item" seems to work on both Chrome and Librewolf.
here is the actual stylesheet i am using:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:exsl="http://exslt.org/common" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml">
<xsl:output method="html"/>
<xsl:variable name="nav-menu">
<item href="/">Home</item>
<item href="/about.xhtml">About</item>
</xsl:variable>
<xsl:template match="document">
<html>
<head>
<meta charset="utf-8" />
<title><xsl:value-of select="title" /></title>
<link rel="stylesheet" type="text/css" href="site.css" />
</head>
<body>
<!-- <xsl:apply-templates select="document('nav-menu.xml')/menu"> -->
<xsl:apply-templates select="exsl:node-set($nav-menu)/item">
<xsl:with-param name="current" select="@name"/>
</xsl:apply-templates>
<xsl:apply-templates select="content" />
</body>
</html>
</xsl:template>
<xsl:template match="item">
<xsl:param name="current"/>
<xsl:choose>
<xsl:when test="@href=$current">
<a class="selected"><xsl:apply-templates/></a>
</xsl:when>
<xsl:otherwise>
<a href="{@href}"><xsl:apply-templates/></a>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<xsl:template match="content">
<xsl:apply-templates select="@*|node()" />
</xsl:template>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<?xml-stylesheet type="text/xsl" href="site.xsl"?>
<document name="about">
<title>About Us</title>
<content>
html content here, to be inserted without change
</content>
</document>
<menu>
<item href="/">Home</item>
<item href="/about.xhtml">About</item>
</menu>
<xsl:variable name="nav-menu-items" xmlns="">
<item href="/">Home</item>
<item href="/about.xhtml">About</item>
</xsl:variable>
The test is failing because it's `/about.xhtml` in the template but `about` outside. You'd either need to add a name attribute to item to compare on or make it match the href.
That should make your thing work if I haven't fooled myself again. :)
you are right. i removed it, and it works. typical "copy from stackoverflow" error. these namespaces are a mystery and not intuitive at all. i suppose most people don't notice that because it only applies to xml data within the stylesheet. most people won't have that so they won't notice an issue. the less the better.
for the other error, my mistake, duh! in my original example in https://news.ycombinator.com/item?id=44961352 i am comparing $current/@name to a hardcoded value, so if i want to keep that comparison i have to add that value to the nav-menu data. or use a value that's already in there.
i went with adding a name="about" attribute to the nav-menu because it keeps the documents cleaner: <document name="about"> just looks better, and it also allows me to treat it like an ID that doesn't have to match the URL which allows renaming/moving documents around without having to change the content. (they might go from about.xhtml to about/index.xhtml for example)
i am also probably going to use the document() function instead of exsl:node-set() because having the menu data in a separate file in this case is also easier to manage. it's good to know about that option though. being able to iterate over some local data is a really useful feature. i'll keep that around as an example.
the final piece of the puzzle was:
<xsl:if test="position() != last()"> | </xsl:if>
that sorted, now it all works. thank you again.
btw, it's funny that we are turning hackernews into an xsl support forum. i guess i should write all that up into a post some day.
li + li::before {
content: " | ";
}
You're right on the href; maybe there's not a slick/more "HTML beginner friendly" way to get rid of the <xsl:choose> stuff even in 3.0. I have no experience with 3.0 though since it doesn't work.
I get a little fired up about the XSLT stuff because I remember being introduced to HTML in an intersession school class when I was like... 6? XSLT wasn't around at that time, but I think I maybe learned about it when I was ~12-13, and it made sense to me then. The design of all of the old stuff was all very normal-human approachable and made it very easy to bite a little bit more off at a time to make your own personal web pages. "Use React and JSON APIs" or "use SSR" seems to just be giving up on the idea that non-programmers should be able to participate in the web too. Should we do away with top level HTML/CSS while we're at it and just use DOM APIs?
There were lots of things in the XML ecosystem I didn't understand at the time (what in the world was the point of XSDs and what was a schema and how do you use them to make web pages? I later came to appreciate those as well after having to work as a programmer with APIs that didn't have schema files), but the template expansion thing to make new tags was easy to latch onto.
right, that's a big issue too. when the xsl breaks (in this case when i use <xsl:apply-templates select="$nav-menu-items/item">) i get an empty page and nothing telling me what could be wrong. if i remove the $ the page works, and the apply-templates directive is just left out.
it turns out that because XSLT was largely ignored, it is full of security issues, some of which have been in there for decades.
so the reason XSLT doesn't have a history of exploits is because nobody used it.
What was the point of it though? People transpile from other languages anyway and pull megabytes of npm dependencies.
The main thing that seems unaddressed is the UX if a user opens a direct link to an XML file and will now just see tag soup instead of the intended rendering.
I think this could be addressed by introducing a <?human-readable ...some url...?> processing instruction that browsers would interpret like a meta tag redirect. Then sites that are interested could put that line at the top of their XML files and redirect to an alternative representation in HTML or even to a server-side or WASM-powered XSLT processor for the file.
Sort of like an inverse of the <link rel="alternate" ...> solution that the post mentioned.
The only thing this doesn't fix is sites that are abandoned and won't update or are part if embedded devices and can't update.
HTTP has already had this since the 90s. Clients send the Accept HTTP header indicating which format they want and servers can respond with alternative representations. You can already respond with HTML for browsers and XML for other clients today. You don’t need the browser to know how to do the transformation.
If they are so worried, then have the xslt support compiled to wasm and sandboxed.
* side effect free (a pure data to data transformation)
* stable, from a spec perspective, for decades
* completely client-side
Isn't this basically an A+ report card for any attempt at making a powerful general tool? The fact that the suggested solution in the absence of XSLT is to toil away at implementing application-specific solutions forever really feels like working toward the wrong direction.
https://thedailywtf.com/articles/Sketchy-Skecherscom
Also world of warcraft used to.
Can’t think of recent examples though.
This would work without special syntax in the XML file.
... Largely because of lack of help from major users such as browsers.
Speaking from personal experience, working on libxslt... not easy for many reasons beyond the complexity of XSLT itself. For instance:
- libxslt is linked against by all sorts of random apps and changes to libxslt (and libxml2) must not break ABI compatibility. This often constrains the shape of possible patches, and makes it that much harder to write systemic fixes.
- libxslt reaches into libxml and reuses fields in creative ways, e.g. libxml2's `xmlDoc` has a `compression` field that is ostensibly for storing the zlib compression level [1], but libxslt has co-opted it for a completely different purpose [2].
- There's a lot of missing institutional knowledge and no clear place to go for answers, e.g. what does a compile-time flag that guards "refactored parts of libxslt" [3] do exactly?
[1] https://gitlab.gnome.org/GNOME/libxml2/-/blob/ca10c7d7b513f3...
[2] https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa...
[3] https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa...
Instead Google and others just use it, and expect that any issues that come up to be immediately fixed by the one or two open source maintainers that happen to work on it in their spare time. The power imbalance must not be lost on you here...
If you wanted to dive into what [3] does, you could do so, you could then document it, or refactor it so that it is more obvious, or remove the compile time flag entirely. There is institutional knowledge everywhere...
// of course we know that, as end-users became the product, Big Tech [sic?] started making sure that users remain dumb.
The vendors cite an aspect of said responsibility (security!) to get rid of an other aspect (costly maintenance of a low-revenue feature).
The web is evolving, there's a ton of things that developers (and website product people, and end-users) want. Of course it comes with a lot of "frivolous" innovation, but that's part of finding the right abstractions/APIs.
(And just to make it clear, I think it's terrible for the web and vendors that ~100% of the funding comes from a shady oligopoly that makes money by selling users - but IMHO this doesn't invalidate the aforementioned resource allocation trade off.)
I’m having trouble expressing this in a way that won’t likely sound harsher than I really want, but, uh, yes? That’s the fundamental difference between maintaining a part of the commons that anybody can benefit from and a subdirectory in a monorepo. The bazaar incurs coordination costs, and not being able to go and fix all the callers is one of them.
(As best as I can see, Chrome’s approach is largely to make everything a part of the monorepo, so maintaining a part of the commons may not be high on the list of priorities.)
This not to defend any particular ABI choice. Too often ABI is left to luck and essentially just happens instead of being deliberately designed, and too often in those cases we get unlucky. (I’m tempted to recite an old quote[1] about file formats, which are only a bit more sticky than public ABI, because of how well it communicates the amount of seriousness the subject ought to evoke: “Do you, Programmer, take this Object to be part of the persistent state of your application, to have and to hold, through maintenance and iterations, for past and future versions, as long as the application shall live?”)
I’m not even deliberately singling out what seems to me like the weakest of the examples in your list. It’s just that ABI, to me, is such a fundamental part of lib-anything that raising it as an objection against fixing libxslt or libxml2 specifically feels utterly bizarre.
They simply didn’t seem to have a concept of data hiding and encapsulation, or worse, felt it led to evil nasty proprietary hidden code and were better than that.
They were all really nice people, mind you—i met quite a few of them, still know some—and the GNOME project has grown up a lot, but i think that’s where libxml was coming from. Daniel didn’t really expect it to be quite so widely used, though, i’m sure.
I’ve actually considered stepping up to maintain libxslt, but i don’t know enough about building on Windows and don’t have access to non-Linux systems really. Remote access will only go so far on Windows i think, although it’d be OK on Mac.
It might be better to move to one of the Rust XML stacks that are under active development (one more active than the other).
Out of those three projects, two are notoriously under-resourced, and one is notorious for constantly ramming through new features at a pace the other two projects can't or won't keep up with.
Why wouldn't the overworked/underresourced Safari and Firefox people want an excuse to have less work to do?
This appeal to authority doesn't hold water for me because the important question is not 'do people with specific priorities think this is a good idea' but instead 'will this idea negatively impact the web platform and its billions of users'. Out of those billions of users it's quite possible a sizable number of them rely on XSLT, and in my reading around this issue I haven't seen concrete data supporting that nobody uses XSLT. If nobody really used it there wouldn't be a need for that polyfill.
Fundamentally the question that should be asked here is: Billions of people use the web every day, which means they're relying on technologies like HTML, CSS, XML, XSLT, etc. Are we okay with breaking something that 0.1% of users rely on? If we are, okay, but who's going to tell that 0.1% of a billion people that they don't matter?
The argument I've seen made is that Google doesn't have the resources (somehow) to maintain XSLT support. One of the googlers argued that new emerging web APIs are more popular, and thus more deserving of resources. So what we've created is a zero-sum game where any new feature added to the platform requires the removal of an existing feature. Where does that game end? Will we eventually remove ARIA and/or screen reader support because it's not used by enough people?
I think all three browser vendors have a duty to their users to support them to the best of their ability, and Google has the financial and human resources to support users of XSLT and is choosing not to.
Billions of people use the web every day. Should the 99.99% of them be vulnerable to XSLT security bugs for the other 0.01%?
Applied to each individually it seems to make sense. However the aggregate effect is kill off a substantial portion of the web.
In fact, it's an argument to never add a new web technology: Should 100% of web users be made vulnerable to bugs in a new technology that 0% of the people are currently using?
Plus it's a false dichotomy. They could instead address XSLT security... e.g., as various people have suggested, by building in the XSLT polyfill they are suggesting all the XSLT pages start using as an alternative.
Ps. The XSLT language is actively maintained and is used in many applications and contexts outside of the browser.
If the goal is to reduce security bugs, then we should stop introducing niche features that only make sense when you are trying to have the browser replace the whole OS.
For now, there's no alternative that allows serving an XML file with the raw data from e.g. an embedded microcontroller in a way that renders a full website in the browser if desired.
Even more so if you want to support people downloading the data and viewing it from a local file.
Your microcontroller only serves the actual xml data, the xslt is served from a different server somewhere else (e.g., the manufacturer's website). You can download the .xml, double-click it, and it'll get the xslt treatment just the same.
In your example, either the microcontroller would have to serve the entire UI to parse and present the data, or you'd have to navigate to the manufacturers website, input the URL of your microcontroller, and it'd have to do a cors fetch to process the data.
One option I'd suggest is instead of
<?xml-stylesheet href="http://example.org/example2.xsl" type="text/xsl" ?>
<?xml-stylesheet href="http://example.org/example2.js" type="application/javascript" ?>
The service worker would not be associated with any specific origin, but it would still receive the regular lifecycle of events, including a fetch event for every load of an xml document pointing at this specific service worker script.
Using https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent/... it could respond to the XML being loaded with a transformed response, allowing it to process the XML similar to an XSLT.
You could even have a polyfill service worker that loads an XSLT and applies it to the XML.
I don't think anyone is arguing that XSLT has to be fast.
You could probably compile libxslt to wasm, run it when loading xml with xslt, and be done.
Does XSLT affect the DOM after processing, isn't it just a dumb preprocessing step, where the render xhtml is what becomes the DOM.
The first strategy is obviously correct, but Google wants strategy 2.
So site operators who rely on this feature today are not merely asked to load a polyfill but to fundamentally change the structure of their website - without necessarily getting to the same result in the end.
Is there a spending on junk projects issue with Firefox?
https://galaxy.ai/youtube-summarizer/is-mozilla-wasting-mone...
Google adds 1000+ new APIs to the web platform a year. They are expected to be supported nearly forever. They have no qualms adding those.
Glad to see the disdain for the actual users of their software remains.
[1] https://github.com/whatwg/html/issues/2894 [2] https://www.theregister.com/2021/08/05/google_chrome_iframe/
(FWIW I agree alert and XSLT are terrible, but that ship sailed a long time ago.)
Seriously though, if I were forced to maintain every tiny legacy feature in a 20 year old app... I'd also become a "former" dev :)
Even in its heyday, XSLT seemed like an afterthought. Probably there are a handful of legacy corporate users hanging on to it for dear life. But if infinitely more popular techs (like Flash or FTP or non HTTPS sites) can be deprecated without much fuss... I don't think XSLT has much of a leg to stand on...
Flash was not part of the web platform. It was a plugin, a plugin that was, over time, abandoned by its maker.
FTP was not part of the web platform. It was a separate protocol that some browsers just happened to include a handler for. If you have an FTP client, you can still open FTP links just fine.
Non-HTTPS sites are being discouraged, but still work fine, and can reasonably be expected to continue to work indefinitely, though they are likely to be discouraged a bit harder over time.
XSLT is part of the web platform. And removing it breaks various things.
I couldn't be more happy about its demise.
We built stuff with it that amazed users, because they were so used to the "full page reload" for every change.
Like more or less everyone that hosts podcasts. But the current trend is for podcast feeds to go away, and be subsumed into Spotify and YouTube.
And those that would replace you might care more for the web rather than the next performance review.
1. not trillion dollar tech companies
or
2. not 99% funded from a trillion dollar tech company.
I have long suspected that Google gives so much money to Mozilla both for the default search option, but also for massive indirect control to deliberately cripple Mozilla in insidious ways to massively reduce Firefox's marketshare. And I have long predicted that Google is going to make the rate of change needed in web standards so high that orgs like Mozilla can't keep up and then implode/become unusable.
They could continue supporting XSLT if they wanted.
Arguably, we could lighten the load on all three teams (especially the under-resourced Firefox and Safari teams) by slowing the pace of new APIs and platform features. This would also ease development of browsers by new teams, like Servo or Ladybird. But this seems to be an unpopular stance because people really (for good reason) want the web platform to have every pet feature they're an advocate for. Most people don't have the perspective necessary to see why a slower pace may be necessary.
This has never ever made sense because Mozilla is not at all afraid to piss in Google's cheerios at the standards meetings. How many different variations of Flock and similar adtech oriented features did they shoot down? It's gotta be at least 3. Not to mention the anti-fingerprinting tech that's available in Firefox (not by default because it breaks several websites) and opposition to several Google-proposed APIs on grounds of fingerprinting. And keeping Manifest V2 around indefinitely for the adblockers.
People just want a conspiracy, even when no observed evidence actually supports it.
>And I have long predicted that Google is going to make the rate of change needed in web standards so high that orgs like Mozilla can't keep up and then implode/become unusable.
That's basically true whether incidentally or on purpose.
You give examples of things they disagree on, and i wouldn't refute that. However i would say that google is going to pick and choose their battles, because ultimately things they appear to "lose on" sort of don't matter. fingerprinting is a great example - yes, firefox provides it, but it's still largely pretty useless, and its impact is even more meaningless because so few people use it. if you have javascript on and arent using a VPN, chances are your anti-fingerprinting isn't actually doing much other than annoying you and breaking sites.
the only real thing to be used for near-complete-anonymity is Tor, but only when it's also used in the right way, and when JavaScript is also turned off. And even then there are ways it could and probably has failed.
Did anybody bother checking with Microsoft? XML/XSLT is very enterprisey and this will likely break a lot of intranet (or $$$ commercial) applications.
Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy? It's the equivalent of the crazy cat hoarder who wormed her way onto the HOA board speaking for everyone else. No.
[0] https://gs.statcounter.com/browser-market-share/all/germany
[1] https://gs.statcounter.com/browser-market-share/desktop/germ...
/abject-speculation
> Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy?
The juxtaposition of these two statements is very funny.
Firefox actually develops a browser, Microsoft doesn't. That's why Firefox gets a say and Microsoft doesn't. Microsoft jumped off the browser game years ago.
No, changing the search engine from Google to Bing in chromium doesn't count.
Ultimately, Microsoft isn't implementing jack shit around XSLT because they aren't implementing ANY web standards.
Obviously the people doing nothing aren't a reliable source. They probably want the browser to cook your food and walk your dog, too.
That's why we ask the people actually writing the code that is being used.
But my thoughts remain. Chromium IS NOT Microsofts browser.
Chromiums opinion might matter, which might include contributers from the open source community, which might then include some Microsoft engineers.
But Microsoft, as a whole, does not develop a browser so they don't have a seat. The seats are Firefox, Safari, and Chromium/Chrome/Blink.
There was not really a vote in the first place and FF is still dependant on google. Otherwise FF (users) represants a vocal and somewhat influental minority, capable of creating shitstorms, if the pain level is high enough.
Personally, I always thought XSLT is somewhat weird, so I never used it. Good choice in hindsight.
Seems like a rigged game to me.
Yes it's a wrapper but Microsoft represents a completely different market with individual needs/wants.
If it wasn't for Apple (who doesn't care about enterprise) butting in, the browser consortium would be reminiscent of the old Soviet Union in terms of voting.
Ironic, considering the market share of XSLT.
This is also not a fair framing. There are lots of good reasons to deprecate a technology, and it doesn't mean the users don't matter. As always, technology requires tradeoffs (as does the "common good", usually.)
Because otherwise everybody has to repeat same work again and again, programming how - instead of focusing on what, declarative way.
Then data is not free, but caged by processing so it can't exist without it.
I just want data or information - not processing, not strings attached.
I don't see any need to run any extra code over any information - except to keep control and to attach other code, trackers etc. - just, I'm not Google, no need to push anything (just.. faster JS engine instead of empowering users somehow made a browser better ? (no matter how fast, you can't) - for what ? (of what I needed) - or instead of something, that they 'forgot' with a wish they could erase it ?)
Probably more like 0.0001% these days. I doubt 0.1% of websites ever used it.
It’s likely more heavily used inside corporate and governmental firewalls, but that’s much harder to measure.
This is part of why web standards processes need to be very conservative about what's added to the web, and part of why a small vocal contingent of web people are angry that Google keeps adding all sorts of weird stuff to the platform. Useful weird stuff, but regardless.
Says who? You keep mentioning this 0.1% threshold yet…
1. I can’t find any reference to that do you have examples / citations?
2. On the contrary here’s a paper that proposes a 3x higher heuristic: https://arianamirian.com/docs/icse2019_deprecation.pdf
3. It seems there are plenty of examples of features being removed above that threshold NPAPI/SPDY/WebSQL/etc.
4. Resources are finite. It’s not a simple matter of who would be impacted. It’s also opportunity cost and people who could be helped as resources are applied to other efforts.
--- start quote ---
As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in 10 million) is generally considered trivial. There are around 771 billion web pages viewed in Chrome every month (not counting other Chromium-based browsers). So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!
--- end quote ---
Read the full doc. They even give examples when they couldn't remove a feature impacting just 0.0000008% of web views.
Yup. Just like the removal of confirm/prompt that had vendor support and was immediately rushed. Thankfully to be indefinitely postponed.
Here's Google's own doc on how a feature should be removed: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...
Notice how "unilateral support by browser vendors" didn't even look at actual usage of XSLT, where it's used, and whether significant parts would be affected.
Good times.
>very, very few websites
Doesn't include all the corporate web sites that they are probably blocked from getting such telemetry for. These are the users that are pushing back.
I'm curious as to the scope of the problem, if html spec drops xslt, what the solutions would be; I've never really used xslt (once maybe, 20 years ago). In addition to just pre-rendering your webpage server-side, I assume another possible solution is some javascript library that does the transformations, if it needed to be client-side?
Found a js-only library, so someone has done this before: https://www.npmjs.com/package/xslt-processor
2. They have a semi-internal document https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... that explicitly states: small usage percentage doesn't mean you can safely remove a feature
--- start quote ---
As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in 10 million) is generally considered trivial.
There are around 771 billion web pages viewed in Chrome every month (not counting other Chromium-based browsers). So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!
--- end quote ---
3. Any feature removal on the web has to be a) given thorough thought and investigation which we haven't seen. Library of congress apparently uses XSLT and Chrome devs couldn't care less
https://www.loc.gov/standards/mods/mods-conversions.html
https://www.loc.gov/preservation/digital/formats/fdd/fdd_xml...
And then there's Congress: https://simonwillison.net/2025/Aug/19/xslt/
Before calling people arrogant you should read your own links.
[The congress example is legit]
https://www.loc.gov/standards/mets/profiles/00000016.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="echoProfile2html.xsl" ?>
So let me get this straight. The Congress example is legit. Multiple other cases discussed here: https://github.com/whatwg/html/issues/11523 are legit
And yet it's not the Googlers and other browser implementers who didn't do even a modicum or research who are arrogant, but me, because I made a potential mistake quickly searching for something on my phone at night?
Second, if HN were built upon outdated Web standards practically nobody else uses, I'm sure YCombinator could address the issue before the deadline (which would probably be at least a year or two out) to meet the needs of its community. Every plant needs nourishment to survive.
Here's we're talking about killing off XSLT used in the intended, documented, standard way.
The other suggestions ignored seemed to be "if this is about security, then fund the OSS, project. Or swap to a newer safer library, or pull it into the JS sandbox and ensure support is maintained." Which were all mostly ignored.
And "if this is about adoption then listen to the constant community request to update the the newer XSLT 3.0 which has been out for years and world have much higher adoption due to tons of QoL improvements including handling JSON."
And the argument presented, which i don't know (but seems reasonable to me), is that XSLT supports the open web. Google tried to kill it a decade ago, the community pushed back and stopped it. So Google's plan was to refuse to do anything to support it, ignore community requests for simple improvements, try to make it wither then use that as justification for killing it at a later point.
Forcing this through when almost all feedback is against it seems to support that to me. Especially with XSLT suddenly/recebtly gaining a lot of popularity and it seems like they are trying to kill it before they have an open competitor in the web.
this is a perfectly reasonable course of action if the feedback is "please don't" but the people saying "please don't" aren't people who are actually using it or who can explain why it's necessary. it's a request for feedback, not just a poll.
I'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision.
> explain why it's necessary
No feature is strictly necessary, so that's a pretty high standard.
I think the idea of that is reasonable. If I used XSLT on my tiny, low-traffic blog, I think it's reasonable for browser devs to tell me to update my code. Even if 100 people like me said the same thing, that's still a vanishingly small portion of the web, a rounding error, protesting it.
I'd expect the protests to be disproportionate in number and loudness because the billion webmasters who couldn't care less aren't weighing in on it.
Now, I'm not saying this with a strong opinion on this specific proposal. It doesn't affect me either way. It's more about the general principle that a loud number of small webmasters opposing the move doesn't mean it's not a good idea. Like, people loudly argued about removing <marquee> back in the day, but that happened to be a great idea.
(And if you did want to tell the entire world to update their code, and have any chance of them following through with it, you'd better make sure there's an immediate replacement ready. Log4Shell would probably still be a huge issue today if it couldn't be fixed in place by swapping out jar files.)
I _do_ use XSLT on my tiny, low-traffic blog, and I _don't_ think that it's reasonable for browser devs to tell me to update my code.
Also, it's real easy to manufacture a situation where adoption of a thing is low when the implementation is incomplete and hasn't had significant updates for decades.
Lots of content was lost when Flash was removed as well - much, much more than the amount of content that will be lost if XSLT is removed. And yet the web continued.
They didn't even do the tiniest bit of research, as people in the discussions clearly showed, and there are high impact sites that would be affected by this including Congress and Library of Congress: https://news.ycombinator.com/item?id=44958929
The other reason is that SVG took a very long time to get good, and when it did I wanted to use XSL and SVG together.
Now SVG has got good and they are removing it :(
https://github.com/whatwg/html/issues/11523#issuecomment-315...
Unlike your average Angular project. Building on top of minified Typescript is rather unreasonable and integrating with JSON means you have a less than reliable data transfer protocol without schema, so validation is a crude trial and error process.
There's no elegance in raw XML et consortes, but the maturity of this family means there are also very mature tools so in practice you don't have to look at XML or XSD as text, you can just unmarshal it into your programming language of choice (that is, if you choose a suitable one) and look at it as you would some other data structure.
Fixed that typo for you.
I'm very practically using Debian Linux on ChromeOS to develop test and debug enterprise software. I even compile and run some native code. It is very much more than just the web.
So is WSL on Windows. I wouldn't call Windows "just the web".
There's also nothing stopping me from building and running local desktop GUI software on the VM.
In fact, a VM is better in that I can back up and restore the image easily.
Just like the Linux VM on ChromeOS.
I'm not sure how that supports the argument that ChromeOS is only "the web". It's running a native VM for Linux today. What would be the advantage of porting it to WebAssembly?
The discussions don't address that. That surprises me, because these seem to be the people in charge of the spec.
The promise is, "This is HTML. Count on it."
Now it would be just, "This is HTML for now. Don't count on it staying that way, though."
Not saying it should never be done, but it's a big deal.
They are removing XSLT just for being a long-tail technology. The same argument would apply to other long-tail web technologies.
So what they're really proposing is to cut off the web's long tail.
(Just want to note: The list of long-tail web technologies will continue to grow over time... we can expect it to grow roughly in proportion to the rate at which web technologies were added around 20 years in the past. Meaning we can expect an explosion of long-tail web technologies soon enough. We might want to think carefully about whether the people currently running the web value the web's long tail the way we would like.)
There's a sweet spot between giving people enough time and tools to make a transition while also avoiding having your platform implode into a black hole of accumulated complexity. Neither end of the spectrum is healthy.
If this was just Android that would be an issue between Google and their developers/users, but this is everybody.
(For the same reason, they dropped the name HTML5 and are only talking about "HTML". Who needs version numbers if there is no future and no past anyway?)
https://whatwg.org/faq#living-standard https://github.com/whatwg/html/blob/main/FAQ.md#html-standar...
Seems hard to square removing XSLT with that.
I get that people are more reacting to the prospect of browsers removing existing support, but I was pretty surprised by how short the PR was. I assumed it was more intertwined.
If this was just about, e.g., organizing web standards docs for better separation of concerns, I think a lot of people would be reacting to it quite differently.
If they were one of the voices for "the browser should be lightweight and let JS libs handle the weird stuff" I would respect this action, but Google is very very not that.
That's a concise way to put it. IMHO this is also the main problem of the standard.
However I think XSLT isn't only long tail but also a curiosity with just academic value. I've being doing some experimentation and prototyping with XSLT while it was still considered alive. So even if you see some value in it, the problems are endless:
* XSLT is cumbersome to write and read
* XML is clunky, XSLT even more so
* yes there's SLAX, which is okay-ish but it becomes clear very fast that it's indeed just Syntax sugar
* there's XSLT 2.0 but there's no software support
* nobody uses it, there's no network effect in usage
I think a few years ago I stumbled upon a CMS that uses it and once I accidentally stumbled upon a Website that uses XSLT transformation for styling. That's all XSLT I ever saw in the wild being actually used.
All in all XSLT is a useless part of the way to large long tail preventing virtually everyone from writing spec compliant web browser engines.
> The promise is, "This is HTML. Count on it."
I think after HTML4 and XHTML people saw that a fully rigid standard isn't viable, so they made HTML5 a living standard with a plethora of working groups. Therefore the times where this was ever supposed to be true are long over anyway.
So indeed the correct way forward would be to remove more parts of a long tail that's hardly in use and stopping innovation. And instead maybe keeping a short list of features that allow writing modern websites.
(Also nobody is stopping anyone from using XSLT as primary language that compiles to HTML5/ES5/CSS)
Should we remove XSLT from the web platform? – 4 days ago (89 comments):
https://news.ycombinator.com/item?id=44909599
XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments):
https://news.ycombinator.com/item?id=44949857
Google is killing the open web, today, 127 comments
Imagine that tomorrow, Google announces plans to stop supporting HTML and move everyone to its own version of "CompuServe", delivered only via Google Fiber and accessible only with Google Chrome. What headline would you suggest for that occasion? "Google is killing the open web" has already been used today on an article about upcoming deprecation of XSLT format.
All the other alternatives are meaningless, including Firefox.
I am one of the few folks on my team that still uses Firefox, all our projects dropped support for it like 5 years ago.
> "- Google had a plan called "Project NERA" to turn the web into a walled garden they called "Not Owned But Operated". A core component of this was the forced logins to the chrome browser you've probably experienced (surprise!)"
To "not own but operate" seems to go into the direction of the parent comment.
Also this: https://news.ycombinator.com/item?id=28976574
[0]: https://web.archive.org/web/20211024063021/https://twitter.c...
Every discussion about "Safari holding back the web" on HN are about 99% about Google-only non-standards that both Safari and Firefox oppose.
There are multiple "works only in Chrome" websites, many of them regularly published on HN.
To me it seems that some people just really like using XSLT, and don't want it gone. Which is fair, but it also has nothing to do with the web's openness - yes, Google has far too much power, but XSLT isn't helping.
Incorrect on three counts. That article lists a bunch of useful technologies that were rejected at WHATWG with unconvincing reasons against massive public protests. It wasn't just labeling the removal of a format - that's a misrepresentation. The second is your characterization of calling XSLT niche. The article makes a case for why it is like that why it shouldn't be so. It's niche because it is neglected by the browser devs themselves. It hasn't been updated to the latest standard in a long time and it isn't maintained well enough to avoid serious bugs. And finally the third - "killing the open web" being a hyperbole. I don't even know where to start. There was a joke that web standards are proposed by someone from Google, reviewed and cleared from someone else from Google and finally approved by someone from Google. We saw this in action with WEI (The only reason for its partial rollback being the unusual attention and the massive backlash they faced from the wider tech community and mainstream media - including ours). At this point the public discussion there is just a farce. I don't know how many times this keeps repeating. That article shows many examples of this. Let me add my own recollections of the mockery to the mix - inclusion of EME and the rejection of JPEG-XL (technically not a part of the standard, but it is in a manner of speaking). It doesn't even resemble anything open.
I will be surprised if this comment doesn't receive a ton of negative votes. But there is no point in being a professional and in being here, if I'm unwilling to oppose this in public interest. The general conduct of WHATWG antithetical to public interest and are meant to escape the attention of the non-tech public. And even the voice of the savvy public is ignored repeatedly and contemptuously. It's not difficult to identify the corruptive influences of private commercial interests on these standards - EME and WEI being the tip of the iceberg. And let's not ignore the elephant in the room. It getting harder by the day to use a browser (web engine to be more precise) of your choice. In this context, the removal of XSLT isn't just a unilateral decision (please don't quote Firefox, Safari or Edge. Their interdependence is nothing short of a cabal at this point), its justification is based on problems that they themselves created.
Again expecting to be downvoted, it's hard to miss the patterns - arguments against XSLT that ignore the neglect that lead to it, and the dismissal of public comments (then why discuss it where anyone can read and post? why bill it as open?). The same happened with SMIL, JPEG XL,... It's tense to suggest attempts to drown out the opposition (I know it has a name. But that's enough trigger some), even if there are sufficient reasons to suspect it. But the flagging of that other article is a blatant indicator of that. Nothing in that article is factually false or remotely hyperbolic. Many of us are first hand witnesses of the damages and concerns it raises. The article is a good quality aggregation of the relevant history. Who is so inconvenienced by that? The only reason I can think of is the zeal to censor public interest opinions. Is the hubris in the group issue tracker spreading to public tech fora now? Conduct like this makes me lose hope that the web platform will ever be the harbinger of humanity's progress that it once promised to be. Instead it's turning out to be another slow motion casualty of unbridled greed.
PS: The flag has been cleared by the admins. But their (!admin) intent is unmistakable.
I've taken the flags off that post now.
The way I see it, any general or sweeping accusation against an entity may be construed as clickbait or too provocative for HN, even if the content backs it up sufficiently. But at what point are you going to draw the line where you consider the accusations to be credible enough to warrant such a scathing crticism? It's not as if these entities are renowned for their ethical conduct or even basic decency regarding the commons. Heated public lash back is often the only avenue they leave us. Case in point, I hope you remember the stand that the HN crowd took against WEI. Make no mistake, such discussions here don't go unnoticed. The talking points here often influence the public discourse, including by mass media. That's why there is such a fierce fight to control the narrative here.
I respect your right to your opinion. But this is essentially a political subject. And there is no getting around the fact that you cannot divorce politics from technology, or from any relevant subject for that matter. If that's considered as flame war, then I guess flame wars are an unavoidable and normal part technical discourse. It isn't personal (and no personal attacks should be involved), but the stakes are high enough for the contestants (often of high monetary nature). Attempts to curb such heated discourse will result in two serious consequences. The first is that you will give one or often both sides (ironically), the impression that HN is a place to amplify certain narratives without a balanced take. Secondly, you'll unintentionally and indirectly influence the outcome outside of HN. From my perspective, that leaves you in an unenviable predicament of such serious decisions.
So I implore you to consider these matters as well while taking such decisions. Especially to ensure that your personal biases don't influence what you consider as click and flame baits. From my personal experience, I know that you're putting in the utmost care, diligence and sincerity in those matters. But it's possible that the pressure to avoid controversies, fights and bad blood might have shifted your Overton window too far into the cautious territory over time. Probably a good yard stick is to see if the flamewar is important enough and whether it avoids personal harm (physical and emotional). I hope you'll consider this opinion when you make similar determination in the future. Regards!
HN doesn't lack for criticism of the tech BigCos. If it's true that HN influences the public discourse (which I doubt, but let's assume it does), all that influence was gained by being the same HN with the same bookish* titles and preference to avoid flamewars as we're talking about here.
I agree, politics can't be divorced from the topics discussed on HN, and it isn't (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...). That's not necessarily flamewar, though such topics are more likely to turn flameward.
Yes, many people have the impression that HN is biased, pushing one point of view over another, etc. But people will have that impression regardless. It's in the eye of the beholder, and there are many angry beholders, so we get accused of every bias you can think of. This is baked into the fundamentals of the site.
I don't think moderators' personal tastes are all that intertwined with issues like baity titles. For example, I like Lisp but if someone posted "Lisp crushes its enemies into execrable dust", I'd still edit that title to "Lisp macros provide a high degree of expressiveness" or some representative sentence from the article.
* pg's word about how he wanted the HN frontpage to be
The flagged post is a perfect example. It contains just a fraction of factual information, but it was enough for bot farms to engage. Manipulators get mad at truth.
The browsers today are too bloated and it is difficult to create a new browser engine. I wish there were simpler standards for "minimal browser", for example, supporting only basic HTML tags, basic layout rules, WASM and Java bytecode.
Many things, like WebAudio or Canvas, could be immplemented using WASM modules, which as a side effect, would prevent their use for fingerprinting.
XSLT is a specification for a "template engine" and not a specific engine. There are dozens of XSLT implementations.
Mozilla notably doesn't use libxslt but transformiix: https://web.mit.edu/ghudson/dev/nokrb/third/firefox/extensio...
> and not Jinja for example?
Jinja operates on text, so it's basically document.write(). XSLT works on the nodes itself. That's better.
> Also it can be reimplemented using JS or WASM.
Sort of. JS is much slower than the native XSLT transform, and the XSLT result is cacheable. That's huge.
I think if you view XSLT as nothing more than ancient technology that nobody uses, then I can see how you could think this is ok, but I've been looking at it as a secret weapon: I've been using it for the last twenty years because it's faster than everything else.
I bet Google will try and solve this problem they're creating by pushing AMP again...
> The browsers today are too bloated
No, Google's browser today is too bloated: That's nobody's fault but Google.
> and it is difficult to create a new browser engine
I don't recommend confusing difficult to create with difficult to sell unless you're looking for a reason to not do something: There's usually very little overlap between the two in the solution.
Perhaps there's an alternative universe where javascript lost and an elegant, declarative XSLT could declaratively present data and incrementally download only what's needed, allowing compact and elegant websites.
But in our universe today, this mapping language wound-up a half-thought-idea that just kicked around for a long time in the specs without ever making sense.
And using it to generate RSS as mentioned elsewhere in the comments? That makes perfect sense to me on the server. I don't know that I've ever even seen client-side generated RSS.
But again, this may all be my own lack of imagination.
Serving a server-generated HTML page could be even faster.
Except it isn't.
Lots of things could be faster than they are.
XSLT is XML: It can be served with the XML as a single request.
You don't have any idea what you're talking about.
> That's why Google serves (served?) its main page as a single file and not as multiple HTML/CSS/JS files.
Google.com used to be about a kilobyte. Now it's 100kb. I think it's absolutely clear Google either doesn't have the first idea how to make things fast, or doesn't care.
The XSLT can also be served once, and then cached for a very long time period, and the XML can be very small.
Nobody is going to process million of DOM nodes with XSLT because the browser won't be able to display them anyway. And one can write a WASM implementation.
You're right nobody processes a million DOM nodes with XSLT in a browser, but you're wrong about everything else: WASM has a huge startup cost.
Consider applying stylesheet properties: XSLT knows exactly how to lay things out so it can put all of the stylesheet properties directly on the element. Pre-rendered HTML would be huge. CSS is slow. XSLT gets you direct-attach, small-payload, and low-latency display.
XSLT is a templating language (like HTML is a content language), not a template engine like Blink or WebKit is a browser engine.
> Also it can be reimplemented using JS or WASM.
Changing the implementation wouldn't involve taking the language out of the web platform. There wouldn't need to be any standardization talk about changing the implementation used in one or more browsers.
They actually thought about it, and decided not to do it :-/
Audio and canvas are fundamental I/O things. You can’t shift them to WASM.
You could theoretically shift a fair bit of Audio into a WASM blob, just expose something more like Mozilla’s original Audio Data API which the Web Audio API defeated for some reason, and implement the rest atop that single primitive.
2D canvas context includes some rendering stuff that needs to match DOM rendering. So you can’t even just expose pixel data and implement the rest of the 2D context in a WASM blob atop that.
And shifting as much of 2D context to WASM as you could would destroy its performance. As for WebGL and WebGPU contexts, their whole thing is GPU integration, you can’t do that via WASM.
So overall, these things you’re saying could be done in WASM are the primitives, so they definitely can’t.
Actually, most of the time C# decompiles nicer from CLR bytecode than esoterically built JS.
But at the end of the day, you only really need one, and the type attribute was phased out of the script tag entirely, and Javascript won.
It is actively used today.
Historic reasons, and it sounds like they want it to contain zero template engines. You could transpile a subset of Jinja or Mustache to XSLT, but no one seems to do it or care.
The funny thing? No, they want to create a new one: https://github.com/WICG/webcomponents/issues/1069
Still the best framework I've ever worked with.
Because XSLT is part of the web standards.
[0] ~0.001% usage according to one post there
This is still a massive number of people who are going to be affected by this.
On the web? That's about right. See Google's own document on this: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...
Of course you can drop features, but if you work at Google I think you can pick something else, and you'll have a hard time convincing anyone that XSLT which was in Chrome back when it was fast, is why Chrome isn't fast anymore. And if you don't work at Google, why do you care? You've learned something new today. Enjoy.
Indeed: I learned that you're a condescending ass who doesn't engage with the actual argument I brought up.
They arguably became a victim of their own scale.
For better or worse, http is no longer just for serving textual documents.
Would make it possible to create spec-compliant browsers with a subset of the web platform, fulfilling different use cases without ripping out essentials or hacking them in.
I think a dedicated unsupported media type -> supported media type WASM transformation interface would be good. You could use it for new image formats and the like as well. There are things like JXL.js that do this:
And no WebAudio and Canvas couldn't be implemented in client WASM without big security implication. If by module you mean inside the browser, them, what is the point of WASM here ?
Fuck javascript, fuck wasm, fuck html, fuck css.
Rebase it all on XML/XPath/XQuery that way you only need ONE parser, one simple engine.
This whole kitchen sink/full blown OS nonsense needs to end.
Edit: You’re clearly a wasm shill, wasm is an abomination that needs to die.
I wonder what the next step of removing less-popular features will be. Probably the SMIL attributes in favor of CSS for SVG animations, they've been grumbling about those for a while. Or maybe they'll ultimately decide that they don't like native MathML support after all. Really, any functionality that doesn't fit in the mold of "a CSS attribute" or "a JS method" is at risk, including most things XML-related.
Which is miles better than having to having to use calcs for CSS animation timing which requires a kludge of CSS variables/etc to keep track of when something begins/ends time-wise, if wanting to avoid requiring Javascript. And some years ago Firefox IIRC didn't even support time-based calcs.
When Chromium announced the intent to deprecate SMIL a decade back (before relenting) it was far too early to consider that given CSS at that time lacked much of what SMIL allowed for (including motion along a path and SVG attribute value animations, which saw CSS support later). It also set off a chain of articles and never-again updated notes warning about SMIL, which just added to confusion. I remember even an LLM mistakenly believing SMIL was still deprecated in Chromium.
And there's one of the issues: browser devs are perfectly happy if user JS can be used to replicate some piece of functionality, since then it's not their problem.
It's that why Chrome unilaterally releases 1000+ web APIs a year, many of them quite complex, and spanning a huge range of things to go wrong (including access to USB, serial devices etc.)? To reduce the attack surface?
Is that a good thing or a bad thing?
Technical people like us have our desires. But the billions of people doing banking on their browsers probably have different priorities.
In any case, there's no limit on how far one can disregard compatibility in the name of security. Just look at the situation on Apple OSes, where developers are kept on a constant treadmill to update their programs to the latest APIs. I'd rather not have everything trend in that direction, even if it means keeping shims and polyfills that aren't totally necessary for modern users.
What I'm trying to say is that it's a false dichotomy in most cases: implementations could almost eliminate the attack surface while maintaining the same functionality, and without devoting any more ongoing effort. Such as, for instance, JS polyfills, or WASM blobs, which could be subjected to the usual security boundaries no matter how bug-ridden and ill-maintained they are internally.
But removing the functionality is often seen as the more expedient option, and so that's what gets picked.
In the absence of anyone raring to do that, removal seems the more sensible option.
And it is also fairly trivial to put that polyfill into the browsers.
The Chrome team has been moaning about XSLT for a decade. If security was really their concern they could have replaced the implementation with asm.js a decade ago, just as they did for pdfs.
Does it, though? Browsers already have existing XSLT stacks, which have somehow gotten by practically unmodified for the last 20 years. The basic XSLT 1.0 functionality never changes, and the links between the XSLT code and the rest of the codebase rarely change, so I find it hard to believe that slapping it into a sandbox would suddenly turn it into a persistent time sink.
So it is currently a persistent time sync, and rewriting it so that it can sit inside the browser sandbox will probably add a significant amount of work in its own right. If that's work that nobody wants to do, then it's difficult to see what your solution actually is.
As for immediate work, some in this thread have proposed compiling libxslt to WASM and using that, which sounds perfectly viable to me, if inefficient. WASM toolchains have progressed far enough that very few changes are needed to a C/C++ codebase to get it to compile and run properly, so all that's left is to set up the entry points.
(And if there really were no one-for-one replacement short of a massive labor effort, then current XSLT users would be left with no simple alternative at all, which would make this decision all the worse.)
When did they do that? Can I not still ftp://example.com in the url bar?
> my main concern is for the “long tail” of the web—there's lots of vital information only available on random university/personal websites last updated before 2005
It's a strong argument for me because I run a lot of old webpages that continue to 'just work', as well as regularly getting value out of other people's old pages. HTML and JS have always been backwards compatible so far, or at least close enough that you get away with slapping a TLS certificate onto the webserver
But I also see that we can't keep support for every old thing indefinitely. See Flash. People make emulators like Ruffle that work impressively well to play a nostalgic game or use a website on the Internet Archive whose main menu (guilty as charged) was a Flash widget. Is that the way we should go with this, emulators? Or a dedicated browser that still gets security updates, but is intended to only view old documents, the way that we see slide film material today? Or some other way?
[0]: https://chromewebstore.google.com/detail/xslt-polyfill/hlahh...
XML was unfairly demonized for the baggage that IBM and other enterprise orgs tied to it, but the standard itself was frigging amazing and powerful.
Converting a simple manually edited xml database of things to html was awesome. What I mostly wanted the ability to pass in a selected item to display differently. That would allow all sorts of interactivity with static documents.
Too heated? Looked pretty civil and reasonable to me. Would it be ridiculous to suggest that the tolerance for heat might depend on how commenters are aligned with respect to a particular vendor?
Google ignored everything, pushed on with the removal, and now pre-emptively closed this discussion, too
To be fair to Google, they've consistently steam-rolled the standards processes like that for as long as I can remember, so it really isn't new.
I find people on HN are often very motivated reasoners when it comes to judging civility, but there’s basically no excuse for calling people “fuckers” or whatever.
> We didn't forgot your decade of fuckeries, Google.
> You wanted some heated comment? You are served.
> the JavaScript brainworm that has destroyed the minds of the new generation
> the covert war being waged by the WHATWG
> This is nothing short of technical sabotage, and it’s a disgrace.
> breaking yet another piece of the open web you don't find convenient for serving people ads and LLM slop.
> Are Google, Apple, Mozilla going to pay for the additional hosting costs incurred by those affected by the removal of client-side XSLT support?
> Hint: if you don't want to be called out on your lies, don't lie.
> Evil big data companies who built their business around obsoleting privacy. Companies who have built their business around destroying freedom and democracy.
> Will you side with privacy and freedom or will you side with dictatorship?
Bullshit like this has no place in an issue tracker. If people didn’t act like such children in a place designed for productive conversation, then maybe the repo owners wouldn’t be so trigger happy.
Two years ago, I created a book in memory of a late friend to create a compilation of her posts on social media. Again, thanks to XSLT, it was a breeze.
XSLT has been orphaned on the browser-side for the last quarter century, but the story on the server-side isn't better either. I think that the only modern and comprehensive implementation comes with Saxon-JS which is bloated and has an unwieldy API for JavaScript.
Were XSLT dropped next year, what would be the course of action for us who rely on browser-based XSLT APIs?
XSLT, especially 3.0, is immensely powerful, and not having good solutions on JS ecosystem would make the aftermath of this decision look bleaker.
And if you’re leaning towards a declarative framework, use React.
Ex. https://source.chromium.org/chromium/chromium/src/+/main:thi...
https://source.chromium.org/chromium/chromium/src/+/main:thi...
https://github.com/WebKit/WebKit/blob/65b2fb1c3c4d0e85ca3902...
Mozilla has an in-house implementation at least:
https://github.com/mozilla-firefox/firefox/tree/5f99d536df02...
It seems like the answer to the compat issue might be the MathML approach. An outside vendor would need to contribute an implementation to every browser. Possibly taking the very inefficient route since that's easy to port.
My first job in software was as a software test development intern at a ~500 employee non-profit, in about 2008 when I was about 19 or 20 years old. Writing software to test software. One of my tasks during the 2 years I worked there was to write documentation for their XML test data format. The test data was written in XML documents, then run through a test runner for validation. I somehow found out about XSLT and it seemed like the perfect solution. So I wrote up XML schemas for the XML test data, in XSD of course. The documentation lived in the schema, alongside the type definitions. Then I wrote an XSLT document, to take in those XML schemas and output HTML pages, which is also basically XML.
So in effect what I wrote was an XML program, which took XML as input, and outputted XML, all entirely in the browser at document-view time.
And it actually worked and I felt super proud of it. I definitely remember it worked in our official browser (Internet Explorer 7, natch). I recall testing it in my preferred browser, Firefox (version 3, check out that new AwesomeBar, baby), and I think I got it working there, too, with some effort.
I always wonder what happened with that XML nightmare I created. I wonder if anyone ever actually used it or maybe even maintained it for some time. I guess it most likely just got thrown away wholesale during an inevitable rewrite. But I still think fondly back on that XSLT "program" even today.
I wrote my personal website in XML with XSLT transforming into something viewable in the browser circa 2008. I was definitely inspired by CSS Zen Garden where the same HTML gave drastically different presentation with different CSS, but I thought that was too restrictive with too much overly tricky CSS. I thought the code would be more maintainable by writing XSLT transforms for different themes of my personal website. That personal webpage was my version of the static site generator craze: I spent 80% of the time on the XSLT and 20% on the content of the website. Fond memories, even though I found XSLT to be incredibly difficult to write.
My first rewrite of my site, as I moved it away from Yahoo, into my own domain was also in XSLT/XML.
Eventually I got tired of keeping it that way, and rewrite the parsing and HTML generation into PHP, but kept the site content in XML, to this day.
Every now and then I think about rewriting it, but I rather do native development outside work, and don't suffer from either PHP nor XML allergies.
Doing declarative programming in XSLT was cool though.
At the end of the (very long) process, I just hard-coded the reference request XML given by the particularly problematic endpoints, put some regex replacements behind it, and called it a day.
Imagine people put energy into writing that thick of a book about XML. To be filed into the Theology section of a library
"Saxonica today counts some of the world's largest companies among its customer base. Several of the world's biggest banks have enterprise licenses; publishers around the world use Saxon as a core part of their XML workflow; and many of the biggest names in the software industry package Saxon-EE as a component of the applications they distribute or the services they deploy on the cloud."
So the libxml/libxslt unpaid volunteer maintainer wants to stop doing 'disclosure embargo' of reported security issues: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 Shortly after that, Google Chrome want to remove XSLT support.
Coincidence?
Source (yawaramin): https://news.ycombinator.com/item?id=44925104
PS: Seems libxslt which is used by Blink has an (unpaid) maintainer but nothing going on there really, seems pretty unmaintained https://gitlab.gnome.org/GNOME/libxslt/-/commits/master?ref_...
PS2: Reminds me all of this https://xkcd.com/2347/ A shame that libxml and libxslt could not get more support while used everywhere. Thanks for all the hard work to the unpaid volunteers!
It'd be much better that Google did support the maintainer, but given the apparent lack of use of XSLT 1.0 and the maintainer already having burned out, stopping supporting XSLT seems like the current best outcome:
> "I just stepped down as libxslt maintainer and it's unlikely that this project will ever be maintained again"
The suggestion of using a polyfill is a bit nonsensical as I suspect there is little new web being written in XSLT, so someone would have to go through all the old pages out there and add the polyfill. Anyone know if accomplishing XSLT is possible with a Chrome extension? That would make more sense.
Cool example with the recipes page :)
There are also very valid comments in there about why removal would still hurt existing sites and applications, especially for embedded devices.
https://github.com/whatwg/html/pull/11563#issuecomment-31970...
If there is a polyfill I'm not sure making it in Javascript makes sense but web assembly could work.
See the agenda here: https://github.com/whatwg/html/issues/11131#issuecomment-274...
Like 90%+ of internet traffic goes to a handful of sites owned by tech giants. Most of what's left is SEO garbage serving those same tech giants' ad networks.
But walled gardens like YouTube, Discord, ChatGPT and suchlike that are delivered via the browser are prospering. And as a cross platform GUI system, html is astonishingly popular.
I’m sure you can come up with more examples of extremely high value business which would not have happened without the web.
I agree RSS parsing is nice to have built into browsers. (Just like FTP support, that I genuinely miss in Firefox nowadays, but allegedly usage was too low to warrant the maintenance.) I also don't really understand the complaint from the Chrome people that are proposing it: "it's too complex, high-profile bugs, here's a polyfill you can use". Okay, why not stuff that polyfill into the browser then? Then it's already inside the javascript sandbox that you need to stay secure anyway, and everything just stays working as it was. Replacing some C++ code sounds like a win for safety any day of the week
On the other hand, I don't normally view RSS feeds manually. They're something a feed parser (in my case: Blogtrottr and Antennapod) would work with. I can also read the XML if there is a reason for me to ever look at that for some reason, or the server can transform the RSS XML into XHTML with the same XSLT code right? If it's somehow a big deal to maintain, and RSS is the only thing that uses it, I'm also not sure how big a deal it is to have people install an extension if they view RSS feeds regularly on sites where the server can do no HTML render of that information. It's essentially the same solution as if Chrome would put the polyfill inside the browser: the browser transforms the XML document inside of the JS sandbox
I think the principle behind it is wonderful. https://www.example.com/latest-posts is just an XML file with the pure data. It references an XSLT file which transforms that XML into a web page. But I've tried using it in the past and it was such a pain to work with. Representing things like for loops in markup is a fundamentally inefficient thing to do, JavaScript based templating is always going to win out from the developer experience viewpoint, especially when you're more than likely going to need to use JS for other stuff anyway.
It's one of those purist things I yearn for but can never justify. Shipping XML with data and a separate template feels so much more efficient than pre-prepared HTML that's endlessly repetitive. But... gzip also exists and makes the bandwidth savings a non-issue.
It may be that I don't notice when I use it, if the page just translates itself into XHTML and I would never know until opening the developer tools (which I do often, fwiw: so many web forms are broken that I have a habit of opening F12, so I always still have my form entries in the network request log). Maybe it's much more widespread than I knew of. I have never come across it and my job is testing third-party websites for security issues, so we see a different product nearly every week (maybe those sites need less testing because they're not as commonly interactive? I may have a biased view of course)
I think I've read some governments still use it, which would make sense since they usually don't have a super high budget for tons of developers, so they have to stick to the easy way to do things.
As much of a monopoly as Chrome is, if they actually try to remove it they're likely to get a bunch of government web pages outright stating "Chrome is unsupported, please upgrade to Firefox or something".
Which government or governmental organizations are you talking about?
[0] https://news.ycombinator.com/item?id=44909599
[1] https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih....
(but I take your point that there exists at least government in the world that uses it)
Practically every WordPress site with one of the top two SEO plugins (I'm not familiar with others) serves XML sitemaps with XSLT. It's used to make the XML contents human readable and to add a header explaining what it is.
Every (Wordpress) site with an SEO plugin should be fine, since the search engines can still read it and that's the goal of an SEO plugin
Especially considering the amount of complex standards they have qualms about from WebUSB to 20+ web components standards
> On the other hand, I don't normally view RSS feeds manually.
Chrome metrics famously underrepresent corporate installation. There could be quite a few corporate applications using XSLT as it was all the rage 15-20 years ago.
XSLT (and basically anything else that existed when HTML5 turned ten years old) is old code using old quality standards and old APIs that still need to be maintained. Browsers can rewrite them to be all new and modern, but it's a job very few people are interested in (and Google's internal structure heavily prioritizes developing new things over maintaining old stuff).
Nobody is making a promotion by modernizing the XSLT parser. Very few people even use XSLT in their day to day, and the biggest product of the spec is a competitor to at least three of the four major browser manufacturers.
XSLT is an example of exciting tech that failed. WebSerial is exciting tech that can still prove itself somehow.
The corporate installations still doing XSLT will get stuck running an LTS browser like they did with IE11 and the many now failed strains of technology that still supports (anyone remember ActiveX?).
You'd use XSLT to translate your data into a webpage. Or a mobile device that supported WML/WAP. Or a desktop application.
That was the dream, anyhow.
5G was another hype word. Can't say that's not useful! I don't really notice a difference with 4G (and barely with 3G) but apparently on the carrier side things got more efficient and it is very widely adopted
I guess there's a reason the Gartner hype cycle ends with widespread adoption and not with "dead and forgotten": most things are widely picked up for a reason. (Having said that, if someone can tell me what the unique selling point of an NFT was, I've not yet understood that one xD)
Which means more unreadable code.
But if they decide to remove XSLT from spec, I would be more than happy if they remove JS too. The same logic applies.
XSLT 1.0 is still useful though, and absolutely shouldn't be removed.
Them: "community feedback" Also them: <marks everything as off topic>
This came about after the maintainer of libxml2 found giving free support to all these downstream projects (from billionaire and trillionaire companies) too much.
Instead of just funding him, they have the gall to say they don't have the money.
While this may be true in a micocosm of that project, the devs should look at the broader context and who they are actually working for.
Here's what I wish could happen: allow implementers to stub out the XSLT engine and tell users who love it that they can produce a memory-safe implementation themselves if they want the functionality put back in. The passionate users and preservationists would get it done eventually.
I know that's not a good solution because a) new xslt engine code needs to be maintained and there's an ongoing cost for that for very few users, b) security reviews are costly for the new code, c) the stubs themselves would probably be nasty to implement, have security implications, etc. And, there's probably reasons d-z that I can't even fathom.
It sucks to have functionality removed/changed in the web platform. Software must be maintained though; cost of doing business. If a platform doesn't burden you with too much maintenance and chooches along day after day, then it's usually a keeper.
Google definitely throws its weight around too much w.r.t. to web standards, but this doesn't seem too bad. Web specifications are huge and complex so trying to size down a little bit while maintaining support for existing sites is okay IMO.
No it doesn't. An HTML page constructed with XSLT written 10 years ago will suddenly break when browsers remove XSLT. The webmaster needs to add the polyfill themselves. If the webmaster doesn't do that, then the page breaks.
From a user perspective, it only remains the same as before if the webmaster adopts the polyfill. From the web developer perspective, this is a breaking change that requires action. "shipping the polyfill" requires changes on many many sites - some of which have not needed to change in many years.
It may also be difficult to do. I'm not sure what their proposed solution is, but often these are static XML files that include an XSLT stylesheet - difficult to put JS in there.
That breaks old unmaintained but still valuable sites.
(But of course, XML Stylesheets are most widely used with RSS feeds, and Google probably considers further harm to the RSS ecosystem as a bonus. sigh)
Fortunately, Thunderbird still has support for feeds and doesn't seem to have been afflicted by the same malaise as the rest of the org chart. Who knows how long that will last.
I completely understand the security and maintenance burdens that they're bringing up but breaking sites would be unacceptable.
I don't understand the point in having a JS polyfill and then expecting websites to include it if they want to use XSLT stuff. The beauty of the web is that shit mostly just works going back decades, and it's led to all kinds of cool and useful bits of information transfer. I would bet money that so much of the weird useful XSLT stuff isn't maintained as much today - and that doesn't mean it's not content worth keeping/preserving.
This entire issue feels like it would be a nothing-burger if browser vendors would just shove the polyfill into the browser and auto-run it on pages that previously triggered the fear-inducing C++ code paths.
What exactly is the opposition to this? Even reading the linked issue, I don't see an argument against this that makes much sense. It solves every problem the browser vendors are complaining about and nothing functionally changes for end users.
That being said, I'm not against removing features but neither this or the original post provide any substantial rationale on why it should be removed. Uses for XSLT do exist and the alternative is "just polyfill it" which is awkward especially for legacy content.
With how bloated browsers are right now, good riddance IMO
Since it's a microcontroller, modifying that server and pushing the firmware update to users is probably also a pain.
Unusual use case, but an reasonable one.
Quite fun at the time
Removal of anything is problematic though, better off freezing parts of the spec to specific compatibility versions and getting browsers to ship optional compatibility modes that let you load and view old sites.
Yegge called it:
https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
"""
> Because I sometimes get similar letters from the Google Cloud Platform. They look like this:
>> Dear Google Cloud Platform User,
>> We are writing to remind you that we are sunsetting [Important Service you are using] as of August 2020, after which you will not be able to perform any updates or upgrades on your instances. We encourage you to upgrade to the latest version, which is in Beta, has no documentation, no migration path, and which we have kindly deprecated in advance for you.
>> We are committed to ensuring that all developers of Google Cloud Platform are minimally disrupted by this change.
>> Besties Forever,
>> Google Cloud Platform
> But I barely skim them, because what they are really saying is:
>> Dear RECIPIENT,
>> Fuck yooooouuuuuuuu. Fuck you, fuck you, Fuck You. Drop whatever you are doing because it’s not important. What is important is OUR time. It’s costing us time and money to support our shit, and we’re tired of it, so we’re not going to support it anymore. So drop your fucking plans and go start digging through our shitty documentation, begging for scraps on forums, and oh by the way, our new shit is COMPLETELY different from the old shit, because well, we fucked that design up pretty bad, heh, but hey, that’s YOUR problem, not our problem.
>> We remain committed as always to ensuring everything you write will be unusable within 1 year.
>> Please go fuck yourself,
>> Google Cloud Platform
"""
Almost no one ever uses it: metrics show only around 0.02% of phone calls use this feature. So we’re planning on deprecating and then removing it.
—⁂—
Just an idea that occurred to me earlier today. XSLT doesn’t get a lot of use, but there are still various systems, important systems, that depend upon it. Links to feeds definitely want it, but it’s not just those sorts of things.
Percentages only tell part of the story. Some are tiny features that are used everywhere, others are huge features that are used in fewer places. Some features can be removed or changed with little harm—frankly, quite a few CSS things that they have declined to address on the grounds of usage fall into this category, where a few things would be slightly damaged, but nothing would be broken by it. Other features completely destroy workflows if you change or remove them—and XSLT is definitely one of these.
I know this is for security reason but why not update the XSLT implementation instead. And if feature that aren't used get dropped, they might as well do it all in one good. I am sure lots of HTML spec aren't even used.
I am of the opinion that it is to remove one of the last ways to build web applications that don't have advertising and tracking injected into them.
Er, how so? What stops you from doing so in HTML/JS/CSS ?
Google is boneheaded and hostile to open web at this point, explicitly.
Go changed their telemetry to opt-in based on community feedback, so I'm not sure what point you're trying to make with that example.
I spent days in that thread. That uproar was “a bunch of noisy minority which doesn’t worth listening” for them.
The GitHub discussion is there: https://github.com/golang/go/discussions/58409
but the words I of Russ I cited is here: https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/WKj7p...
Copying verbatim:
It's good to know that's what it looks like. I can tell you that the shouting did not really influence the decision. Long-time Go contributors and supporters commenting quietly or emailing me privately had far greater influence.
Probably a browser extension on the user side can do the same job if an XSLT relying page cannot be updated.
And browsers are too big with too many features; reducing the scope of what a browser does is good (but not enough by itself to remove a feature).
Maybe one day it will come back as a black-box module running in an appropriate sandbox - like I think Firefox uses for PDF rendering.
At least that's how my cynical side feels anymore.
I remember using these things in a CSCI class, and, IIRC, we were using something akin to Tomcat to do transformations on the server, before serving HTML to the browser, circa 2005/2006.
XSLT came across as a little esoteric.
I think that's a tradeoff.
Simplest approach would be to just distribute programs, but the Web is more than that!
Another simple approach would be to have only HTML and CSS, or even only HTML, or something like Markdown, or HTML + a different simple styling language...
and yet nothing of that would offer the features that make web development so widespread as a universal document and application platform.
But like, most people just want a site to work and provide value, save them time etc and the way the site is built is entirely unimportant. I find myself moving towards that side despite being somewhat of a web purist for years.
[0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
The W3C's plan was for HTML4 to be replaced by XHTML. What we commonly call HTML5 is the WHATWG "HTML Living Standard."
no wonder they were sidelined
Which Chrome has transmuted into "we do whatever we want to do". Remember their attempt to remove confirm/prompt?
How do you apply this to documents? They are so different. XML gives the answer: you INVENT a notation that suits just your case and use it. This way you perfectly solve the enigma of semantic.
OK, fine, but what to do with my invented notation? Nobody understands it. Well, that is OK. You want to render it as HTML; HTML has no idea about you notation, but is (was) also a kind of XML, so you write a transformation from your notation to HTML. Now you want to render it for printed media: here is XSL-FO, go ahead. Or maybe you want to let blind people read your document too; here is (a non-existent) AUDIO-ML, just add a transformation into this format. In fact there could be lots of different notations for different purposes (search, for instance) and they are all within a single transformation step.
And for that transformation we give you a tool: XSLT.
(I remember a piece discussed here; it was about different languages and one of examples of very simple languages was XSLT. It is my impression as well; XSLT is unconventional, but otherwise very simple.)
Of course you do not have to invent a new notation each time. It's equally fine to invent small specific notations and mix them with yours.
For example, imagine a specific chess notation. It allows you to describe positions and a sequence of moves, giving you either a party or a composition. You write about chess and add snippets in this notation. First, it can be very expressive; referring to a position should take no more than:
<position party="#myparty" move="22w" />
<moves party="#myparty" from="22w" to "25b" />
And then imagine a specific search engine that crawls the web, indexes parties and compositions and then can search, for example, for other pages that discuss this party, or for similar positions, or for matching sequences of moves.
XML even had a foundation to incorporate other notations. XML itself is, indeed, verbose (although this can be lessened with a good design, which is rare), but starting from v1.0 it has a way to formally indicate that contents of an element are written in a specific notation. If that direction was followed it could lead to things like:
<math notation="latex">...</math> <math notation="asciimath">...</math>
The vision of XML was federated web. Lots of notations, big and small, evolving and mixing. It was dismissed on the premise it was too strict. I myself think it was too free.
Nothing is stopping you from using content negotiation to do it server side.