Live data from Hacker News

Removing XSLT for a more secure browser

developer.chrome.com

261–270 of 352 posts

Re: Removing XSLT for a more secure browser

#261
post #252

Earlier quoted context omitted.

> Mozilla's own site expounds on "Don't Break the Web" as I'm a former Mozillian. I don't give a shit how it has been retconned by whomever happened to be writing copy that day, if indeed they have—it isn't even worth bothering to check. "Don't break the Web" means exactly what it sounds like it means. Anything else is a lie. > If the machine is so complex that nobody wants to maintain it, it will go unmaintained The…

Sounds like you're volunteering to maintain the XSLT support in Firefox. That's great! That means when Chrome tries to decommission it, users who rely upon it will flock to Firefox instead because it's the only browser that works right with the websites they use. Firefox ascendancy is overdue. Best of luck!

[deleted]

Re: Removing XSLT for a more secure browser

#262
post #252

Earlier quoted context omitted.

> Mozilla's own site expounds on "Don't Break the Web" as I'm a former Mozillian. I don't give a shit how it has been retconned by whomever happened to be writing copy that day, if indeed they have—it isn't even worth bothering to check. "Don't break the Web" means exactly what it sounds like it means. Anything else is a lie. > If the machine is so complex that nobody wants to maintain it, it will go unmaintained The…

Sounds like you're volunteering to maintain the XSLT support in Firefox. That's great! That means when Chrome tries to decommission it, users who rely upon it will flock to Firefox instead because it's the only browser that works right with the websites they use. Firefox ascendancy is overdue. Best of luck!

Do you still beat your wife?

Re: Removing XSLT for a more secure browser

#263
post #44

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

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

I think in the context of that link, they see React as a failing of the web. If the W3C/WHATWG/browser vendors had done a reasonable job of moving web technology forward, things like React would be far less necessary. But they spent all their time and energy working on things like and web components instead of listening to web developers and building things that are actually useful in a web developer’s day-to-day life. Front-end frameworks like React, on the other hand, did a far better job of listening to developers and building what they needed.

Re: Removing XSLT for a more secure browser

#264
post #262

Earlier quoted context omitted.

Sounds like you're volunteering to maintain the XSLT support in Firefox. That's great! That means when Chrome tries to decommission it, users who rely upon it will flock to Firefox instead because it's the only browser that works right with the websites they use. Firefox ascendancy is overdue. Best of luck!

Do you still beat your wife?

Don't understand the question, but I do wish you well in your future endeavors!

Re: Removing XSLT for a more secure browser

#265

Earlier quoted context omitted.

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…

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…

We object with our feet, by switching browsers.

What odds would you put dropping XSLT support at for triggering a user migration?

Re: Removing XSLT for a more secure browser

#266
When do we see the headline: Removing Javascript for a more secure browser?

So the honest title should have been: Removing XSLT because it cannot serve adds

(Yes, the underlying implementation might be insecure. But how secure would Javascript be with the same amount of maintenance in the last 20 years?)

Re: Removing XSLT for a more secure browser

#267

Earlier quoted context omitted.

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

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

In Saxon you write templates that give you partial results and just call them with the -it:name switch. So if you have a four-step transform you can examine the results of each step in isolation. In libxslt that only supports 1.0 you can do this with parameters, although this is less convenient.

You can trace with xsl:message. Step-by-step debug is not there, granted; but it is definitely the last resort tool even when it is available.

Re: Removing XSLT for a more secure browser

#268

Earlier quoted context omitted.

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

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

As for the lack of libraries. Technically they are possible, but are not used that often. Maybe they are not that necessary. XML's idea is a federation of notations. Each notations is semantic, that is it makes only specific distinctions. XSLT transforms between two such notations. Since each combination is unique, there is little to reuse. Where other tools use libraries XSLT uses separate stylesheets and just rearranges them differently.

Re: Removing XSLT for a more secure browser

#269
post #174

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…

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

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

Are there examples of this?

Re: Removing XSLT for a more secure browser

#270

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…

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

So it's a parser implementation problem, not XSLT per se.
Post reply on HN