Playing with XML+XSLT=SVG because I just hate circos.

#bioinformatics #svg #xml #xslt

Playing with XML+XSLT=SVG because I just hate circos.

#bioinformatics #svg #xml #xslt

But as I've already mentioned in other threads, the #GeminiProtocol approach IMO throws away the baby with the bathwater. Many of the web formats and technologies are actually extremely useful even for the “web of documents”: the problem isn't with #HTML, #CSS, #XML, #XSLT, #SVG or even #JavaScript, the problem is that browsers have been catering exclusively to the “web of apps” instead of the “web of documents”. We *can* keep that tech *and* the “web of documents”.

18/

When I think about the amount of resources #Mozilla is throwing behind the integration of #genAI #LLM integration nobody wants to then complain they don't have the resources to maintain and improve #XML & #XSLT or bring back #RSS support makes me seriously angry.

The death of #XSLT by the hand of #Google (again) is quite saddening.

To be clear, the last time I actively used XSLT was probably around 2010. But I still had an emotional attachment to this technology.

Maybe because one of the first bug reports I contributed to as a coder was this ancient Mozilla bug from 2001 which was about XSLT rendering (and btw it’s still open after 24 years, and since XSLT is now officially dead I don’t think it’ll ever be addressed).

Maybe it’s because one of the first iterations of my personal website relied heavily on XSLT.

My website back in 2007-2008 consisted in a bunch of XML files, which were rendered on the fly either as HTML or RSS feeds depending on the client. And XSLT was there operating this transformation behind the scenes.

I get it, the world doesn’t rely so heavy on XML as it did 15 years ago.

But HTML is a superset of XML. As those unloved RSS/Atom feeds are still XML.

XSLT provided the perfect glue to transform one into another with a (relatively) simple markup language. No boilerplate code required on your application to operate conversion for client presentation purposes. XML in, XML out, XML in between.

Back then, in the early days of jQuery, I used to dream of an XSLT-based solution to generate and reuse DOM components.

Imagine that: an alternative timeline where no React, Vue or 200MB node_modules for transpiling were required, and everything relied on XSLT to transparently transform whatever markup synctatic sugar your frontend framework used into valid HTML.

But I guess that, especially now that XSLT support has been removed for good from Web browsers, we’ve diverged from that timeline quite a bit.

The death of #XSLT by the hand of #Google (again) is quite saddening.

To be clear, the last time I actively used XSLT was probably around 2010. But I still had an emotional attachment to this technology.

Maybe because one of the first bug reports I contributed to as a coder was this ancient Mozilla bug from 2001 which was about XSLT rendering (and btw it’s still open after 24 years, and since XSLT is now officially dead I don’t think it’ll ever be addressed).

Maybe it’s because one of the first iterations of my personal website relied heavily on XSLT.

My website back in 2007-2008 consisted in a bunch of XML files, which were rendered on the fly either as HTML or RSS feeds depending on the client. And XSLT was there operating this transformation behind the scenes.

I get it, the world doesn’t rely so heavy on XML as it did 15 years ago.

But HTML is a superset of XML. As those unloved RSS/Atom feeds are still XML.

XSLT provided the perfect glue to transform one into another with a (relatively) simple markup language. No boilerplate code required on your application to operate conversion for client presentation purposes. XML in, XML out, XML in between.

Back then, in the early days of jQuery, I used to dream of an XSLT-based solution to generate and reuse DOM components.

Imagine that: an alternative timeline where no React, Vue or 200MB node_modules for transpiling were required, and everything relied on XSLT to transparently transform whatever markup synctatic sugar your frontend framework used into valid HTML.

But I guess that, especially now that XSLT support has been removed for good from Web browsers, we’ve diverged from that timeline quite a bit.

Despite rumours, #XML, #invisibleXML ( #iXML) #XSLT, #XQuery all very much alive. They solve real problems and meet people’s needs.

native XSLT in the browser might go away. So applications like https://wendellpiez.github.io/PellucidLiterature/Amsel/amsel.scholia.xmll might stop working (made by Wendell Piez) which is sad but won’t affect large corporations and their revenue.

There is still no standard way to mark up a poem in HTML. No business case for it. But you can do it in XML with the #TEI.

#markupMonday

Despite rumours, #XML, #invisibleXML ( #iXML) #XSLT, #XQuery all very much alive. They solve real problems and meet people’s needs.

native XSLT in the browser might go away. So applications like https://wendellpiez.github.io/PellucidLiterature/Amsel/amsel.scholia.xmll might stop working (made by Wendell Piez) which is sad but won’t affect large corporations and their revenue.

There is still no standard way to mark up a poem in HTML. No business case for it. But you can do it in XML with the #TEI.

#markupMonday

XSLT RIP

https://xslt.rip/

#HackerNews #XSLT #RIP #XSLT #Legacy #WebDevelopment #TechNews #Programming

#Chrome's deprecation of #XSLT is just the next step in the decade-long efforts by #Google to kill an open, independent web (reminder that I've collected some of that history here <https://wok.oblomov.eu/tecnologia/google-killing-open-web/>). The #WebKit developers at #Apple or the prone #Mozilla developers agreeing on this choice detracts nothing from the argument.

#openWeb #indieWeb

