I saw XSLT used to transform RSS feeds into something nicely human readable. That is, the RSS feed was referencing the XSLT. Other than that I haven't noticed the use of XSLT on the web.
"Remove mentions of XSLT from the html spec"
181–190 of 559 posts
Re: "Remove mentions of XSLT from the html spec"
#182Best comment from another related thread (not from me): So the libxml/libxslt unpaid volunteer maintainer wants to stop doing 'disclosure embargo' of reported security issues: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 Shortly after that, Google Chrome want to remove XSLT support. Coincidence? Source (yawaramin): https://news.ycombinator.com/item?id=44925104 PS: Seems libxslt which is used by Blink has an (u…
Mozilla doesn't use libxslt
Re: "Remove mentions of XSLT from the html spec"
#183Earlier quoted context omitted.
Why should the browser contain a specific scripting language, like JavaScript, and not ActiveScript for example?
It's a consequence of javascript being "good enough." Originally, the goal was for the web to support multiple languages (I think one prototype of the tag had a "type=text/tcl") and IE supported VBScript for a while. But at the end of the day, you only really need one, and the type attribute was phased out of the script tag entirely, and Javascript won.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
It is actively used today.
Re: "Remove mentions of XSLT from the html spec"
#184Earlier quoted context omitted.
Former Mozilla and Google (Chrome team specifically) dev here. The way I see what you're saying is: Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT from the web platform, regardless of whether it's still being used. It's okay because someone from Mozilla brought it up. Out of those three projects, two are notoriously under-resourced, and one is notorious for con…
When I see "reps from every browser agree" my bullshit alarm immediately goes off. Does it include unanimous support from browser projects that are either: 1. not trillion dollar tech companies or 2. not 99% funded from a trillion dollar tech company. I have long suspected that Google gives so much money to Mozilla both for the default search option, but also for massive indirect control to deliberately cripple Mozil…
>I have long suspected that Google gives so much money to Mozilla both for the default search option, but also for massive indirect control to deliberately cripple Mozilla in insidious ways to massively reduce Firefox's marketshare.
This has never ever made sense because Mozilla is not at all afraid to piss in Google's cheerios at the standards meetings. How many different variations of Flock and similar adtech oriented features did they shoot down? It's gotta be at least 3. Not to mention the anti-fingerprinting tech that's available in Firefox (not by default because it breaks several websites) and opposition to several Google-proposed APIs on grounds of fingerprinting. And keeping Manifest V2 around indefinitely for the adblockers.
People just want a conspiracy, even when no observed evidence actually supports it.
>And I have long predicted that Google is going to make the rate of change needed in web standards so high that orgs like Mozilla can't keep up and then implode/become unusable.
That's basically true whether incidentally or on purpose.
Re: "Remove mentions of XSLT from the html spec"
#185A few things to note: - This isn't Chrome doing this unilaterally. https://github.com/whatwg/html/issues/11523 shows that representatives from every browser are supportive and there have been discussions about this in standards meetings: https://github.com/whatwg/html/issues/11146#issuecomment-275... - You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time. - Opening a…
Also, https://github.com/whatwg/html/issues/11523 (Should we remove XSLT from the web platform?) is not a request for community feedback. It's an issue open on the HTML spec for the HTML spec maintainers to consider. It was opened by a Chrome engineer after at least two meetings where a Mozilla engineer raised the topic, and where there was apparently vendor support for it. This is happening after some serious exploi…
I think this discussion is quite reasonable, but it also highlights the power imbalance: If this stuff is decided in closed meetings and the bug trackers are not supposed to be places for community feedback, where can the community influence such decisions?
Re: "Remove mentions of XSLT from the html spec"
#186A few things to note: - This isn't Chrome doing this unilaterally. https://github.com/whatwg/html/issues/11523 shows that representatives from every browser are supportive and there have been discussions about this in standards meetings: https://github.com/whatwg/html/issues/11146#issuecomment-275... - You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time. - Opening a…
The responses of some folks on this thread reminds me of this:
Re: "Remove mentions of XSLT from the html spec"
#187This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Also it can be reimplemented using JS or WASM. The browsers today are too bloated and it is difficult to create a new browser engine. I wish there were simpler standards for "minimal browser", for example, supporting only basic HTML tags, basic layout rules, WASM and Java bytecode. Many th…
> This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT XSLT is a specification for a "template engine" and not a specific engine. There are dozens of XSLT implementations. Mozilla notably doesn't use libxslt but transformiix: https://web.mit.edu/ghudson/dev/nokrb/third/firefox/extensio... > and not Jinja for example? Jinja operates on text, so it's basically document.w…
> Sort of. JS is much slower than the native XSLT transform, and the XSLT result is cacheable. That's huge.
Nobody is going to process million of DOM nodes with XSLT because the browser won't be able to display them anyway. And one can write a WASM implementation.
Re: "Remove mentions of XSLT from the html spec"
#188So if in reading the two threads correctly essentially Google asked for feedback, essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"? The other suggestions ignored seemed to be "if this is about security, then fund the OSS, project. Or swap to a newer safer library, or pull it into the JS sandbox and ensure support is maintained." Which were all m…
>essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"?
this is a perfectly reasonable course of action if the feedback is "please don't" but the people saying "please don't" aren't people who are actually using it or who can explain why it's necessary. it's a request for feedback, not just a poll.
Re: "Remove mentions of XSLT from the html spec"
#189Earlier quoted context omitted.
Almost every single government organization uses it to publish their official documents. Lots of major corporations too. As much of a monopoly as Chrome is, if they actually try to remove it they're likely to get a bunch of government web pages outright stating "Chrome is unsupported, please upgrade to Firefox or something".
Huh? I mainly see official government documents as annoying PDFs. Thankfully someone had the bright idea to turn the national law's text into a proper webpage and not use an image-like format for that. (I think regional governments also publish laws as PDF though.) Double checking now, yes: that's definitely HTML and not a transformed XML Which government or governmental organizations are you talking about?
Yes, PDF documents which are generated using XSL-FO (XSL Formatting Objects) from an xml source document
Re: "Remove mentions of XSLT from the html spec"
#190I used XSLT once to publish recipes on the web. The cookbook software my mom used (maybe MasterCook?) could "export as xml" and I wrote an xslt to transform it into readable html. It was fine. It's, of course, also possible to run the XSLT from the command line to generate static html. The suggestion of using a polyfill is a bit nonsensical as I suspect there is little new web being written in XSLT, so someone would…
It would sure be possible to combine a polyfill with a webextension, not sure if XSLT contains any footguns for this approach that would make it hard to do, but if it's solely a single client-side transformation of the initial XML response, this should work fine. Cool example with the recipes page :)
I guess it's time for me to write that webextension; if it gets popular enough I can sell it to someone wearing a black hat for maybe tens of dollars!