Removing XSLT for a more secure browser • Hacker News Board

Re: Removing XSLT for a more secure browser

#291

Post by righthand » Thu, Nov 06, 2025, 4:53 PM UTC

dpark wrote: post #288

righthand wrote: post #287

Earlier quoted context omitted.

Yes we would because people still use fax machines. I don’t understand this “everything must be a business metric because it can, therefor if I can whittle any feature as a small minority, I am forever correct and just in destroying said technology. Look at smart and savvy I am.” Totally brain dead.

Are browser manufacturers required to support features forever no matter how low the usage is? Do you still mourn for the loss of Gopher support?

Yes I mourn the loss of Gopher, RSS, XML, etc.

Browser developers don’t have to do shit but it’s against the idea of an open web to kill off technology, especially one that’s A PART OF THE HTML STANDARD.

You love a closed web. That’s why you’re backing Google and arguing for this. I can’t change that there are so many weak minded “yes daddy Google” people in the world.

All I can do is advocate we support many technologies and ideas. The world you are advocating sounds locked down and uninteresting.

Re: Removing XSLT for a more secure browser

#292

Post by righthand » Thu, Nov 06, 2025, 4:59 PM UTC

JimDabell wrote: post #260

righthand wrote: post #211

Earlier quoted context omitted.

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 mai…

If somebody says “our position is A but if that’s not possible we should do B”, it means they prefer A. It doesn’t mean they prefer B, and telling people that they prefer B when you know otherwise is dishonest.

The comment isn’t “our position is A” the comment is “our position is A if B,C,D aren’t possible for compatibility reasons”. Aka “if we must remove it then fine, else we would like to improve it”.

Google then side stepped all the compatibility concerns and notions to improve it and arguments against removing it so they could only address A.

Go ahead and argue for all the word twisting these bad actors have done. You won’t change my mind this is an obvious attack on the open web by people subservient to the ad tech industry. Prove to me it’s not when all the browsers depend on a platform for ad money. M

They have installed people like Mason Freed into these positions, who are incapable of reason, to carry this objective forward.

Re: Removing XSLT for a more secure browser

#293

Post by shadowgovt » Thu, Nov 06, 2025, 5:00 PM UTC

dpark wrote: post #288

righthand wrote: post #287

Earlier quoted context omitted.

Yes we would because people still use fax machines. I don’t understand this “everything must be a business metric because it can, therefor if I can whittle any feature as a small minority, I am forever correct and just in destroying said technology. Look at smart and savvy I am.” Totally brain dead.

Are browser manufacturers required to support features forever no matter how low the usage is? Do you still mourn for the loss of Gopher support?

Gopher support in browser was never, IIUC, a w3c standard.

Piecing the puzzle pieces together from multiple threads:

There's an argument to be made that the HTML standard, which post-dates the browser wars and was more-or-less the detente that was agreed upon by the major vendors of the day, includes a rule that no compliant browser should drop a feature (no matter how old or unused that feature is) because "Don't break the web." In other words: it doesn't matter if there's zero users of something in the spec; if it's in the spec and you claim to be compliant, you support it.

XSLT has been a W3C recommendation since 1999 and XSLT2 and 3 were added later, and no W3C process has declared it dead. But several browser engines are declaring it's too cumbersome to maintain so they're planning to drop it. This creates an odd situation because generally a detente has held standards in place: you don't drop something people use because users won't perceive the sites that use the tech as broken, they'll perceive your browser is broken and go use someone else's browser.

... except that so many vendors are choosing to drop it simultaneously, and the tech is so infrequently used, that there's a good chance this drop will de-facto kill XSLT client-side rendering as a technology web devs can rely upon regardless of what the spec says.

So people are concerned about a perceived shift in the practical "balance of power" between the standards and the browser developers that (reading between the lines) could usher in the bad old days of the Microsoft monopoly again, except that this time it's three or four browser vendors agreeing upon what the web should be and doing it without external input instead of Microsoft doing what it wants and Firefox fighting them / fighting to keep up. Consolidation of most of the the myriad browsers to only be running on three engines enables this.

