You can install an XSLT processor plugin in a corporate setting. This is about the public web.

IMO the main use of client-side XSLT was making people say "what the-?" when they viewed source, because they'd get an XML document full of your entirely custom tags, not the output of the XSLT processor. Which is pretty cool in itself but not worth the attack surface.

▲

Telemakhos 3 days ago | parent [-]

You're ignoring the actual use case: people would view the XML with XSLT in browser and see a web page in a format that they could read and appreciate, and computers could read the XML ignoring the XSLT and get a dataset that they could manipulate for further purposes.

Consider an API that returns not JSON but XML: a human viewing that data in a web browser would see a web page depicting the data, while a script fetching that data would get the underlying data as an intelligible and manipulable structure for further operations. The example usually given was a CD tracklist: a human would get a readable list, while a script would get data about titles, artists, etc, and could file that in a music library or perform other operations on it. I worked with TEI: a human could read a book encoded as TEI and transformed by XSLT into a web page that reproduced the text of the book, but a CMS collecting texts into a corpus could pull bibliographic data from the XML and index the TEI file among others into a library. The main idea was that underlying data should be separated from its presentation, so that XML files would function as data models for different consumers, while XSLT transformed that data for human consumers, and automated consumers would operate on the underlying model. If you remember the late 90s and early 00s, separating data from presentation of data was a major goal, and XSLT did that.

▲

cowlevel 3 days ago | parent [-]

Yeah but you can also implement that by appending .json to the path to get JSON, like in the old reddit API

▲

qrios 2 days ago | parent [-]

By addinng .json you trigger a different render mode on the server. With in-browser XSLT the server does not need to support different rendering requirements.

▲

cowlevel 2 days ago | parent [-]

But the browser does and that's the dangerous attack surface

	▲	qrios 2 days ago \| parent [-]
		Valid point. And as someone who used XSLT in the browser before 2k heavily it was clear, that this is not the way the web will go. To care not only browser specific rendering and styling behaviour, with browser-based XSLT you also had to track different integrations of libxsl. But it was fun. One use case was a browsable work package documentation for a big public funded project. The browser native print function rendered the page in a different style with valid page breaks and numbers.