There's an older parallel here for when #Mozilla helped #Google in their path to kill #RSS (note that this #XSLT is *also* about that) by removing the Live Bookmark feature. At the time, the excuse was that the implementation was incompatible with some important code changes that were happening at the same time, but the fact that support could be trivially brought in via extension showed that the issue there wasn't technical, but a matter of intent.

Note that the #Chrome team could trivially ship the polyfill itself and nobody would have even _cared_ about the change in the way #XSLT support was implemented in browser. This would have completely solved the “security” issue due to #Google leeching on a #FLOSS libraries without giving back. The fact that they haven't shows that the security issues in the libraries are just an excuse.

Any comment on this, @drott ?

This week I have been digging around in the #InternetArchive looking for digitised Arabic periodicals. With a bit of #Rstats and far too many hours with #XSLT and #TEI/XML spent on identifying titles based on the very patchy metadata provided by uploaders, there are quite some exciting finds.

The API returned some 4500+ items for the keywords "جريدة", "مجلة", and "صحيفة", of which I could identify 781 as pertaining to 100 individual Arabic periodicals published before 1930. Links to all of these have been uploaded to #Wikidata, which will increase their visibility to scholars and the interested public.

There are, of course, thousands of items for which I couldn’t programmatically establish a title with sufficient certainty, let alone try and link them to existing records without actually looking at the digital facsimile and reading the information provided on front-pages and mastheads.

Check out https://query-chest.toolforge.org/redirect/wnywBGxzyyiukWWYiIQqi0smeUCu6AggKG4mOME68i3 to see the results.

#ArabPeriodicalStudies #PeriodicalStudies #DigitalHumanities

This week I have been digging around in the #InternetArchive looking for digitised Arabic periodicals. With a bit of #Rstats and far too many hours with #XSLT and #TEI/XML spent on identifying titles based on the very patchy metadata provided by uploaders, there are quite some exciting finds.

The API returned some 4500+ items for the keywords "جريدة", "مجلة", and "صحيفة", of which I could identify 781 as pertaining to 100 individual Arabic periodicals published before 1930. Links to all of these have been uploaded to #Wikidata, which will increase their visibility to scholars and the interested public.

There are, of course, thousands of items for which I couldn’t programmatically establish a title with sufficient certainty, let alone try and link them to existing records without actually looking at the digital facsimile and reading the information provided on front-pages and mastheads.

Check out https://query-chest.toolforge.org/redirect/wnywBGxzyyiukWWYiIQqi0smeUCu6AggKG4mOME68i3 to see the results.

#ArabPeriodicalStudies #PeriodicalStudies #DigitalHumanities

Did you know #XPath 3 (2016) is a Turing-complete functional and declarative language? As are #XSLT 3 (which uses XPath and #XQuery which extends it). And #XProc 3 is a data flow language that also uses XPath.

These are widely used, powerful, efficient, and super pointy.

#XMLisUseful #markupMonday

Did you know #XPath 3 (2016) is a Turing-complete functional and declarative language? As are #XSLT 3 (which uses XPath and #XQuery which extends it). And #XProc 3 is a data flow language that also uses XPath.

These are widely used, powerful, efficient, and super pointy.

#XMLisUseful #markupMonday

chrome developers: we are thinking of dropping support for rendering RSS feeds as something other than garbage code. does anyone have any reasons not to do this?

developers from many different backgrounds: yes, I rely on normal people being able to understand RSS for my business. dropping support will be disastrous for me because I can't rely on people to have some random extension installed.

chrome devs: OK well we're probably going to do it anyway because we can't be bothered to support web standards. uwu google is only a teensy wee company uwu

https://github.com/whatwg/html/issues/11523

#xslt #standards#openWeb

Recently I got sufficiently annoyed at authoring posts in two places so that they were visible both here and on HaugenHus: Now – this is also in part because I prefer to write in Markdown which GoToSocial handles marvellously – that I decided to start looking at options. Of course there are many, but I chose to pursue an exclusively client-side solution with a static pageset to lighten the load on my little Raspberry Pi.

I landed on a solution built on HTMX + GoToSocial:RSS + XSLT which can be seen on HaugenHus: XSLT Test, but was horrified to find that after 26 years Firefox hasn’t managed to solve for HTML within an XML node. Of course it’s easy to get frustrated with a second-rate browser like Firefox 😁 – WebKit all the way baby! – but why bother when someone else has keep the flame war burning for 24 years Bug 98168 🤣. Of course with every ugly battle there are some heroes, and Scott Trenda was clearly one of these both offering a viable workaround and serving as a calm voice of reason.

So with a viable workaround to my XSLT woes, why haven’t I finished this little project? Well, there are two reasons: the first is that a workaround should never be allowed to become a permanent solution; and secondly, my WebKit enthusiasm may have been misplaced. It turns out that the fine folks over at Apple – @annevk – have expressed interest in killing my XSLT dreams 🥺.

With all of that said, what I found most interesting about this whole thing is that while I have been aware of XSLT for years, I unknowingly decided to play with it just as a storm appears to be brewing. Eventually I will get over my desire to minimize my dependence on JavaScript, but until then I’m sure there many other ways to solve this problem. I might just need to change the constraints.

(Maybe @gotosocial@superseriousbusiness.org would give us JSON Feed . . . feature request incoming after a bit more research 🤓.)

Additional Reading

XSLT Debate Leads to Bigger Questions of Web Governance

#Now #XSLT #Firefox #WebKit #GoToSocial #HTMX #RSS #JSONFeed