Re: Removing XSLT for a more secure browser

#294

Post by shadowgovt » Thu, Nov 06, 2025, 5:01 PM UTC

righthand wrote: post #291

dpark wrote: post #288

Earlier quoted context omitted.

Are browser manufacturers required to support features forever no matter how low the usage is? Do you still mourn for the loss of Gopher support?

Yes I mourn the loss of Gopher, RSS, XML, etc. Browser developers don’t have to do shit but it’s against the idea of an open web to kill off technology, especially one that’s A PART OF THE HTML STANDARD. You love a closed web. That’s why you’re backing Google and arguing for this. I can’t change that there are so many weak minded “yes daddy Google” people in the world. All I can do is advocate we support many technol…

Practically speaking, what does "open web" vs. "Closed web" mean in this context?

Is "open web" just "maximally complies with the w3c standard?"

Re: Removing XSLT for a more secure browser

#295

Post by righthand » Thu, Nov 06, 2025, 5:02 PM UTC

tptacek wrote: post #232

righthand wrote: post #210

Earlier quoted context omitted.

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 push…

https://www.youtube.com/watch?v=1NqLGp6qRuU

Ah you’re just a Google boot licker. Sorry I wasted my time responding, I thought you were serious.

Re: Removing XSLT for a more secure browser

#296

Post by dpark » Thu, Nov 06, 2025, 5:48 PM UTC

righthand wrote: post #291

dpark wrote: post #288

Earlier quoted context omitted.

Are browser manufacturers required to support features forever no matter how low the usage is? Do you still mourn for the loss of Gopher support?

Yes I mourn the loss of Gopher, RSS, XML, etc. Browser developers don’t have to do shit but it’s against the idea of an open web to kill off technology, especially one that’s A PART OF THE HTML STANDARD. You love a closed web. That’s why you’re backing Google and arguing for this. I can’t change that there are so many weak minded “yes daddy Google” people in the world. All I can do is advocate we support many technol…

The proposal is to remove support and change the standard. Standards evolve. Sometimes features are removed because they are costly to maintain or security problems or both.

The fact is that all the major browsers are looking to deprecate this functionality because they all agree it’s a security bug farm and too underutilized to justify fixing.

> You love a closed web. That’s why you’re backing Google and arguing for this. I can’t change that there are so many weak minded “yes daddy Google” people in the world.

Don’t do this. We can just disagree without resorting to strawman and ad hominem attacks. No one insulted you for holding your opinion.

Before this my mental model of you was an engineer who’s frustrated that he’s going to have to do work to deal with the deprecation. I can empathize with that even if I think you are wrong in believing that browsers should invest further in support of xslt. Now I realize you just lack empathy for other engineers who are also forced to make real world trade offs. The fact that you happen to use xslt in the browser does not make it important relative to all the other features browsers support.

Re: Removing XSLT for a more secure browser

#297

Post by tptacek » Thu, Nov 06, 2025, 6:18 PM UTC

righthand wrote: post #295

tptacek wrote: post #232

Earlier quoted context omitted.

https://www.youtube.com/watch?v=1NqLGp6qRuU

Ah you’re just a Google boot licker. Sorry I wasted my time responding, I thought you were serious.

I'm not a Google boot licker, I just hate XSLT, like (empirically) most developers.

Re: Removing XSLT for a more secure browser

#298

Post by cweagans » Thu, Nov 06, 2025, 7:23 PM UTC

davisr wrote: post #289

imtringued wrote: post #277

Earlier quoted context omitted.

This falls apart the moment you need to add rows to a table or show and hide things in response to values selected in a dropdown. Even the lightest JS app centered around a big form is going to become a huge pain in the ass for literally no benefit. In a company of 100 people, that <0.5% of people who disable JS could literally be one guy, or no one at all.

