lol, talking about "secure browser" on chrome dot com
Removing XSLT for a more secure browser
231–240 of 352 posts
Re: Removing XSLT for a more secure browser
#232Earlier quoted context omitted.
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 push…
Re: Removing XSLT for a more secure browser
#233Earlier quoted context omitted.
> 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…
Or perhaps the multi-billion-dollar corporations could stop piggy-backing on volunteers and invest in maintaining the Web platform?
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.
Re: Removing XSLT for a more secure browser
#234Makes 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 parse…
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…
> 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.
Re: Removing XSLT for a more secure browser
#235Earlier quoted context omitted.
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 you…
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,…
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", as if it to present it as a rebuttal or rejoinder to something that was said, but then proceeds into total non-sequitur. It's an unrestrained attempt at a change of subject and makes for a not-very-hard-to-spot type of 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.
Re: Removing XSLT for a more secure browser
#236One 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…
> 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/downl…
Many governments and public bodies used Flash, ActiveX and Java applets, but I'm certainly glad we got rid of those.
Re: Removing XSLT for a more secure browser
#237It'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 n…
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.
Re: Removing XSLT for a more secure browser
#238Earlier quoted context omitted.
> 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…
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.
I make Javascript mandatory to use my sites regardless of if it's necessary.
Re: Removing XSLT for a more secure browser
#239I 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!
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.
Re: Removing XSLT for a more secure browser
#240Earlier quoted context omitted.
> 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/downl…
Many governments and public bodies used Flash, ActiveX and Java applets, but I'm certainly glad we got rid of those.
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.