[deleted]
Removing XSLT for a more secure browser
341–350 of 352 posts
Re: Removing XSLT for a more secure browser
#342[deleted]
Re: Removing XSLT for a more secure browser
#343https://github.com/whatwg/html/issues/11146#issuecomment-275...
panos: next item, removing XSLT. There are usage numbers.
stephen: I have concerns. I kept this up to date historically for Chromium, and I don't trust the use counters based on my experience. Total usage might be higher.
dan: even if the data were accurate, not enough zeros for the usage to be low enough.
mason: is XSLT supported officially?
simon: supported
mason: maybe we could just mark it deprecated in the spec, to make the statement that we're not actively working on it.
brian: we could do that on MDN too. This would be the first time we have something baseline widely available that we've marked as removed.
dan: maybe we could offer helpful pointers to alternatives that are better, and why they're better.
panos: maybe a question for olli. But I like brian's suggestion to mark it in all the places.
dan: it won't go far unless developers know what to use instead.
brian: talk about it in those terms also. Would anyone want to come on the podcast and talk about it? I'm guessing people will have objections.
emilio: we have a history of security bugs, etc.
stephen: yeah that was a big deal
mason: yeah we get bugs about it and have to basically ignore them, which sucks
brian: people do use it and some like it
panos: put a pin in it, and talk with olli next time?
As for the rest of your [working for Google] comment. To put it simply, you come off as someone inexperienced, maybe I'm wrong and you have a big list of features you've successfully removed and public discussions you had in the process, if so, there's probably something to learn from those that's different here.Re: Removing XSLT for a more secure browser
#344https://www.igalia.com/chats/xslt-liam
So basically browsers had this [..] the question now is there is no investment in this. None. And there hasn't been for a really long time from the browser's perspectives.
XPath And XSLT continue to evolve. They've really continued to evolve. And people are currently working on an XSLT-4.
And because it's a declarative way of transforming trees and collections of trees. And declarative means you don't say how to do it. You say, 'This is what I want'..
.. it's timeless: _abstracted definition_ to which imperative solutions could be reduced in the best case - with unaware of that authors repetitively trying (and soon having to) to reimplement that "not needed" ( - if abstracted already out ! - ) part ( ex. https://news.ycombinator.com/item?id=45183624 ) - in more or less common or compatible ways
- so, better keep it - as not everybody can afford expensive solutions and there are nonprofits too that don't depend on % of money wasted repeating same work and like to KISS !
Re: Removing XSLT for a more secure browser
#345Earlier 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,…
by definition XSLT is more secure than JavaScript.
Yes and no. It's true that if you had to pick one to support and were only considering security, it would virtually certainly be better to go with XSLT. However, browser makers basically _have_ to support javascript, so as long as XSLT has a non-zero attack surface (which it does, at least as long as it's a native implementation), including it would be less secure. That said, as I pointed out, there are obvious ways to mitigate this issue and reduce the extra attack surface to effectively zero.
Re: Removing XSLT for a more secure browser
#346Re: Removing XSLT for a more secure browser
#347Earlier quoted context omitted.
by definition XSLT is more secure than JavaScript.
Yes and no. It's true that if you had to pick one to support and were only considering security, it would virtually certainly be better to go with XSLT. However, browser makers basically _have_ to support javascript, so as long as XSLT has a non-zero attack surface (which it does, at least as long as it's a native implementation), including it would be less secure. That said, as I pointed out, there are obvious ways…
[deleted]
Re: Removing XSLT for a more secure browser
#348Just.. and for so long:
XSLT is WWW standard, JavaScript is not (it's ECMA standard) - and there is no JavaScript specification on W3C pages .
( https://www.w3.org/wiki/JavaScript )
Shall JavaScript to become a web standard first - then to be used to "replace" already standard solution ?
Re: Removing XSLT for a more secure browser
#349Earlier quoted context omitted.
At the very least it's (probably*) illegal whether you agree with it or not. Even where it's not illegal, physical violence against your partner isn't okay, even if they've angered you. * depending on jurisdiction
This is all entirely off-topic from using XSLT in a website. As opposed to rendering XSLT client-side or server side, or rendering it using an in-engine native-implementation API or a JavaScript engine. Happy to talk about those if you want; not interested at all in this violence digression you've decided to go on.
Anger is no justification for violence against your partner.
Re: Removing XSLT for a more secure browser
#350Question, how hard is it going to be to add XSLT back with WASM? I have built a few stylesheets for clients to view their raw XML in browser. I even add charts for data tables with XSLT.