You can use CSS for interactive-esque things like that. Use JS for all I care, just don't make it mandatory. You /could/ refresh the page with new values. You /could/ paginate your flow. You won't, because you'd rather spend 50 hours getting your JS to work right, than 5 hours writing some PHP. Pity.

I _could_ also just write API endpoints and handle client-side interaction however I want. If your preferences are incompatible with mine, that's a tradeoff I'm choosing to make. I am doing the work, you see, and I can choose how I want to do it.

You ostensibly run some flavor of Linux. Do you also complain that macOS apps don't run on your machine? It seems to me like a similar argument: somebody has developed an application in some particular way, but your choices have resulted in that application not running on your machine. Your choices are not necessarily _wrong_, but they are of very little consequence to somebody who has developed an application with a particular environment/runtime in mind. Why should they have to make significant architectural changes to their application to support your non-standard choices?

Re: Removing XSLT for a more secure browser

#299

Post by mpyne » Thu, Nov 06, 2025, 8:59 PM UTC

larusso wrote: post #242

mpyne wrote: post #234

Earlier quoted context omitted.

> 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…

Don’t know if I would describe it as much better. I see it similar to the whole SQL -> NOSQL -> let’s add all the feature and end up with SQL. JSON undergo a similar story with the difference that we didn’t go back to XML. What I mean is to simplify and then realize what was actually missing. But I agree for the smaller services and state transfer especially in web XML was just too damn big and verbose. But conceptua…

For "I need this Python dict to exist in this unrelated JavaScript program's context space" JSON is absolutely much better. If only because you completely sidestep all the various XML foibles, including its very real security foibles.

JSON is so good at this that, like CSV, it does displace better tech for that use case, but the better tech isn't usually XML but rather things like Avro or Protobuf.

For the most part people don't add on XML features to JSON. Comments are a frequent addition, sometimes schemas, but for the most part the attraction of JSON is avoiding features of XML, like external entity validation, namespaces, getting to choose between SAX or DOM styles, or being required to support unrelated XML systems just to use another.

Again, there are problem domains where those are helpful, and XML is a good fit for those. But those problem spaces end up being much smaller in scale than the ones solved by JSON, Avro, Iceberg, etc.

But the whole point to JSON is to be nearly as dumb simple as possible so that the complexity of the problem domain will necessarily be handled in a real programming language, not by the data magically trying to transform itself.

Re: Removing XSLT for a more secure browser

#300

Post by righthand » Thu, Nov 06, 2025, 9:44 PM UTC

dpark wrote: post #296

righthand wrote: post #291

Earlier quoted context omitted.

Yes I mourn the loss of Gopher, RSS, XML, etc. Browser developers don’t have to do shit but it’s against the idea of an open web to kill off technology, especially one that’s A PART OF THE HTML STANDARD. You love a closed web. That’s why you’re backing Google and arguing for this. I can’t change that there are so many weak minded “yes daddy Google” people in the world. All I can do is advocate we support many technol…

The proposal is to remove support and change the standard . Standards evolve. Sometimes features are removed because they are costly to maintain or security problems or both. The fact is that all the major browsers are looking to deprecate this functionality because they all agree it’s a security bug farm and too underutilized to justify fixing. > You love a closed web. That’s why you’re backing Google and arguing fo…

> Sometimes features are removed because they are costly to maintain or security problems or both.

But the features and tech doesn’t have security problems. The library implementation does. This is exactly the kind of bad faith argument I’m talking about. Please just for one second try making an argument pro-XSLT and then try to compare the two mind sets about technology here.

There is no negative trade off by maintaining XSLT other than not being lazy developers. I have no empathy for people who hide behind billion dollar corporations and do their bidding. This is not some sort of critical situation, this is a Google engineer doing things because it’s easier, not “right” or “the difficult choice”.