Live data from Hacker News

Removing XSLT for a more secure browser

developer.chrome.com

161–170 of 352 posts

Re: Removing XSLT for a more secure browser

#161

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…

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

Re: Removing XSLT for a more secure browser

#162
post #84

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

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

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.

Re: Removing XSLT for a more secure browser

#163

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.

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

Re: Removing XSLT for a more secure browser

#164

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

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

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.

Re: Removing XSLT for a more secure browser

#165

Earlier quoted context omitted.

Your argument here includes that browsers should retain native XSLT implementations because non-browsers have bad XSLT implementations?

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…

Is the idea that if they did so, the insecure non-browser XSLT-users could adopt their implementation?

Re: Removing XSLT for a more secure browser

#166

Earlier quoted context omitted.

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

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.

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.

Re: Removing XSLT for a more secure browser

#167
post #127
post #119

Earlier quoted context omitted.

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.

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

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

Re: Removing XSLT for a more secure browser

#168
post #84

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

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

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

Re: Removing XSLT for a more secure browser

#169

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

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

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.

Re: Removing XSLT for a more secure browser

#170
post #84

Earlier quoted context omitted.

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

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

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

Post reply on HN