[HN Gopher] Removing XSLT for a more secure browser
___________________________________________________________________
Removing XSLT for a more secure browser
Author : justin-reeves
Score : 157 points
Date : 2025-11-05 14:14 UTC (8 hours ago)
(HTM) web link (developer.chrome.com)
(TXT) w3m dump (developer.chrome.com)
| righthand wrote:
| Destroying the open web instead of advocating to fix one of the
| better underutilized browser technologies for a more Profitable
| Google.
|
| I will not forget the name Mason Freed, destroyer of open
| collaborative technology.
| tptacek wrote:
| Didn't this effort start with Mozilla and not Google? I think
| you will in fact forget the name Mason Freed, just like most of
| us forgot about XSLT.
| simoncion wrote:
| > Didn't this effort start with Mozilla and not Google?
|
| Maybe round one of it like ten years ago did? From what I
| understand, it's a Google employee who opened the "Hey, I
| want to get rid of this and have no plans to provide a zero-
| effort-for-users replacement." Github Issue a few months
| back.
| JimDabell wrote:
| > 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.
|
| -- https://news.ycombinator.com/item?id=44953349
| simoncion wrote:
| I don't see any evidence of that claim from the materials
| I have available to me. [0] is the Github Issue I
| mentioned. [1] is the WHATNOT meeting notes linked to
| from that GH Issue... though I have no idea who smaug is.
|
| [0] <https://github.com/whatwg/html/issues/11523>
|
| [1] <https://github.com/whatwg/html/issues/11146#issuecom
| ment-275...>
| JimDabell wrote:
| Smaug is the Mozilla engineer they were talking about:
|
| https://github.com/smaug----
| simoncion wrote:
| Ah, that was my problem... I didn't put enough minuses
| after the nickname. ;)
| tptacek wrote:
| You can remember their name forever now!
| simoncion wrote:
| You appear to have forgotten how to scroll up and notice
| that the name of the OP is not my name. ;)
| tptacek wrote:
| No, I know, I'm just being silly. Sorry, I didn't mean to
| attribute that sentiment to you.
| righthand wrote:
| Hilarious, thanks. Sorry you have issues with memory.
| indolering wrote:
| It started with Mozilla, Apple, and Opera jumping ship and
| forming WHATWG. That stopped new XML related technologies
| from being adopted in browsers twenty years ago. Google is
| just closing the casket and burying the body.
| righthand wrote:
| Why would I forget about XSLT a really good technology pushed
| to the wayside by bad faith actors? Why would I forget Mason
| Freed? A person dedicating themselves to ruining perfectly
| good technology that needs a little love.
|
| Do you have some sort of exclusive short term memory or
| something where you can't remember someone's name? Bizarre
| reply. Other people may have had a similarly lazy idea, but
| Mason is the one pushing and leading the charge.
|
| It seems maybe you want me to blame this on Google as a whole
| but that would mean bypassing blame and giving into their
| ridiculous bs.
| tptacek wrote:
| https://www.youtube.com/watch?v=1NqLGp6qRuU
| dfabulich wrote:
| Blame Apple and Mozilla, too, then. They all agreed to remove
| it.
|
| They all agreed because XSLT is extremely unpopular and worse
| than JS in every way. Performance/bloat? Worse. Security? MUCH
| worse. Language design? Unimaginably worse.
|
| EDIT: I wrote thousands of lines of XSLT circa 2005. I'm
| grateful that I'll never do that again.
| stickfigure wrote:
| This is only repeated by people who have never used it.
|
| XSLT is still a great way of easily transforming xml-like
| documents. It's orders of magnitude more concise than
| transforming using Javascript or other general programming
| languages. And people are actively re-inventing XSLT for JSON
| (see `jq`).
| mschuster91 wrote:
| I actually do have to work with raw XML and XSLTs every
| once in a while for a java-based CMS and holy hell, it's
| nasty.
|
| Java in general... Maven, trying to implement extremely
| simple things in Gradle (e.g. only execute a specific Thing
| as part of the pipeline when certain conditions are met) is
| an utter headache to do in the pom.xml because XML is not a
| programming language!
| stickfigure wrote:
| It is an unfortunate fact about our industry that all
| build tools suck. Tell me what your favorite build tool
| is and I can point at hundreds of HN threads ripping it
| to shreds. Maybe it's NPM? Cue the screams...
|
| I agree though, "XML is not a programming language" and
| attempts to use it that way have produced poor results.
| You should have seen the `ant` era! But this is broader
| than XML - look at pretty much every popular CI system
| for "YAML is not a programming language".
|
| That doesn't mean that XML isn't useful. Just not as a
| programming language.
| mschuster91 wrote:
| > It is an unfortunate fact about our industry that all
| build tools suck. Tell me what your favorite build tool
| is and I can point at hundreds of HN threads ripping it
| to shreds. Maybe it's NPM? Cue the screams...
|
| npm isn't even a build tool, it's a package manager and
| at that it's actually gotten quite decent - the fact that
| the JS ecosystem at large doesn't give a fuck about
| respecting semantic versioning or keeps reinventing the
| wheel or that NodeJS / JavaScript itself lacks a decent
| standard library aren't faults of npm ;)
|
| Maven and Gradle in contrast are one-stop-shops, both
| build orchestrators and dependency managers. As for ant,
| oh hell yes I'm aware of that. The most horrid build
| system I encountered in my decade worth of tenure as "the
| guy who can figure out pretty much _any_ nuclear
| submarine project (aka, only surfaces every few years
| after everyone working on it departed) " involved Gradle,
| which then orchestrated Maven and Ant, oh and the project
| was built on a Jenkins that was half DSL, half clicked
| together in the web UI, and the runner that executed the
| builds was a manually set up, "organically grown" server.
| That one was a holy damn mess to understand, unwind,
| clean up and migrate to Gitlab.
|
| > look at pretty much every popular CI system for "YAML
| is not a programming language".
|
| Oh yes... I only had the misfortune of having to code for
| Github Actions once in my life time, it's utter fucking
| madness compared to GitLab.
| dfabulich wrote:
| But, that's what XSL is! XSL is a Turing-complete
| programming language in XML for processing XML documents.
| Being in XML is a big part of what makes XSL so awful to
| write.
| stickfigure wrote:
| XSL may be Turing-complete but it's not a programming
| language and wasn't intended to be one. It's a
| declarative way to transform XML. When used as such I
| never found it awful to write... it's certainly much
| easier than doing the equivalent in general purpose
| programming languages.
|
| Maybe by analogy: There are _type systems_ that are
| Turing complete. People sometimes abuse them to humorous
| effect to write whole programs (famously, C++ templates).
| That doesn 't mean that type systems are bad.
| DonHopkins wrote:
| "Java is a big DSL to transform XML into stacktraces"
|
| https://news.ycombinator.com/item?id=26663191
|
| XSLT (or ANT) may be Turing complete, but it's firmly
| embedded in the Turing Tarpit.
|
| https://en.wikipedia.org/wiki/Turing_tarpit
|
| >"54. Beware of the Turing tar-pit in which everything is
| possible but nothing of interest is easy." -Alan Perlis
| garethrowlands wrote:
| I used to use XSLT a lot, though it was a while ago.
|
| You can use Javascript to get the same effect and, indeed,
| write your transforms in much the same style as XSLT.
| Javascript has xpath (still). You have a choice of template
| language but JSX is common and convenient. A function for
| applying XSLT-style matching rules for an XSLT push style
| of transform is only a few lines of code.
|
| Do you have a particular example where you think Javascript
| might be more verbose than XSLT?
| silon42 wrote:
| How is it worse than JS? It's a different thing...
| dfox wrote:
| > Security? MUCH worse.
|
| Comparing single-purpose declarative language that is not
| even really turing-complete with all the ugly hacks needed to
| make DOM/JS reasonably secure does not make any sense.
|
| Exactly what you can abuse in XSLT (without non-standard
| extensions) in order to do anything security relevant? (DoS
| by infinite recursion or memory exhaustion does not count,
| you can do the same in JS...)
| exasperaited wrote:
| Are the security concerns not about libxslt, rather than
| XSLT?
| dfabulich wrote:
| If you would RTFA, they're removing XSLT specifically for
| security reasons. They provide the following links:
|
| https://www.offensivecon.org/speakers/2025/ivan-
| fratric.html
|
| > _Although XSLT in web browsers has been a known attack
| surface for some time, there are still plenty of bugs to be
| found in it, when viewing it through the lens of modern
| vulnerability discovery techniques. In this presentation,
| we will talk about how we found multiple vulnerabilities in
| XSLT implementations across all major web browsers. We will
| showcase vulnerabilities that remained undiscovered for 20+
| years, difficult to fix bug classes with many variants as
| well as instances of less well-known bug classes that break
| memory safety in unexpected ways. We will show a working
| exploit against at least one web browser using these bugs._
|
| https://nvd.nist.gov/vuln/detail/CVE-2025-7425
|
| https://nvd.nist.gov/vuln/detail/CVE-2022-22834
|
| (And, for the record, XSL _is_ Turing-complete. It has
| xsl:variable, xsl:if, xsl:for-each, and xsl:apply-template
| function calls.)
| righthand wrote:
| They did not agree to remove it. This is a spun lie from the
| public posts I can see. They agreed to explore removing it
| but preferred to keep it for good reasons.
|
| Only Google is pushing forward and twisting that message.
| JimDabell wrote:
| > They did not agree to remove it. This is a spun lie from
| the public posts I can see. They agreed to explore removing
| it but preferred to keep it for good reasons.
|
| Mozilla:
|
| > Our position is that it would be good for the long-term
| health of the web platform and good for user security to
| remove XSLT, and we support Chromium's effort to find out
| if it would be web compatible to remove support.
|
| -- https://github.com/mozilla/standards-
| positions/issues/1287#i...
|
| WebKit:
|
| > WebKit is cautiously supportive. We'd probably wait for
| one implementation to fully remove support, though if
| there's a known list of origins that participate in a
| reverse origin trial we could perhaps participate sooner.
|
| -- https://github.com/whatwg/html/issues/11523#issuecomment
| -314...
|
| Describing either of those as "they preferred to keep it"
| is blatantly untrue.
| righthand wrote:
| So you're choosing to help them spin the lie by cherry
| picking comments.
|
| The Mozilla comment itself ends with:
|
| > If it turns out that it's not possible to remove
| support, then we think browsers should make an effort to
| improve the fundamental security properties of XSLT even
| at the cost of performance.
|
| > If it turns out not to be possible to remove the
| feature, we'd like to replace our current implementation.
| The main requirements would be compatibility with
| existing web content, addressing memory safety security
| issues, and not regressing performance on non-XSLT
| content. We've seen some interest in sandboxing libxslt,
| and if something with that shape satisfied our normal
| production requirements we would ship it.
|
| But the only way it's possible to remove the feature is
| if you ignore everyone asking you to please not to remove
| it.
|
| Therefor by totally ignoring push back you can then twist
| Mozilla reps words to mean the only option is to remove
| it.
|
| Similarly with the Webkit comment:
|
| > WebKit is cautiously supportive.
|
| Both these orgs requested investigation not removal. Both
| expressed some concern and caution. Google did not, they
| only ever pushed forward with removing it. Even goong so
| far as to ignore the followup request to implement XSLT
| 3.0.
|
| No it's not blatantly untrue. It's unblatantly
| misleading.
|
| Furthermore I'd say for those specific comments, "go
| ahead and remove it", the inverse is blatantly untrue.
| cxr wrote:
| > They all agreed to remove it.
|
| All those people suck, too.
|
| Were you counting on a different response?
|
| > XSLT is extremely unpopular and worse than JS in every way
|
| This isn't a quorum of folks torpedoing a proposed standard.
| This is a decades-old stable spec and an established part of
| the Web platform, and welching on their end of the deal will
| break things, contra "Don't break the Web".
| shadowgovt wrote:
| You can continue to use XSLT server-side to emit HTML if
| you are deeply, deeply concerned about the technology.
| cxr wrote:
| _Do you still beat your wife?_ <https://en.wikipedia.org/
| wiki/Do_you_still_beat_your_wife?>
| shadowgovt wrote:
| I don't think that applies here (especially since I
| didn't even ask a question).
|
| "I'm sad it's going away in the client!"
|
| "So move it to the server, and the end-user will get
| essentially the same experience."
|
| Am I missing something here?
| rvz wrote:
| > Destroying the open web instead of advocating to fix one of
| the better underutilized browser technologies for a more
| Profitable Google.
|
| Google, Mozilla and Apple do not care if it doesn't make them
| money, unless you want to pay them billions to keep that
| feature?
|
| > I will not forget the name Mason Freed, destroyer of open
| collaborative technology.
|
| This is quite petty.
| righthand wrote:
| So is blatantly ignoring pushback against removing a feature
| like this. Eye for an eye.
| lenkite wrote:
| "Removing established open standards for a more walled garden" ->
| Fixed
| HunOL wrote:
| So XPath locators won't be available in Playwright and Selenium
| in Chrome? This could be huge for QA and RPA.
| rhdunn wrote:
| They are still keeping the XPath APIs so XPath locators will
| still work.
| tclancy wrote:
| I know it makes me an old and I am biased because one of the
| systems in my career I am most proud of I designed around XSLT
| transformations, but this is some real bullshit and a clear case
| why a private company should not be the de facto arbiter of web
| standards. Have a legacy system that depends on XSLT in the
| browser? Sucks to be you, one of our PMs decided the cost-benefit
| just wasn't there so we scrapped it. Take comfort in the fact our
| team's velocity bumped up for a few weeks.
|
| And yes I am sour about the fact as an American I have to hope
| the EU does something about this because I know full-well it's
| not happening here in The Land of the Free.
| socalgal2 wrote:
| Good, XSLT was crap. I wrote an RSS feed XSLT template. Worst dev
| experience ever. No one is/was using XSLT. Removing unused code
| is a win for browsers. Every anti bloat HNer should be cheering
| gdwatson wrote:
| The first few times you use it, XSLT is _insane_. But once
| something clicks, you figure out the kinds of things it's good
| for.
|
| I am not really a functional programming guy. But XSLT is a
| really cool application of functional programming for data
| munging, and I wouldn't have believed it if I hadn't used it
| enough for it to click.
| exasperaited wrote:
| Right. I didn't use it much on the client side so I am not
| feeling this particular loss so keenly.
|
| But server side, many years ago I built an entire CMS with
| pretty arbitrary markup regions that a designer could declare
| (divs/TDs/spans with custom attributes basically) in XSLT
| (Sablotron!) with the Perl binding and a customised build of
| HTML Tidy, wrapped up in an Apache RewriteRule.
|
| So designers could do their thing with dreamweaver or golive,
| pretty arbitrarily mark up an area that they wanted to be
| customisable, and my CMS would show edit markers in those
| locations that popped up a database-backed textarea in a
| popup.
|
| What started off really simple ended up using Sablotron's URL
| schemes to allow a main HTML file to be a master template for
| sub-page templates, merge in some dynamic functionality etc.
|
| And the thing would either work or it wouldn't (if the HTML
| couldn't be tidied, which was easy enough to catch).
|
| The Perl around the outside changed very rarely; the XSLT
| stylesheet was fast and evolved quite a lot.
| garethrowlands wrote:
| XSLT's matching rules allow a 'push' style of transform
| that's really neat. But you can actually do that with any
| programming language such as Javascript.
| johannes1234321 wrote:
| > Every anti bloat HNer should be cheering
|
| Actually a transformation system can reduce bloat, as people
| don't have to write their own crappy JavaScript versions of it.
|
| Being XML the syntax is a bit convoluted, but behind that is a
| good functional (in sense of functional programming language,
| not functioning) system which can be used for templating etc.
|
| The XML made it a bit hard to get started and anti-XML-spirit
| reduced motivation to get into it, but once you know it, it
| beats most bloaty JavaScript stuff in that realm by a lot.
| nolok wrote:
| > No one is/was using XSLT.
|
| Ah, when ignorance leads to arrogance; It is massively utilised
| by many large entreprise or state administration in some
| countries.
|
| Eg if you're american the library of congress uses it to show
| all legislative text.
| basscomm wrote:
| I'm always puzzled by statements like this. I'm not much of a
| programmer and I wrote a basic XSLT document to transform
| rss.xml into HTML in a couple of hours. I didn't find it very
| hard at all (anecdotes are not data, etc)
| jerf wrote:
| This has been chewed on _ad nauseum_ on HN already, to the point
| I won 't even try to make a list of the articles but just link a
| search result:
| https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...
| lolive wrote:
| KPIs of the hottest languages on the web show that XSLT has
| become hotter that Java and C++ in the last days. XML is back,
| dudes!
| QuadrupleA wrote:
| TIL: Chrome supports XSLT.
|
| Good riddance I guess - it and most of the tech from the "XML
| era" was needlessly overcomplicated.
| exasperaited wrote:
| XSLT is really powerful and it is declarative, like CSS, but
| can both push and pull.
|
| It's a loss, if you ask me, to remove it from client-side, but
| it's one I worked through years ago.
|
| It's still really useful on the server side for document
| transformation.
| QuadrupleA wrote:
| Imagine a WASM XSLT interpreter wouldn't be to hard to
| compile?
| afandian wrote:
| TFA mentions polyfills and libraries.
| afandian wrote:
| Perhaps, but isn't the contemporary tech stack orders of
| magnitude more complicated? Doesn't feel like a strong
| motivating argument.
| cxr wrote:
| Your response is like seeing the cops going to the wrong house
| to kick in your neighbors door, breaking their ornaments in
| their entry way, and then saying to yourself, "Good. I hate
| yellow, and would never have any of that tacky shit in my
| house."
|
| As your first sentence of your comment indicates, the fact that
| it's supported and there for people to use doesn't (and hasn't)
| result in _you_ being forced to use it in your projects.
| QuadrupleA wrote:
| Yes but software, and especially browser, complexity has
| balooned enormously over the years. And while XSLT probably
| plays a tiny part in that, it's likely embedded in every
| Electron app that could do in 1MB what it takes 500 MB to do,
| makes it incrementally harder to build and maintain a
| competing browser, etc., etc. It's not zero cost.
|
| I do tend to support backwards compatibility over constant
| updates and breakage, and needless hoops to jump through as
| e.g. Apple often puts its developers through. But having
| grown up and worked in the overexuberant XML-for-everything,
| semantic-web 1000-page specification, OOP
| AbstractFactoryTemplateManagerFactory era, I'm glad to put
| some of that behind us.
|
| If that makes me some kind of gestappo, so be it.
| lenkite wrote:
| Remove crappy JS APIs and other web-tech first before
| deprecating XSLT - which is a true-blue public standard.
| For folks who don't enable JS and XML data, XSLT is a life-
| saver.
| WorldMaker wrote:
| If we're talking about removing things for security
| security, the ticking time bomb that is WebUSB seems top
| of the list to me of things that are dangerous, not
| actually standards (it is Chrome only), and yet a bunch
| of websites think it's a big, good reason to be Chrome-
| only.
| cxr wrote:
| Point to the part of your comment that has any-fucking-
| thing to do with the topic at hand (i.e. engages with the
| actual substance of the comment that it's posted as a reply
| to). Your comment starts with "Yes but", and then proceeds
| into total non-sequitur, presented as if it's a rebuttal or
| rejoinder to something. This is misdirection.
|
| Your neighbors' ugly yellow tchotchkes have in _no way_
| forced you--nor will they ever force you--to ornament your
| house with XSLT printouts.
| jtvjan wrote:
| That's upsetting. Being able to do templating without using
| JavaScript was a really cool party trick.
|
| I've used it in an unfinished website where all data was stored
| in a single XML file and all markup was stored in a single XSLT
| file. A CGI one-liner then made path info available to XSLT, and
| routing (multiple pages) was achieved by doing string tests
| inside of the XSLT template.
| sangeeth96 wrote:
| To those who saw a chrome.com link and got triggered:
|
| > The Firefox[^0] and WebKit[^1] projects have also indicated
| plans to remove XSLT from their browser engines.
|
| [^0]: https://github.com/mozilla/standards-
| positions/issues/1287#i...
|
| [^1]:
| https://github.com/whatwg/html/issues/11523#issuecomment-314...
| righthand wrote:
| In my opinion this is not "we agree lets remove it". This is
| "we agree to explore the idea".
|
| Google and Freed using this as a go ahead because the Mozilla
| guy pasted a pollyfill. However it is very clearly NOT an
| endorsement to remove it, even though bad actors are stating
| so.
|
| > Our position is that it would be good for the long-term
| health of the web platform and good for user security to remove
| XSLT, and we support Chromium's effort to find out if it would
| be web compatible to remove support1. If it turns out that it's
| not possible to remove support, then we think browsers should
| make an effort to improve the fundamental security properties
| of XSLT even at the cost of performance.
|
| Freed et al also explicitly chose to ignore user feedback for
| their own decision and not even try to improve XSLT security
| issues at the cost of performance.
| TingPing wrote:
| Last I heard for WebKit removing it was the only outcome they
| saw.
| righthand wrote:
| Yeah all these billion dollar corporations that can't be
| bothered see it as the only path forward not because of
| technological or practical issues, but because none of them
| can be asked to give a shit and plan it into their budgets.
|
| They're MBAs who only know how to destroy and consolidate
| as trained.
| TingPing wrote:
| I get the frustration but I don't believe that's really
| accurate. It's not widely used and modern developers
| don't see it as valuable.
| righthand wrote:
| I'm a modern developer and I see it as valuable. Why side
| with the browser teams and ignoring user feedback?
|
| If "modern developers" actually spent time with it,
| they'd find it valuable. Modern developers are idiots if
| their constant cry is "just write it in JS".
|
| No idea what's inaccurate about this. A billion dollar
| company that has no problem pivoting otherwise, can't
| fund open technology "because budgets" is simply a lie.
| shadowgovt wrote:
| The dominant user feedback is the hard statistics on how
| rarely it's used.
|
| You can't trim the space of "users" to just "people who
| already adopted the technology" in the context of the
| cost of browser support.
| dpark wrote:
| "Everyone who uses the blink tag agrees it's critical
| functionality."
| righthand wrote:
| Yes excellent way to continue to diminish users of tech
| you don't agree with.
|
| "The people who actually use it are wrong and don't
| matter!"
| shadowgovt wrote:
| I'm not personally in the business of maintaining a
| browser.
|
| But if I were, and I were looking to decrease cost of
| maintenance, "This entire rendering framework that
| supports a 0.02% use case" would be an outlier for
| chopping-block consideration. Not all corner-case
| features match that combination of cost-to-maintain and
| adoption (after, what, decades at this point?).
|
| We wouldn't be arguing the point if the feature in
| question were fax machine support, right?
| exasperaited wrote:
| XSLT in the browser was left fundamentally
| underdeveloped, which is why it is not really widespread.
|
| XSLT in non-browser contexts is _absolutely_ valuable.
| ForHackernews wrote:
| Pour one out for @vgr-land
| https://news.ycombinator.com/item?id=45006098
| sherinjosephroy wrote:
| Nice find -- interesting to see browsers moving to drop XSLT
| support. I used XSLT once for a tiny site and it felt like magic
| --templating without JavaScript was freeing. But maybe it's just
| niche now, and browser vendors see more cost than payoff.
|
| Curious: have any of you used XSLT in production lately?
| rhdunn wrote:
| Yes. It's used heavily in the publishing and standards
| industries that store the documents in JATS and other XML-based
| formats.
|
| Because browsers only support XSLT 1.0 the transform to HTML is
| typically done server side to take advantage of XSLT 2.0 and
| 3.0 features.
|
| It's also used by the US government:
|
| 1. https://www.govinfo.gov/bulkdata/BILLS
|
| 2. https://www.govinfo.gov/bulkdata/FR/resources
| Devasta wrote:
| I lead a team that manage trade settlements for hedge funds;
| data is exported from our systems as XML and then transformed
| via XSLT into whatever format the prime brokers require.
|
| All the transformed are maintained by non-developers, business
| analysts mainly. Because the language is so simple we don't
| need to give them much training, just get IntelliJ installed on
| their machine, show them a few samples and let them work away.
|
| We couldn't have managed with anything else.
| creatonez wrote:
| XSLT is complete and utter garbage. Good riddance.
| MarsIronPI wrote:
| To anyone who says to use JS instead of XSLT: I block JS because
| it is also used for ads, tracking and bloat in general. I don't
| block XSLT because I haven't come across malicious use of XSLT
| before (though to be fair, I haven't come across much use of XSLT
| at all).
|
| I think being able to do client-side templating without JS is an
| important feature and I hope that since browser vendors are
| removing XSLT they will add some kind of client-side templating
| to replace it.
| Aurornis wrote:
| > I block JS
|
| The percentage of visitors who block JS is extremely small.
| Many of those visits are actually bots and scrapers that don't
| interpret JS. Of the real users who block JS, most of them will
| enable JS for any website they actually want to visit if it's
| necessary.
|
| What I'm trying to say is that making any product decision for
| the extremely small (but vocal) minority of users who block JS
| is not a good product choice. I'm sorry it doesn't work for
| your use case, but having the entire browser ecosystem cater to
| JS-blocking legitimate users wouldn't make any sense.
| davisr wrote:
| I block JS, too. And so does about 1-2% of all Web users.
| JavaScript should NOT be REQUIRED to view a website. It makes
| web browsing more insecure and less private, makes page load
| times slower, and wastes energy.
| dpark wrote:
| > And so does about 1-2% of all Web users.
|
| To put that in context, about 6 percent of US homes have no
| internet access at all. The "I turn off JS" crowd is at
| least 3x smaller than the crowd with no access at all.
|
| The JS ship sailed years ago. You can turn it off but a
| bunch of things simply will not work and no amount of
| insisting that it would not be required will change that.
| kstrauser wrote:
| Without saying whether I think that's a good or bad
| thing, as a practical matter, I 100% agree. Approximately
| no major websites spend any effort whatsoever supporting
| non-JS browsers today. They probably put that in the
| class of text only browsers, or people who override all
| CSS: "sure, visitors can do that, but if they've altered
| their browser's behavior then what happens afterward is
| on them."
|
| And frankly, from an economic POV, I can't blame them.
| Imagine a company who write a React-based website. (And
| again, I'm not weighing in on the goodness or badness of
| that.) Depending on how they implemented it, supporting a
| non-JS version may literally require a second, parallel
| version of the site. And for what, to cater to 1-2% of
| users? "Hey boss, can we triple our budget to serve two
| versions of the site, kept in lockstep and feature
| identical so that visitors don't scream at us, to pick up
| an extra 1% or 2% of users, who by definition are very
| finicky?" Yeah, that's not happening.
|
| I've launched dozens of websites over the years, all of
| them using SSR (or HTML templates as we called them back
| in the day). I've personally never written a JavaScript-
| native website. I'm not saying the above because I built
| a career on writing JS or something. And despite that, I
| completely understand why devs might refuse to support
| non-JS browsers. It's a lot of extra work, it means they
| can't use the "modern" (React launched in 2013) tools
| they're use to, and all without any compelling financial
| benefit.
| davisr wrote:
| I'm hearing you say, "don't waste your breath because
| change is not possible." And there you have your self-
| fulfilling prophecy.
|
| To quote someone who lived before me: don't accept the
| things you cannot change. Change the things you cannot
| accept.
|
| And the no-JS ship has not sailed. Government websites
| require accessibility, and at least in the UK, do not
| rely on JS.
| dpark wrote:
| Then you misheard me.
|
| I'm not saying change is not possible. I'm saying the
| change you propose is misguided. I do not believe the
| entire world should abandon JS to accommodate your
| unusual preferences nor should everyone be obliged to
| build two versions of their site, one for the masses and
| one for those with JS turned off.
|
| Yes, JS is overused. But JS also brings significant real
| value to the web. JS is what has allowed websites to
| replace desktop apps in many cases.
| davisr wrote:
| Did I say abandon? No. I said it should not be required.
| JavaScript should be supplementary to a page, but not
| necessary to view it. This was its original intent.
|
| > JS is what has allowed websites to replace desktop apps
| in many cases.
|
| Horribly at that, with poorer accessibility features,
| worse latency, abused visual style that doesn't match the
| host operating system, unusable during times of net
| outages, etc, etc.
| dpark wrote:
| > JavaScript should be supplementary to a page, but not
| necessary to view it.
|
| I'm curious. Do Google Maps, YouTube, etc even work with
| JS off?
|
| > This was its original intent.
|
| Original intent is borderline irrelevant. What matters is
| how it is actually used and what value it brings.
|
| > Horribly at that
|
| I disagree. You say you turn JS off for security but JS
| has made billions of people more secure by creating a
| sandbox for these random apps to run in. I can load up a
| random web app and have high confidence that it can't
| muck with my computer. I can't do the same with random
| desktop apps.
| davisr wrote:
| > I'm curious. Do Google Maps, YouTube, etc even work
| with JS off?
|
| I use KDE Marble (OpenStreetMap) and Invidious. They work
| fine.
|
| > Original intent is borderline irrelevant. What matters
| is how it is actually used and what value it brings.
|
| And that's why webshit is webshit.
|
| > I can't do the same with random desktop apps.
|
| I can, and besides the point, why should anyone run
| random desktop apps? (Rhetorical question, they
| shouldn't.) I don't run code that I don't trust. And I
| don't trust code that I can't run for any purpose, read,
| study, edit, or share. I enforce this by running a
| totally-free (libre) operating system, booted with a
| totally-free BIOS, and installing and using totally-free
| software.
| dpark wrote:
| > I use KDE Marble (OpenStreetMap) and Invidious. They
| work fine.
|
| So no. Some major websites don't actually work for you.
|
| > And that's why webshit is webshit.
|
| I don't understand this statement. Webshit is webshit
| because the platform grew beyond basic html docs? At some
| point this just feels like hating on change. The web grew
| beyond static html just like Unix grew beyond terminals.
|
| > I don't run code that I don't trust. And I don't trust
| code that I can't run for any purpose, read, study, edit,
| or share. I enforce this by running a totally-free
| (libre) operating system, booted with a totally-free
| BIOS, and installing and using totally-free software.
|
| If this is the archetype of the person who turns off JS
| then I would bet the real percentage is _way_ less than
| 1%.
| nagaiaida wrote:
| > You say you turn JS off for security but JS has made
| billions of people more secure by creating a sandbox for
| these random apps to run in.
|
| is "every website now expects to run arbitrary code on
| the client's computer" really a more secure state of
| affairs? after high profile hardware vulnerabilities
| exploitable even from within sandboxed js?
|
| from how many unique distributors did the average person
| run random untrusted apps that required sandboxing before
| and after this became the normal way to deliver a purely
| informational website and also basically everything
| started happening online?
| dpark wrote:
| People used to download way more questionable stuff and
| run it. Remember shareware? Remember Sourceforge?
| (Remember also how Sourceforge decided to basically
| inject malware that time?)
|
| I used to help friends and family disinfect their PCs
| from all the malware they'd unintentionally installed.
| MarsIronPI wrote:
| > Yes, JS is overused. But JS also brings significant
| real value to the web. JS is what has allowed websites to
| replace desktop apps in many cases.
|
| Exactly. JS should be used to make apps. A blog is not an
| app. Your average blog should have 0 lines of JS. Every
| time I see a blog or a news article who's content doesn't
| load because I have JS disabled I strongly reconsider
| whether it's worth my time to read or not.
| selfhoster11 wrote:
| I don't see how this makes the "JS availability should be
| the baseline" assumption any more legitimate. We make it
| possible to function in a society for those 6% of people.
| Low percentage still works out to a whole lot of people
| who shouldn't be left out.
| dpark wrote:
| I disagree. The world is under no obligation to cater to
| a tiny minority who self-select into reduced-
| functionality experiences.
|
| It's fine for you to turn off JS. It's also fine for
| developers to require JS. Software has had minimum system
| requirements forever. I can't run Android apps on my Palm
| Pilot from 2002 either and no one is obligated to make
| them work for me.
| stronglikedan wrote:
| The point of the poster you're responding to is that sites
| are built JS-first for 98-99% of users, and it takes extra
| work to make them compatible with "JavaScript should NOT be
| REQUIRED to view a website", and no one is going to bother
| doing that work for 1-2% of users.
| davisr wrote:
| Yeah... or...... maybe they should just build websites
| the proper way the first time around, returning plain
| HTML, perhaps with some JS extras. Any user-entered input
| needs to be validated again on the backend anyway, so
| client-side JS is often a waste.
| zzo38computer wrote:
| In addition to those things, JavaScripts can also cause
| some things to not work properly even though they would
| work without JavaScripts.
| samdoesnothing wrote:
| I make Javascript mandatory to use my sites regardless of
| if it's necessary.
| tptacek wrote:
| Of note here is that the segment we're talking about is
| actually an intersection of two very small cohorts; the
| first, as you note, are people who don't own a television
| errr disable Javascript, and the second is sites that
| actually rely on XSLT, of which there are vanishingly few.
| magicalist wrote:
| > _I don 't block XSLT because I haven't come across malicious
| use of XSLT before (though to be fair, I haven't come across
| much use of XSLT at all)_
|
| Recent XSLT parser exploits were literally the reason this
| whole push to remove it was started, so this change will
| specifically be helping people in your shoes.
| neilk wrote:
| XSLT is being exploited right now for security vulnerabilities,
| and there is no solution on the horizon.
|
| The browser technologies that people actually use, like
| JavaScript, have active attention to security issues, decades
| of learnings baked into the protocol, and even attention from
| legislators.
|
| You imagine that XSLT is more secure but it's not. It's never
| been. Even pure XSLT is quite capable of Turing-complete
| tomfoolery, and from the beginning there were loopholes to
| introduce unsafe code.
|
| As they say, security is not a product, it's a process. The
| process we have for existing browser technologies is better.
| That process is better because more people use it.
|
| But even if we were to try to consider the technologies in
| isolation, and imagine a timeline where things were different?
| I doubt whether XML+XSLT is the superior platform for security.
| If it had won, we'd just have a different nightmare of
| intermingled content and processing. Maybe more stuff being
| done client-side. I expect that browser and OS manufacturers
| would be warping content to insert their own ads.
| rf15 wrote:
| As someone who built an XSLT renderer and remembers having an
| awful time with the spec: good riddance.
|
| Data and its visualisation should be strictly separate, and not
| require an additional engine in your environment of choice.
| afandian wrote:
| Previous discussion https://news.ycombinator.com/item?id=44952185
| fithisux wrote:
| Removing JavaScript for a more secure browser.
| phendrenad2 wrote:
| Unquestionably the right move. From the various posts on HN about
| this, it's clear that (A) not many people use it (B) it increases
| security vulnerability surface area (C) the few people who do
| claim to use have nothing to back up the claim
|
| The major downside to removing this seems to be that a lot of
| people LIKE it. But eh, you're welcome to fork Chromium or
| Firefox.
| lunar_mycroft wrote:
| Chrome and other browsers could virtually completely mitigate
| the security issues by shipping the polyfil they're suggesting
| all sites depending on XSLT deploy in the browser. By doing so,
| their XSLT implementation would become no less secure than
| their javascript implementation (and fat chance they'll remove
| _that_ ). The fact that they've rejected doing so is a pretty
| clear indication that security is just an excuse, IMO.
| chrismorgan wrote:
| I wish more people would see this. They know _exactly_ how to
| sandbox it, they're telling you how to, _they're even
| providing and recommending a browser extension to securely
| restore the functionality they're removing!_
|
| The security argument can be valid motivation for doing
| something, but is utterly illegitimate as a reason for
| removing. They want to remove it because they abandoned it
| many years ago, and it's a _maintenance burden_. Not a
| security burden, they've shown exactly how to fix that as
| part of preparing to remove it!
| lunar_mycroft wrote:
| And it's a very small maintenance burden at that. Shipping
| the polyfil would technically still be a dependency, but
| about as decoupled a dependency as you can get. It's only
| interaction with the rest of the code would be through
| public APIs that browsers have to keep stable anyway.
| willseth wrote:
| "[Y]ou're welcome to fork Chromium or Firefox" is the software
| developer equivalent of saying "you're welcome to go fuck
| yourself."
| larusso wrote:
| Makes me kind of sad. I started my carrier back in days when
| XHTML and co were lauded as the next thing. I worked with SOAP
| and WDSLs. I loved that one can express nearly everything in XML.
| And namespaces... Then came json and apart from being easier to
| read for humans I wondered why we switch from this one great
| exchange format to this half baked one. But maybe I'm just
| nostalgic. But every time I deal with json parsers for type
| serialization and the question how to express HashMaps and sets,
| how to provide type information etc etc I think back to XML and
| the way that everything was available on board. Looked ugly as
| hell though :)
| kome wrote:
| json is sort of a gresham's law "bad money drives out the good"
| but for tech: lazy and forgiving technologies drive out the
| better but stricter ones.
|
| bad technology seems to make life easier at the beginning, but
| that's why we now have sloppy websites that are an unorganized
| mess of different libraries, several MB in size without reason,
| and an absolute usability and accessibility nightmare.
|
| xhtml and xml were better, also the idea separating syntax from
| presentation, but they were too intelligent for our own good.
| mpyne wrote:
| > lazy and forgiving technologies drive out the better but
| stricter ones.
|
| JSON is not "lazy and forgiving" (seriously, go try adding a
| comment to it).
|
| It was just laser-focused on what the actual problem was that
| needed to be solved by many devs in day-to-day practice.
|
| Meanwhile XML wanted to be an entire ecosystem, its own XML
| Cinematic Universe, where you had to adopt it all to really
| use it.
|
| It's not surprising to me that JSON won out, but it's not
| because it's worse, it's actually much better than XML for
| the job it ended up being used for (a generic format to
| transfer state between running programs supporting common
| data structures with no extraneous add-ons or requirements).
|
| XML is better for a few other things, but those things are
| far less commonly needed.
| gdulli wrote:
| I don't use XSLT and don't object to this, but seeing "security"
| cited made me realize how reflexively distrustful I've become of
| them using that justification for a given decision. Is this one
| actually about security? Who knows!
| Devasta wrote:
| Its "Security" when they want to do a thing, its "WebCompat"
| when they don't.
| JimDabell wrote:
| > Finding and exploiting 20-year-old bugs in web browsers
|
| > Although XSLT in web browsers has been a known attack surface
| for some time, there are still plenty of bugs to be found in
| it, when viewing it through the lens of modern vulnerability
| discovery techniques. In this presentation, we will talk about
| how we found multiple vulnerabilities in XSLT implementations
| across all major web browsers. We will showcase vulnerabilities
| that remained undiscovered for 20+ years, difficult to fix bug
| classes with many variants as well as instances of less well-
| known bug classes that break memory safety in unexpected ways.
| We will show a working exploit against at least one web browser
| using these bugs.
|
| -- https://www.offensivecon.org/speakers/2025/ivan-fratric.html
|
| -- https://www.youtube.com/watch?v=U1kc7fcF5Ao
|
| > libxslt -- unmaintained, with multiple unfixed
| vulnerabilities
|
| --
| https://vuxml.freebsd.org/freebsd/b0a3466f-5efc-11f0-ae84-99...
| bawolff wrote:
| Didn't this come pretty directly after someone found some
| security vulns? I think the logic was, this is a huge chunk of
| code that is really complex which almost nobody uses outside of
| toy examples (and rss feeds). Sure, we fixed the issue just
| reported, but who knows what else is lurking here, it doesn't
| seem worth it.
|
| As a general rule, simplifying and removing code is one of the
| best things you can do for security. Sure you have to balance
| that with doing useful things. The most secure computer is an
| unplugged computer but it wouldn't be a very useful one;
| security is about tradeoffs. There is a reason though that
| security is almost always cited - to some degree or another,
| deleting code is always good for security.
| wswope wrote:
| > As a general rule, simplifying and removing code is one of
| the best things you can do for security.
|
| Sure, but that's not what they're doing in the big picture.
| XSLT is a tiny drop in the bucket compared to all the surface
| area of the niche, non-standard APIs tacked onto Chromium.
| It's classic EEE.
|
| https://developer.chrome.com/docs/web-platform/
| bawolff wrote:
| My understanding is that contrary to popular opinion it is
| firefox not chrome that originally pushed for the removal,
| so i dont know how relavent that is. It seems like all
| browser vendors are in agreement on xslt.
|
| that said, xslt is a bit of a weird api in how it interacts
| with everything. Not all apis are equally risky and i
| suspect xslt is pretty high up there on the risk vs reward
| ratio.
| masfuerte wrote:
| There are security issues in the C implementation they
| currently use. They could remove this without breaking anything
| by incorporating the JS XSLT polyfill into the browser. But
| they won't because money.
| chrismorgan wrote:
| > _example.com needs to review the security of your connection
| before proceeding._
|
| This text from Cloudflare challenge pages is just a flat-out
| lie.
| willseth wrote:
| It's true that there are security issues, but it's also true
| that they don't want to put any resources into making their
| XSLT implementation secure. There is strong unstated subtext
| that a huge motivation is that they simply want to rip this out
| of Chrome so they don't have to maintain it at all.
| throw_m239339 wrote:
| Especially when Google largely has the money to maintain the
| alleged unsecure library... of course it's an excuse to break
| the web once again.
|
| XSLT is fantastic. You just feed it an XML file and it can
| change it into HTML, without any need for javascript.
| p0w3n3d wrote:
| what exactly is the security concern with xslt?
| JimDabell wrote:
| This is answered in the article.
| TingPing wrote:
| It parses untrusted input, the library is basically
| unmaintained, it's not often audited but anytime someone looks
| they find a CVE.
| jeffbee wrote:
| XSLT the idea contains few (but not zero) unavoidable security
| flaws.
|
| libxslt the library is a barely-maintained dumpster fire of bad
| practices.
| ryoshu wrote:
| They should audit LLMs.
| TazeTSchnitzel wrote:
| It wasn't clear to me from reading this whether
| <?xml-stylesheet
|
| with _CSS_ will also stop being supported. There 's no need to
| deprecate _that_ , surely?
| aorth wrote:
| Ah, so this is removing libxslt. For a minute I thought XSLT
| processing was provided by libxml2, and I remembered seeing that
| the Ladybird browser project just _added_ a dependency on libxml2
| in their latest progress update
| https://ladybird.org/newsletter/2025-10-31/.
|
| I'm curious to see what happens going forward with these aging
| and under-resourced--yet critical--libraries.
| Devasta wrote:
| _" The reality is that for all of the work that we've put into
| HTML, and CSS, and the DOM, it has fundamentally utterly failed
| to deliver on its promise.
|
| It's even worse than that, actually, because all of the things
| we've built aren't just not doing what we want, they're holding
| developers back. People build their applications on frameworks
| that _abstract out_ all the APIs we build for browsers, and _even
| with those frameworks_ developers are hamstrung by weird
| limitations of the web."_
|
| - https://news.ycombinator.com/item?id=34612696#34622514
|
| I find it so weird that browser devs can point to the existence
| of stuff like React and not feel embarrassed.
| shadowgovt wrote:
| > I find it so weird that browser devs can point to the
| existence of stuff like React and not feel embarrassed.
|
| Sorry, I don't follow. What's embarrassing about React?
| simonw wrote:
| If you are using XSLT to make your RSS or atom feeds readable in
| a browser should somebody click the link you may find this post
| by Jake Archibald useful: https://jakearchibald.com/2025/making-
| xml-human-readable-wit... - it provides a JavaScript-based
| alternative that I believe should work even after Chrome remove
| this feature.
| nwellnhof wrote:
| The "severe security issue" in libxml2 they mention is actually a
| non-issue and the code in question isn't even used by Chrome. I'm
| all for switching to memory-safe languages but badmouthing OSS
| projects is poor style.
| cxr wrote:
| Where's the best collection or entry point to what you've
| written about Chrome's use of Gnome's XML libraries, the
| maintenance burden, and the dearth of offers by browser makers
| foot the bill?
| chuckadams wrote:
| The issue in question is just one of the several long-unfixed
| vulnerabilities we know about, from a library that doesn't have
| that many hands or eyes on it to begin with.
| sroussey wrote:
| And why doesn't Google contribute to fixing and maintaining
| code they use?
| SoftTalker wrote:
| Because in this case it doesn't contribute to their ability
| to deliver ads.
| kccqzy wrote:
| Because they don't want to use the code. They begrudgingly
| use it to support XSLT and now they don't use it.
| lunar_mycroft wrote:
| Maintaining web standards without breaking backwards
| compatibility is literally what they signed up for when
| they decided to make a browser. If they didn't want to do
| that job, they shouldn't have made one.
| will4274 wrote:
| According to whom?
|
| Chromium is open source and free (both as in beer and
| speech). The license says they've made no future
| commitments and made no warrants.
|
| Google signed up to give something away for free to
| people who want to use it. From the very first version,
| it wasn't perfectly compatible with other web browsers
| (which mostly did IE quirks things). If you don't want to
| use it, because it doesn't maintain enough backwards
| compatibility... Then don't.
| lunar_mycroft wrote:
| The license would be relevant if I'd claimed that
| removing XSLT was illegal or opened them up to lawsuits,
| but I didn't. The obligation they took on is
| social/ethical, not legal. By your logic, chrome could
| choose to stop supporting literally anything (including
| HTML) in their "browser" and not have done anything that
| we can object to.
|
| iIRC, lack of IE compatibility is fundamentally
| different, because the IE specific stuff they didn't
| implement was never part of the open web standards, but
| rather stuff Microsoft unilaterally chose to add.
| spookie wrote:
| The license is the way it is not by choice. We should be
| clear about that and acknowledge KHTML, and both Safari
| and Chromium origins. Some parts remain LGPL to this day.
| spookie wrote:
| They "own the web". They steer its standards, and other
| browsers' development paths (if they want to remain
| relevant).
|
| It is remarkable the anti-trust case went as it did.
| timeon wrote:
| If that was case they would switch to (rust XPath/XSLT) Xee.
| delfinom wrote:
| Nobody is badmouthing open source. It's the core truth, open
| source libraries can become unmaintained for a variety of
| reasons, including the code base becoming a burden to maintain
| by anyone new.
|
| And you know what? That's completely fine. Open source doesn't
| mean something lives forever
| flomo wrote:
| Sounded like the maintainers of libxml2 have stepped-back, so
| there needs to be a supported replacement, because it is widely
| used. (Or if you are worried the reputation of "OSS", you can
| volunteer!)
| jeroenhd wrote:
| Google is too cheap to fund or maintain the library they've
| built their browser with after its hobbyist maintainers got
| burnt out, for more than a decade so they're ripping out the
| feature.
|
| Their whole browser is made up of unsafe languages and their
| attempt to sort of make c++ safer has yet to produce a usable
| proof of concept compiler. This is a fat middle finger in the
| face of all the people's free work they grabbed to collect
| billions for their investors.
| Genbox wrote:
| It is also kinda a self-burn. Chromium an aging code base [1].
| It is written in a memory unsafe language (C++), calls hundreds
| of outdated & vulnerable libraries [2] and has hundreds of high
| severity vulnerabilities [3].
|
| People in glass houses shouldn't throw stones.
|
| [1]
| https://github.com/chromium/chromium/commits/main/?after=c5a...
|
| [2] https://github.com/chromium/chromium/blob/main/DEPS
|
| [3] https://www.cvedetails.com/product/15031/Google-
| Chrome.html?...
| immibis wrote:
| Although it's sad to see an interesting feature go, they're not
| wrong about security. It's more important to have a small attack
| surface if this was maintained by one guy in Nebraska and he
| doesn't maintain it any more.
|
| No, XSLT isn't required for the open web. Everything you can do
| with XSLT, you can also do without XSLT. It's interesting
| technology, but not essential.
|
| Yes, this breaks compatibility with all the 5 websites that use
| it.
| arandr0x wrote:
| It's encouraging to see browsers actually deprecate APIs, when I
| think a lot of problems with the Web and Web security in
| particular is people start using new technologies too fast but
| don't stop using old ones fast enough.
|
| That said, it's also pretty sad. I remember back in the 2000s
| writing purely XML websites with stylesheets for display, and
| XML+XSLT is more powerful, more rigorous, and arguably more
| performant now in the average case than JSON + React + vast
| amounts of random collated libraries which has become the Web
| "standard".
|
| But I guess LLMs aren't great at generating XSLT, so it's
| unlikely to gain back that market in the near future. It was a
| good standard (though not without flaws), I hope the people who
| designed it are still proud of the influence it did have.
| danielvaughn wrote:
| Agreed on API deprecation, the surface is so broad at this
| point that it's nearly impossible to build a browser from
| scratch. I've been doing webdev since 2009 and I'm still
| finding new APIs that I've never heard of before.
| update wrote:
| > I remember back in the 2000s writing purely XML websites with
| stylesheets for display
|
| Awesome! I made a blog using XML+XSLT, back in high school. It
| was worth it just to see the flabbergasted look on my friends
| faces when I told them to view the source code of the page, and
| it was just XML with no visible HTML or CSS[0].
|
| [0] https://www.w3schools.com/xml/simplexsl.xml - example
| XML+XSLT page from w3schools
| logifail wrote:
| > I remember back in the 2000s writing purely XML websites with
| stylesheets for display
|
| Yup, "been there, done that" - at the time I think we were
| creating reports in SQL Server 2000, hooked up behind IIS.
|
| It feels this is being deprecated and removed because it's gone
| out of fashion, rather than because it's actually measurably
| worse than whatever's-in-fashion-today... (eg
| React/Node/<whatever>)
| SoftTalker wrote:
| Yeah it was great. You could sort/filter/summarize in
| different ways all without a server round-trip. At the time
| it seemed magical to users.
| austin-cheney wrote:
| What about XML + CSS? CSS works the exact same on XML as it
| does on HTML. Actually, CSS works better on XML than HTML
| because namespace prefixes provide more specific selectors.
|
| The reason CSS works on XML the same as HTML is because CSS is
| not styling tags. It is providing visual data properties to
| nodes in the DOM.
| 1718627440 wrote:
| Some people seem to think XSLT is used for the step from DOM ->
| Graphics. This is not the first time I have send a comment
| implying that, but it is wrong. XSLT is for the step from
| 'normalized data' -> DOM. And I like it, that this can be done
| in a declarative way.
| mindwok wrote:
| 100%. I've been neck deep over the past few months in
| developing a bunch of Windows applications, and it's convinced
| me that never deprecating or removing anything in the name of
| backwards incompatibility is the wrong way. There's a balance
| to be struck like anything, but leaving these things around
| means we continue to pay for them in perpetuity as new
| vulnerabilities are found or maintenance is required.
| Fileformat wrote:
| One extremely important XSLT use-case is for RSS/Atom feeds.
| Right now, clicking on a link to feed brings up a wall of XML (or
| worse, a download link). If the feed has an XSLT stylesheet, it
| can be presented in a way that a newcomer can understand and use.
|
| I realize that not that many feeds are actually doing this, but
| that's because feed authors are tech-savvy and know what to do
| with an RSS/Atom link.
|
| But someone who hasn't seen/used an RSS reader will see a wall of
| plain-text gibberish (or a prompt to download the wall of
| gibberish).
|
| XSLT is currently the only way to make feeds into something that
| can still be viewed.
|
| I think RSS/Atom are key technologies for the open web, and
| discovery is extremely important. Cancelling XSLT is going in the
| wrong direction (IMHO).
|
| I've done a bunch of things to try to get people to use XSLT in
| their feeds: https://www.rss.style/
|
| You can see it in action on an RSS feed here (served as real XML,
| not HTML: do view/source):
| https://www.fileformat.info/news/rss.xml
| yegle wrote:
| FWIW the original post explicitly mentioned this use case and
| offered two ways to workaround.
| Fileformat wrote:
| Gotta love the reference to the <link> header element. There
| used to be an icon in the browser URL bar when a site had a
| feed, but they nuked that too.
| jeffbee wrote:
| Man, reaching way back in history here, but this reminds me
| of why I stopped contributing to Mozilla decades ago. My
| contribution was the link toolbar, that was supposed to
| give a UI representation of the canonical link elements
| like next and prev and whatnot. At the last minute before a
| major release some jerkhole of a product manager at AOL cut
| my feature from the release. It's incredible the way such
| pretty bureaucrats have shaped web browsers over the years.
| shadowgovt wrote:
| Good user-facing software tends to have a coherent
| vision, and that involves getting features cut that
| people put a lot of time and effort into; even though
| those features have value, it's possible they don't have
| value in the product under development.
|
| I don't really have enough context to say whether that
| was the case here. Mostly I'm raising the comment to note
| that this is an issue in commercial software too, but the
| sting is immediately moderated by "At least you got
| paid." It's a lot easier to see one's work fail to be
| reflected in the finished product when you can dry your
| tears with the bills in your money-pile (and I don't know
| how open source competes in things as cut-throat and
| taste-opinionated as UI when that continues to be true
| without solving the problem by injecting money into the
| process, which carries its own risks).
| cosmic_cheese wrote:
| > There used to be an icon in the browser URL bar when a
| site had a feed, but they nuked that too.
|
| This is actually a feature of Orion[0], and among the
| reasons why I believe it to be one of the most (power)
| user-oriented browsers in active development.
|
| It's such a basic thing that there's really no good reason
| to remove the feature outright (as mainstream browsers
| have), especially when the cited reason is to "reduce
| clutter" which has been added back tenfold with garbage
| like chatbots and shopping assistants.
|
| [0]: https://kagi.com/orion/
| lunar_mycroft wrote:
| iIRC, all of the proposed workarounds involved updating the
| sites using XSLT, which may not always be particularly easy,
| or even something publishers will realize they need to do.
| fevangelou wrote:
| Here's a 3rd option :)
|
| For RSS/Atom feeds presented as links in a site (for
| convenience to users), developers can always offer a simple
| preview for the feed output using: https://feedreader.xyz/
|
| Just URL-encode the feed like so: https://feedreader.xyz/?url
| =https%3A%2F%2Fwww.theverge.com%2...
|
| ...and you get a nice preview that's human readable.
| jerf wrote:
| I've been involved in the RSS world since the beginning and
| I've never clicked on an RSS link and expected it to be
| rendered in a "nice" way, nor have I seen one.
|
| "XSLT is currently the only way to make feeds into something
| that can still be viewed."
|
| You could use content negotiation just fine. I just hit my
| personal rss.xml file, and the browser sent this as the Accept
| header:
| text/html,application/xhtml+xml,application/xml;
| q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8
|
| except it has no newline, which I added for HN.
|
| You can easily ship out an HTML rendering of an RSS file based
| on this. You can have your server render an XSLT if you must.
| You can have your server send out some XSLT implemented in JS
| that will come along at some point.
|
| To a first approximation, nobody cares enough to use content
| negotiation any more than anyone cares about providing XML
| stylesheets. The tech isn't the problem, the not caring is...
| and the not caring isn't actually that big a problem either.
| It's been that way for a long time and we aren't actually all
| that bothered about it. It's just a "wouldn't it be nice" that
| comes up on those rare occasions like this when it's the topic
| of conversation and doesn't cross anyone's mind otherwise.
| zamalek wrote:
| > I've been involved in the RSS world since the beginning and
| I've never clicked on an RSS link and expected it to be
| rendered in a "nice" way, nor have I seen one.
|
| So that excludes you from the "someone who hasn't seen/used a
| RSS reader" demographic mentioned in the comment you are
| replying to.
| doctorpangloss wrote:
| The phrase you are looking for to describe this discourse is
| "concern trolling."
| cosmic_cheese wrote:
| > nor have I seen one.
|
| Once upon a time, nice in-browser rendering of RSS/Atom feeds
| complete with search and sorting was a headliner feature of
| Safari.
|
| https://www.askdavetaylor.com/how_do_i_subscribe_to_rss_feed.
| ..
| bawolff wrote:
| I think it used to be more popular in early days. At one
| point i think firefox was styling rss feeds by default so
| people stopped using xslt as much.
|
| You can still style them with css if you want. I dont really
| see the point. RSS is for machines to read not humans.
| cbarrick wrote:
| You've been in the RSS world since the beginning and never
| seen a stylized feed?
|
| I've _not_ been in the RSS world very much. I don 't use news
| readers. And even I have seen a stylized RSS in the wild.
|
| Our individual experiences are of course anecdotal, I'm just
| surprised at how different they are given your background.
| AlecSchueler wrote:
| > I've been involved in the RSS world since the beginning and
| I've never clicked on an RSS link and expected it to be
| rendered in a "nice" way, nor have I seen one.
|
| Maybe it's more for people who have no idea what RSS is and
| click on the intriguing icon. If they weren't greeted with a
| load of what seems like nonsense for nerds there could have
| been broader adoption of RSS.
| klez wrote:
| > If they weren't greeted with a load of what seems like
| nonsense for nerds there could have been broader adoption
| of RSS.
|
| Why? Wouldn't just see a different view of the same website
| that had that intriguing icon and go "ok, so what?"
|
| If they don't know what an RSS feed is, seeing a stylized
| version isn't really going to help them understand, imho.
| AlecSchueler wrote:
| You can add text to the document via XSL which can be
| used to explain what you're looking at and how to use it.
|
| See: https://developer.mozilla.org/en-
| US/docs/Web/XML/XSLT/Refere...
| Fileformat wrote:
| That's my point: you know all about RSS & feeds and don't
| need it. But what about someone who hasn't been using them
| since the beginning?
|
| I think every page with an RSS feed should have a link to the
| feed _in the html body_. And it should be friendly to people
| who are not RSS wizards.
| Fileformat wrote:
| Another point: it is shocking how many feeds have errors in
| them. I analyzed the feeds of some of the top contributors on
| HN, and almost all had something wrong with them.
|
| Even RSS wizards would benefit from looking at a human-
| readable version instead of raw XML.
|
| I ended up writing a feed analyzer that you can try on your
| feed: https://www.rss.style/feed-analyzer.html
| Groxx wrote:
| there's a fairly good chance that you simply haven't
| _noticed_ , because it was working as intended, e.g.
| https://standardebooks.org/feeds/rss/new-releases
|
| from: https://news.ycombinator.com/item?id=45824952
| acabal wrote:
| We do the same with our feeds at Standard Ebooks:
| https://standardebooks.org/feeds/rss/new-releases
|
| The page is XML but styled with XSLT.
| chuckadams wrote:
| > Cancelling XSLT is going in the wrong direction (IMHO).
|
| XSLT isn't going anywhere: hardwiring into the browser an
| implementation that's known to be insecure and is basically
| unmaintained is what's going away. The people doing the
| wailing/rending/gnashing about the removal of libxslt needed to
| step up to fix and maintain it.
|
| It seems like something an extension ought to be capable of,
| and if not, fix the extension API so it can. In firefox I think
| it would be a full-blown plugin, which is a lower-level thing
| than an extension, but I don't know whether Chromium even has a
| concept of such a thing.
| dragonwriter wrote:
| > XSLT isn't going anywhere: hardwiring into the browser an
| implementation that's known to be insecure and is basically
| unmaintained is what's going away.
|
| Not having it available from the browser really reduces the
| ability to use it in many cases, and lots of the nonbrowser
| XSLT ecosystem relies on the same insecure, unmaintained
| implementation. There is at least one major alternative
| (Saxon), and if browser support was switching backing
| implementation rather than just ending support, "XSLT isn't
| going anywhere" would be a more natural conclusion, but
| that's not, for whatever reason, the case.
| tptacek wrote:
| Your argument here includes that browsers should retain
| native XSLT implementations because non-browsers have bad
| XSLT implementations?
| AlecSchueler wrote:
| What do you find questionable about this being included
| as part of the broader argument?
| tptacek wrote:
| I just don't understand it. I don't understand it well
| enough to call out what's questionable about it.
| dragonwriter wrote:
| I don't see anything that looks remotely like a normative
| argument about what browsers _should_ or _should not_ do
| anywhere in my post that you are responding to, did you
| perhaps mean to respond to some other post?
|
| My point was that the decision to _remove_ XSLT support
| from browsers rather than _replacing_ the insecure,
| unmaintained implementation with a secure, maintained
| implementation is an indicator opposed to the claim
| "XSLT isn't going anywhere". I am not arguing anything at
| all about what browser vendors _should_ do.
| tptacek wrote:
| Is the idea that if they did so, the insecure non-browser
| XSLT-users could adopt their implementation?
| dragonwriter wrote:
| The idea is that if they did so, the people using
| software running in the browser could continue to use
| XSLT with just the browser platform because the
| functionality would still be there with a different
| backend implementation, but instead that in-browser XSLT
| functionality is going somewhere, specifically, _away_.
| tptacek wrote:
| Right but either way, the vulnerability exists today, and
| you're saying that whether or not the browser platform
| supports the functionality that harbors the
| vulnerabilities, the browser platform should be
| responsible for resolving those vulnerabilities. That's
| how I read it.
| dragonwriter wrote:
| > and you're saying that whether or not the browser
| platform supports the functionality that harbors the
| vulnerabilities, the browser platform should be
| responsible for resolving those vulnerabilities.
|
| No, I'm not (and I keep saying this explicitly) saying
| that browsers _should_ or _should not_ do anything, or be
| responsible for anything. I'm not making a normative
| argument, _at all_.
|
| I am stating, descriptively, that browser vendors
| choosing to remove XSLT functionality rather than
| repairing it by using an alternative implementation is
| very directly contrary to the claim made upthread that
| "XSLT isn't going anywhere". It is being removed from the
| the most popular application platform in existence, with
| developers being required to bring their own
| implementation for what was previously functionality
| supported by the platform. I am not saying that this is
| good or bad or that anyone should or should not do
| anything differently or making any argument about where
| responsibility for anything related to this lies.
| Kwpolska wrote:
| Or perhaps the multi-billion-dollar corporations could stop
| piggy-backing on volunteers and invest in maintaining the Web
| platform?
| robocat wrote:
| Which popular browsers are significantly leaning on
| individual contributors or volunteers?
| mhitza wrote:
| Almost all of them? as I recall there was a single
| volunteer developer maintaining the xml/xslt libraries
| they were using.
|
| Wasn't it similar with openssl 13+ years ago? Few
| volunteer maintainers, and only after a couple of major
| vulnerabilities money got thrown at that project?
|
| I'm sure there's more and that's why the famous xkcd
| comic is always of relevance.
| Kwpolska wrote:
| Google decided to drop XSLT, because the volunteer-
| maintained libxslt had no maintainers for some time. So,
| instead of helping the project, they just decided to
| remove a feature.
| josefx wrote:
| Were you born before or after heartbleed uncovered the
| sorry state of OpenSSL and the complete absence of
| funding it was maintained under?
|
| So to answer your question: Every single one of them,
| from Google with its billions, to Mozilla with Googles
| billions, none of them would spend even a cent on
| critical open source projects they relied on as long as
| they could get away with it.
| mpyne wrote:
| They did, the issue is that the improved Web platform they
| invested so much to build and maintain has no use for XSLT,
| which is obsolete in the modern world of good JavaScript,
| JSON and modern Fetch APIs.
| Fileformat wrote:
| So... you want newbies to install an extension/plugin before
| they get a human-readable view of a feed???
|
| That's about as new-user-hostile as I can imagine.
| MrJohz wrote:
| There are plenty of ways around this.
|
| As others have pointed out, there are other options for
| styling XML that work well enough in practice. You can also
| do content negotiation on the server, so that a browser
| requesting an html document will get the human-readable
| version, while any feed reader will be sent the XML
| version. (If you render the html page with XSLT, you can
| even take advantage of better XSLT implementations where
| you don't need to work around bugs and cross-platform
| jank.) Or you can rely on `link` tags, letting users submit
| your homepage to their feed reader, and having the feed
| reader figure out where everything is.
|
| There might even be a mime code for RSS feeds, such that if
| you open an RSS feed in your browser, it automatically
| figures out the correct application (i.e. your preferred
| RSS reader) to open that feed in. But I've not seen that
| actually implemented anywhere, which is a shame, because
| that seems like by far the best option for user experience.
| imiric wrote:
| > XSLT isn't going anywhere
|
| XSLT as a feature is being removed from web browsers, which
| is pretty significant. Sure it can still be used in
| standalone tools and libraries, but having it in web browsers
| enabled a lot of functionality people have been relying on
| since the dawn of the web.
|
| > hardwiring into the browser an implementation that's known
| to be insecure and is basically unmaintained is what's going
| away
|
| So why not switch to a better maintained and more secure
| implementation? Firefox uses TransforMiix, which I haven't
| seen mentioned in any of Google's posts on the topic. I can't
| comment on whether it's an improvement, but it's certainly an
| option.
|
| > The people doing the wailing/rending/gnashing about the
| removal of libxslt needed to step up to fix and maintain it.
|
| Really? How about a trillion dollar corporation steps up to
| sponsor the lone maintainer who has been doing a thankless
| job for decades? Or directly takes over maintenance?
|
| They certainly have enough resources to maintain a core web
| library and fix all the security issues if they wanted to.
| The fact they're deciding to remove the feature instead is a
| sign that they simply don't.
|
| And I don't buy the excuse that XSLT is a niche feature.
| Their HTML bastardization AMP probably has even less users,
| and they're happily maintaining that abomination.
|
| > It seems like something an extension ought to be capable of
|
| I seriously doubt an extension implemented with the
| restricted MV3 API could do everything XSLT was used for.
|
| > and if not, fix the extension API so it can.
|
| Who? Try proposing a new extension API to a platform
| controlled by mega-corporations, and see how that goes.
| chrisweekly wrote:
| Another use case I discovered and implemented many years ago
| was styling a sitemap.xml for improved UX / aesthetics.
| AlecSchueler wrote:
| > not that many feeds are actually doing this
|
| Isn't this kind of an argument for dropping it? Yeah it would
| be great if it was in use but even the people who are clicking
| and providing RSS feeds don't seem to care that much.
| Fileformat wrote:
| You are probably right, but it is depressing how techies
| don't see the big picture & don't want to provide an on-ramp
| to the RSS/Atom world for newcomers.
| wryoak wrote:
| Google is widely faulted with effectively killing RSS by
| pulling the plug on Reader (I, for example, haven't used
| RSS since), so I don't think they're missing the big
| picture, I think they just prefer a different picture
| pjmlp wrote:
| I never got the backslash with Reader, having always used
| native apps to handle RSS.
| wryoak wrote:
| Native apps are always better, but having a web page
| syncing your feeds made it easier to access them, eg from
| the library or work computer. Not to mention nothing to
| install (or update) reduces friction. I didn't have to
| stop using RSS, but the newly exposed hurdles were enough
| discouragement that I did stop
| shadowgovt wrote:
| It's probably worth considering that if the technology
| could be killed by _one_ company pulling its chips off
| the board, perhaps the technology wasn 't standing on its
| own.
|
| We still use RSS and Atom feeds for podcasts. It's a
| pretty widely-adopted use case. Perhaps there is a lot
| more to the contraction of RSS as a way for discovering
| publishing of "blog"-style media than "Reader got killed"
| (it seems like Reader offered more features than just RSS
| consolidation that someone could, hypothetically,
| build... But nobody has yet?).
| geocar wrote:
| > One extremely important...
|
| Not to downplay what you think is important, but I think it's
| pretty important that _governments_ and public bodies use XSLT.
|
| https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih....
|
| https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BIL...
|
| https://www.weather.gov/xml/current_obs/KABE.xml
|
| https://www.europarl.europa.eu/politicalparties/index_en.xml
|
| https://apps.tga.gov.au/downloads/sequence-description.xml
|
| https://cwfis.cfs.nrcan.gc.ca/downloads/fwi_obs/WeatherStati...
|
| https://converters.eionet.europa.eu/xmlfile/EPRTR_MethodType...
|
| They don't put ads on their sites, so I'm not surprised Google
| doesn't give a fuck about them...
| jiggawatts wrote:
| > "They don't put ads on their sites, so I'm not
| surprised..."
|
| Similarly, Chrome regularly breaks or outright drops support
| for web features used only in private enterprise networks.
| Think NTLM or Kerberos authentication, private CA revocation
| list checking, that kind of thing.
|
| Again, nobody uses Google Ads on internal apps!
| cedilla wrote:
| Many governments and public bodies used Flash, ActiveX and
| Java applets, but I'm certainly glad we got rid of those.
| al_be_back wrote:
| Replaced them with App stores, why one code base when you
| can have N code bases: web sites, ios, android , tv ...
|
| cheaper, privacy-oriented and more secure lol obviously
| not, doesn't help the consumer or the developer.
|
| Xslt is brilliant at transforming raw data, a tree or table
| for example, without having to install Office apps or
| paying a number of providers to simply view it without
| massive disruption loops.
| thesuitonym wrote:
| I never realized styling RSS feeds was an options. Now looking
| at some of the examples, I wonder how many times I've clicked
| on "Feed", then rolled my eyes and closed it because I thought
| it wasn't RSS. More than zero, I'm sure.
| behringer wrote:
| It's the right direction if you're google. This is why Google
| should not be allowed to control the web. Support firefox, dump
| google.
| cxr wrote:
| > When that solution isn't wanted, the polyfill offers another
| path.
|
| A solution is only a solution if it solves the problem.
|
| This sort of thing, basically a "reverse X/Y problem", is an
| intellectually dishonest maneuver, where a thing is dubbed a
| "solution" after just, like, redefining the problem to not
| include the parts that _make it a problem_.
|
| The problem is that there is content that works today that will
| break after the Chrome team follows through on their announced
| plans of shirking on their responsibility to not break the Web.
| _That 's_ what the problem is. Any "solution" that involves
| people having to go around un-breaking things that the web
| browser broke _is not a solution to the problem that the Chrome
| team 's actions call for people to go around un-breaking things
| that the web browser broke_.
|
| > As mentioned previously, the RSS/Atom XML feed can be augmented
| with one line, <script src="xslt-polyfill.min.js"
| xmlns="http://www.w3.org/1999/xhtml"></script>, which will
| maintain the existing behavior of XSLT-based transformation to
| HTML.
|
| Oh, yeah? It's that easy? So the Chrome team is going to ship a
| solution where when it encounters un-un-fucked content that
| depends on XSLT, Chrome will transparently fix it up as if
| someone had injected this polyfill import into the page, right?
| Or is this another instance where well-paid engineers on the
| Chrome team who elected to accept the responsibility of
| maintaining the stability of the Web have decided that they like
| the getting-paid part but don't like the maintaining-the-
| stability-of-the-Web part and are talking out of both sides of
| their mouths?
| shadowgovt wrote:
| > So the Chrome team is going to ship a solution where when it
| encounters un-un-fucked content that depends on XSLT, Chrome
| will transparently fix it up as if someone had injected this
| polyfill import into the page, right?
|
| As with most things on the web, the answer is "They will if it
| breaks a website that a critical mass of users care about."
|
| And that's the issue with XSLT: it won't.
| cxr wrote:
| > As with most things on the web, the answer is "They will if
| it breaks a website that a critical mass of users care
| about."
|
| This is a (poor) attempt at gaslighting/retconning.
|
| The phrase "Don't break the Web" is not original to this
| thread.
|
| (I can't say I look forward to your follow-up reply employing
| sleights of hand like claims about how stuff like Flash that
| was never standardized, or the withdrawal of experimental
| APIs that weren't both stable/finalized and implemented by
| all the major browsers, or the long tail of stuff on
| developer.mozilla.org that is marked "deprecated" (but
| nonetheless still manages to work) are evidence of your claim
| and that browser makers really do have a history of doing
| this sort of thing. This is in fact the first time something
| like _this_ has actually happened--all because there are
| engineers working on browsers at Google (and Mozilla and
| Apple) that are either confused about how the Web differs
| from, say, Android and iOS, or resentful of their colleagues
| who get to work on vendor SDKs where the API surface area is
| routinely rev 'd to remove whatever they've decided no longer
| aligns with their vision for their platform. That's not what
| the Web is, and those engineers can and should go work on
| Android and iOS instead of sabotaging the far more important
| project of attending to the only successful attempt at a
| vendor-neutral, ubiquitous, highly accessible, substrate for
| information access that no one owns and that doesn't fuck
| over the people who rely on it being stable.)
| slightwinder wrote:
| Would it be possible to move it to an add-on for those who still
| want it? Are WebExtensions supporting third-party-libs?
| RogBogTog wrote:
| I think that's sad. XSLT is in my point a view a very
| misunderstood technology. It gets hated on a lot. I wonder if
| this hate is by people who actually used and understood it,
| though. In any case, more often than not this is by people who in
| the same sentence endorse JavaScript (which, by any objective way
| of measuring is just a language far more poorly designed).
| lolive wrote:
| Iterating upon a JSON in raw JS is much sexier than learning
| XSLT. (at least, JS allows breakpoints in the Chrome debugger)
| eddd-ddde wrote:
| What does XSLT provide that you cannot achieve with plain JS?
| basscomm wrote:
| I'm not much of a programmer, but XSLT being declarative
| means that I can knock out a decent-looking template without
| having to do a whole lot of programming work.
| DonHopkins wrote:
| Au contraire: the more you understand and use XSLT, the more
| you hate it. People who don't understand it and haven't used it
| don't have enough information and perspective to truly hate it
| properly. I and many other people don't hate XSLT out of
| misunderstanding at all: just the opposite.
|
| XSLT is like programming with both hands tied behind your back,
| or pedaling a bicycle with only one leg. For any non-trivial
| task, you quickly hit a wall of complexity or impossibility,
| then the only way XSLT is useful is if you use Microsoft's non-
| standard XSLT extensions that let you call out to JavaScript,
| then you realize it's so easy and more powerful to simply do
| what you want directly in JavaScript there's absolutely no need
| for XSLT.
|
| I understand XSLT just fine, but it is not the only templating
| language I understand, so I have something to compare it with.
| I hate XSLT and vastly prefer JavaScript because I've known and
| used both of them and other worse and better alternatives (like
| Zope Page Templates / TAL / METAL / TALES, TurboGears Kid and
| Genshi, OpenLaszlo, etc).
|
| https://news.ycombinator.com/item?id=44396067
|
| https://news.ycombinator.com/item?id=22264623
|
| https://news.ycombinator.com/item?id=28878913
|
| https://news.ycombinator.com/item?id=16227249
|
| >My (completely imaginary) impression of the XSLT committee is
| that there must have been representatives of several different
| programming languages (Lisp, Prolog, C++, RPG, Brainfuck, etc)
| sitting around the conference table facing off with each other,
| and each managed to get a caricature of their language's cliche
| cool programming technique hammered into XSLT, but without the
| other context and support it needed to actually be useful. So
| nobody was happy!
|
| >Then Microsoft came out with MSXML, with an XSL processor that
| let you include <script> tags in your XSLT documents to do all
| kinds of magic stuff by dynamically accessing the DOM and
| performing arbitrary computation (in VBScript, JavaScript, C#,
| or any IScriptingEngine compatible language). Once you hit a
| wall with XSLT you could drop down to JavaScript and actually
| get some work done. But after you got used to manipulating the
| DOM in JavaScript with XPath, you being to wonder what you ever
| needed XSLT for in the first place, and why you don't just
| write a nice flexible XML transformation library in JavaScript,
| and forget about XSLT.
| basscomm wrote:
| Counterpoint: the more I used XSLT, the more I liked it, and
| the more I was frustrated that the featureset that ships in
| browsers is frozen in 1999
| DonHopkins wrote:
| You should really try some of the modern alternatives.
| Don't let Angular and React's templating systems poison
| you, give Svelte a try!
|
| Even just plain JavaScript is much better and more powerful
| and easier to use than XSLT. There are many JavaScript
| libraries to help you with templates. Is there even any
| such thing as an XSLT library?
|
| Is there some reason you would prefer to use XSLT than
| JavaScript? You can much more easily get a job yourself or
| hire developers who know JavaScript. Can you say the same
| thing for XSLT, and would anyone in their right mind hire
| somebody who knows XSLT but refuses to use JavaScript?
|
| XSLT is so clumsy and hard to modularize, only good for
| messy spaghetti monoliths, no good for components and
| libraries and modules and frameworks, or any form of
| abstraction.
|
| And then there's debugging. Does a good XSLT debugger even
| exist? Can it hold a candle to all the off-the-shelf built-
| in JavaScript debuggers that every browser includes? How do
| you even debug and trace through your XSLT?
| asadotzler wrote:
| It is always correct to tell someone they are wrong for
| liking something, and doing so is how we keep HN great.
| basscomm wrote:
| I think the fundamental disconnect here is that you're
| assuming that I am a developer. I'm not, I'm a lousy
| developer. It's not for lack of trying, programming just
| doesn't click for me in the way that makes learning it an
| enjoyable process.
|
| XSLT is a good middle ground that gave me _just enough_
| rope to do some fun transformations and put up some pages
| on the internet without having to set up a dev
| environment or learn a 'real' programming language
| deepspace wrote:
| Well said. I wrote an XSLT based application back in the
| early 2000s, and I always imagined the creators of XSLT as a
| bunch of slavering demented sadists. I hate XSLT with a
| passion and would take brainfuck over it any day.
|
| Hearing the words Xalan, Xerces, FOP makes me break out in a
| cold sweat, 20 years later.
| flomo wrote:
| IMO XSLT was just too difficult for most webdevs. And IMO this
| created a political problem where the 'frontend' folks needed
| to be smarter than the 'backend' generating the XML in the
| first place.
|
| XSLT might make sense as part of a processing pipeline. But
| putting it on front of your website was just an unnecessary and
| inflexible layer, so that's why everyone stopped doing it.
| (except rss feeds and etc.)
| froh wrote:
| I to this day think the move from dsssl to xslt was the biggest
| mistake in the SGML to XML evolution.
|
| they went from a clean scheme based standard to a human-
| unreadable "use a GUI tool" syntax.
|
| st text serna was a wysiwyg XML FO rendering editor: throw in
| call stylesheets and some input XML, wysiwyg edit away
|
| but xslt didn't take off nor did derived products.
| DonHopkins wrote:
| I recently had an interesting chat with Liam Quin (who was on
| W3C's XML team) about XML and CDATA on Facebook, where he
| revealed some surprising history!
|
| Liam Quinn in his award winning weirdest hat, also Microsoft's
| Matthew Fuchs' talk on achieving extensibility and reuse for XSLT
| 2.0 stylesheets, and Stephan Kesper's simple proof that XSLT and
| XQuery are Turing complete using m-recursive functions, and
| presentations about other cool stuff like Relax/NG:
|
| https://www.cafeconleche.org/oldnews/news2004August5.html
|
| Liam Quin's post:
|
| https://www.facebook.com/liam.quin/posts/pfbid0X6jE58zjcEK5U...
|
| #XML people!
|
| How do we communicate the idea that declarative markup is a good
| idea? Declarative markup is where you identify what is there, not
| what it does. This is a title, not, make this big and bold. This
| is a a part number, not, make this blink when you click it -
| sure, you can do that to part numbers, but don't encode your
| aircraft manual that way.
|
| But this idea is hard to grasp, for the same reason that WYSIAYG
| word processors (the A stands for All, What you see is all you
| get) took over from descriptive formatting in a lot of cases.
|
| For an internal memo, for an insurance letter to a client, how
| much matters? Well, the insurance company has to be able to
| search the letters for specific information for 10, 20, 40, 100
| years. What word processor did you use 40 years ago? Wordstar?
| Magic Wand? Ventura?
|
| #markupMonday #declarativeMarkup
|
| Don Hopkins: I Wanna Be <![CDATA[
|
| https://donhopkins.medium.com/i-wanna-be-cdata-3406e14d4f21
|
| Liam Quin: hahaha i actually opposed the inclusion of CDATA
| sections when we were designing XML (by taking bits we wanted
| from SGML), but they were already in use by the people writing
| the XML spec! But now you've given me a reason to want to keep
| them. The weird syntax is because SGML supported more keywords,
| not only CDATA, but they were a security fail.
|
| Don Hopkins: There was a REASON for the <![SYNTAX[ ]]> ?!?!? I
| though it was just some kind of tribal artistic expressionism,
| like lexical performance art!
|
| At TomTom we were using xulrunner for the cross platform content
| management tool TomTom Home, and XUL abused external entities for
| internationalizing user interface text. That was icky!
|
| For all those years programming OpenLaszlo in XML with <![CDATA[
| JavaScript code sections ]>, my fingers learned how to type that
| really fast, yet I never once wondered what the fuck ADATA or
| BDATA might be, and why not even DDATA or ZDATA? What other kinds
| of data are there anyway? It sounds kind of like quantum
| mechanics, where you just have to shrug and not question what the
| words mean, because it's just all arbitrarily weird.
|
| Liam Quin: haha it's been 30 years, but, there's CDATA (character
| data), replaceable character data (RCDATA) in which `é`
| entity definitions are recognised but not `<`, IGNORE and
| INCLUDE, and the bizarre TEMP which wraps part of a document that
| might need to be removed later. After `<!` you could also have
| comments, <!-- .... --> for example (all the delimiters in SGML
| could be changed).
|
| Don Hopkins: What is James Clark up to these days? I loved his
| work on Relax/NG, and that Dr. Dobb's interview "The Triumph of
| Simplicity".
|
| https://web.archive.org/web/20020224025029/http://www.ddj.co...
|
| Note: James Clark is arguably the single most important engineer
| in XML history:
|
| - Lead developer of SGMLtools, expat, and Jade/DSSSL
|
| - Co-editor of the XML 1.0 specification
|
| - Designer of XSLT 1.0 and XPath 1.0
|
| - Creator of Relax NG, one of the most elegant schema languages
| ever devised
|
| He also wrote the reference XSLT implementation XT, used in early
| browsers and toolchains before libxslt dominated.
|
| James Clark's epic 2001 Doctor Dobb's Journal "A Triumph of
| Simplicity: James Clark on Markup Languages and XML" interview
| captures his minimalist design philosophy and his critique of
| standards and committee-driven complexity (which later infected
| XSLT 2.0).
|
| It touches on separation of concerns, simplicity as survival, a
| standard isn't one implementation, balance of pragmatism and
| purity, human-scale simplicity, uniform data modeling, pluralism
| over universality, type systems and safety, committe pathology,
| and W3C -vs- ISO culture.
|
| He explains why XML is designed the way it is, and reframes the
| XSLT argument: his own philosophy shows that when a
| transformation language stops being simple, it loses the very
| quality that made XML succeed.
| symbogra wrote:
| I wrote a bunch of stuff with XSLT back in the day that I thought
| was pretty cool but I can't for the life of me remember what it
| was...
| zzo38computer wrote:
| XSLT seem like it could be something implemented with WebAssembly
| (and/or JavaScript), in an extension (if the extension mechanism
| is made suitable; I think some changes might be helpful to
| support this and other things), possibly one that is included by
| default (and can be overridden by the user, like any other
| extension should be); if it is implemented in that way then it
| might avoid some of the security issues. (PDF could also be
| implemented in a similar way.)
|
| (There are also reasons why it might be useful to allow the user
| to manually install native code extensions, but native code seems
| to be not helpful for this use, so to improve security it should
| not be used for this and most other extensions.)
| willseth wrote:
| The lead dev driving the Chrome deprecation built a wasm
| polyfill https://github.com/mfreed7/xslt_polyfill. Multiple
| people proposed in the Github discussions leading up to this
| that Google simply make the polyfill ship with Chrome as an on-
| by-default extension that could be disabled in settings, but he
| wouldn't consider it.
| qwertox wrote:
| - Chrome 155 (Nov 17, 2026): XSLT stops functioning on Stable
| releases, for all users other than Origin Trial and Enterprise
| Policy participants.**
|
| - Chrome 164 (Aug 17, 2027): Origin Trial and Enterprise Policy
| stop functioning. XSLT is disabled for all users.**
|
| Not the first time I've seen on Google's pages that the use of
| asterisks then lacks the corresponding footnotes.
| sedatk wrote:
| I like XSLT, and I've been using the browser-based APIs in my
| projects, but I must say that XSLT ecosystem has been in a sad
| state:
|
| - Browsers have only supported XSLT 1.0, for decades, which is
| the stone age of templating. XSLT 3.0 is much nicer, but there's
| no browser support for it.
|
| - There are only two cross-platform libraries built for it:
| libxslt and Saxon. Saxon seriously lacks ergonomics to say the
| least.
|
| One option for Google as a trillion dollar company would be to
| drive an initiative for "better XSLT" and write a Rust-based
| replacement for libxslt with maybe XSLT 3.0 support, but killing
| it is more on-brand I guess.
|
| I also dislike the message "just use this [huge framework
| everyone uses]". Browser-based template rendering without loading
| a framework into the page has been an invaluable boon. It will be
| missed.
| dana321 wrote:
| This is the problem with any C/C++ codebase, using rust instead
| would have been a better solution than just removing web
| standards from what is supposed to be a web browser.
| bigbuppo wrote:
| It's a shame the browser developers are making an open,
| interoperable, semantic web more difficult. It's not surprising,
| though. Browsers started going downhill after they removed the
| status bar and the throbber and made scrollbars useless.
| userbinator wrote:
| If they really cared about "security" they would remove JS or try
| to encourage minimising its use. That is a huge attack surface in
| comparison, but they obviously want to keep it so they can shove
| in more invasive and hostile user-tracking and controlling
| functionality.
| NooneAtAll3 wrote:
| lol, talking about "secure browser" on chrome dot com
___________________________________________________________________
(page generated 2025-11-05 23:01 UTC)