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.
Removing XSLT for a more secure browser
201–210 of 352 posts
Re: Removing XSLT for a more secure browser
#202It'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.
Re: Removing XSLT for a more secure browser
#203Earlier quoted context omitted.
Or perhaps the multi-billion-dollar corporations could stop piggy-backing on volunteers and invest in maintaining the Web platform?
Which popular browsers are significantly leaning on individual contributors or volunteers?
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.
Re: Removing XSLT for a more secure browser
#204Earlier quoted context omitted.
> 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.
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
Re: Removing XSLT for a more secure browser
#205Earlier 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. 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.
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...
Re: Removing XSLT for a more secure browser
#206One 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…
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
Re: Removing XSLT for a more secure browser
#207If 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.
Re: Removing XSLT for a more secure browser
#208Destroying 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.
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.
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.
Re: Removing XSLT for a more secure browser
#209Earlier quoted context omitted.
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,…
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 mainten…
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.
Re: Removing XSLT for a more secure browser
#210Destroying 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.
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.
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.