It worked for me: https://imgur.com/a/Qccw9kT
On reflection, it’s also quite possible this is a platform-specific bug. I’m on Linux. I think I experienced it in Windows a few years back, but the memory is fuzzy.
… hmm, apparently if I start a blank Firefox profile this doesn’t happen either. Though I know I’ve encountered this with at least two completely distinct Firefox profiles over the years. This bears closer investigation.
Anyway, it’s still indicative of the disrepair of this feature set. It’s still used widely enough that I don’t think it’ll be torn out, but honestly on technical robustness grounds it could warrant being removed.
But I do share your frustration: the modern web seems unusable, unless you have a collection of extensions that block ads, annoying consent forms and the likes. But once you have these extensions installed, you basically lose all support.
Sometimes stuff breaks, and it works in a new profile even with the same extensions installed... and then what? You're supposed to throw away your profile with bookmarks, CAs, years of history etc.?
Its gotten to the point where I have multiple browsers as fallback. FF with lots of essential extensions > Brave with just a few > Unextended Chromium. A necessarily ridiculous state of affairs, but there you have it.
I can't reproduce your issue (on Firefox 115.7.0esr (64-bit) from Debian). I open it in a new tab with middle click and it loads fine immediately.
back in the day i built so many nice solutions for both web and internal services using XSLT as a key component. i also found it interesting that it was pretty easy for less experienced devs and particularly non-devs to pick up and make changes to. declarative programming has been much neglected sadly.
i'm intrigued by the combination of Assembly and XSL - any pointers to what you use those for?
i even thought SOAP was quite nice if you used the message oriented flavour instead of RPC flavour. REST was imo better and won out, but then nobody really does REST today and we seem to keep on re-inventing the wheel. am watching the htmx discourse with interest.
if your web service had a truly RESTful design then all you would need to do is point something like postman (or a browser) at it and it would be able to automagically figure out the whole set of available resources and interactions instead of having to use all this crazy swagger/OpenAPI stuff. there's a whole cottage industry around this api stuff rn.
i guess this is what happens when you put "programmers" in charge of a hypermedia system. everything becomes an RPC and nothing is standardised.
¯\_(ツ)_/¯
Even in its neglected state, it's got tons of features. You know how when Hacker News is having server issues, it tends to still work when logged out? Well you can just always serve the logged out page so it's cached for everyone, and then in the xslt template you can do an include of the user's data (that's right, you can directly include and query other xml documents in xhtml/xslt), e.g. <xsl:variable name="myinfo" select="document('/app/users/myinfo')"/> or something, and set that URL to private cache or no-cache, and then in the parts where you need the page to be different for the logged in user, you can e.g. compare '$myinfo/user/@id' to '@authorId' of a comment to decide whether to show an edit/delete button, etc. You basically get graceful degradation by default if it can't fetch that myinfo document. XPath is like jq that's been built into the browser this whole time.
The same thing can be used for things like subreddit side bars that are common across many but not all pages. You can even do an xsl:copy-of and serve it as xhtml. No need to send the same data over and over with SSR. No need to do client side routing or have any frontend tooling. It's all built right into the browser. The code is concise (it's verbose in the sense that it's xml, but it's still declarative) and easy to read. You can have a clean separation between backend sending the data in an xml model that makes sense for the domain, and then frontend having templates to present it.
The downside is of course that it all runs before the html for your page is produced, so you can't use javascript inside of xsl (unless you run a separate xsl processor in javascript), and it's about the same as SSR in terms of how dynamic it is (i.e. not interactive after page load, though you can of course have javascript in the output html). That and there's no info out there about how to use it because no one uses it, so you have to be a little creative. But it's been quite fun to see how much I can milk out of client side static template rendering using a technology that browsers haven't even bothered to update past 1.0 from 1999.
The first time I encountered XSLT I thought it was the most ridiculous thing to ever have been invented. A programming language written in XML?
but damn, the things you can do with that thing in a tiny bit of code. It was doing expression filtering years before anyone else, including the likes of Haskell.
Maybe what's needed is an extension to XSLT/XPath to consume JSON and transform it to XML.
it would be nice to see if fundamental xml tech can be improved in a new hardware and software environment. afaik, there hasn't been much if any innovation in that space in recent times. would love to know if there has.
I remember installing enterprise java beans to support my soap wsdl 16 years ago. Meanwhile shopify built a basic Rails app using http verbs and killed the product I was using.
It opened fine in Safari (macOS), and it opened fine in Chrome. Firefox did not apply the XSL file.
I tried to "view source" on both Safari and Chrome, and neither gave me the option. I could Inspect Element, and I got the HTML DOM, but not the original XML source. On Firefox, it showed me the XML file.
This surprised me. I was under the understanding that the browsers had effectively abandoned the XML/XSL concept any more. Apparently Firefox does.
It's also a shame the browsers stopped at XSL v1 as well, v2 is much better.
But, the browsers basically said "we're not in the XML ecosystem, we're in the HTML ecosystem".
The idea of downloading XSL, and then having a blog post that was little more than just content, with a wee bit of meta data, with all the chrome rendered locally via the template, I find that idea compelling. One less thing to download. More stuff to cache on the local system.
I had grand visions of an XProc pipeline terminated in the browser itself, but when I found out the browsers weren't really playing along anymore, kind of took the wind out of its sails.
It did for me. The "This is a list of blogs and news sources I follow." part of the page as rendered comes from the XSL file (opml.xsl). The actual list is rendered. I'm did not check whether the XSL was applied correctly, but applied it was.
> On Firefox, ["view source"] showed be the XML file.
Can confirm.
> The idea of downloading XSL, [...], I find that idea compelling.
> [...] but when I found out the browsers weren't really playing along anymore, kind of took the wind out of its sails.
Sad, yes, but for me Firefox did download the XML, the XSL, applied the XSL, and rendered the resulting page. I dunno why it didn't for you or GP, but maybe it's an add-on interfering? Do check, and please report, because I'm curious if the issue is add-ons.
edit: and yes opened the link on a new tab
The article is (as to be expected) very disparaging, but the author responded with valid points. Either way, a fun read and a blast from the past.
Loads absolutely fine for me on Firefox Nightly and on Firefox 122.0.1 stable on Linux.
The worst problem I know of is that loading an XML file with an XSL stylesheet into a new tab in Firefox just hangs. Has done for years, and I still haven’t searched for a bug report about it (surely someone’s already reported it). Try opening https://kmaasrud.com/blogroll.xml in a new tab (Ctrl+click or whatever), and observe the correct document title, but how the actual document area remains blank and the status bar says it’s still “Transferring data from kmaasrud.com…”. A quick Ctrl+R and it loads just fine the second time.