You can also style XML documents with CSS, like this:

    <link rel="stylesheet"
       href="style.css"
       xmlns="http://www.w3.org/1999/xhtml" />

That Lean Rada article is really fun!

Instead of:

    <script>document.currentScript.replaceWith(new Date().getFullYear())</script>

    <svg onload="this.outerHTML=new Date().getFullYear()"/>

Why does it have to be web-based? Discoverability? There's Minecraft and Lego. I discovered the CLI of MSDOS when I was a kid. It was a world to explore for sure.

There used to be pictionary online, web-based, which used Shockwave. iSketch I think it was called. There's probably alternatives these days, but I wouldn't know them. And regarding the Roblox issue: yes, some **heads were drawing ** pictures. Screw those people. This is what you get when you interact with total strangers. It brings the worst in people. How to solve that? Play with strangers-lite. Play games with people who are local to you. Yes, issues may ensue, but at the very least you can contact each other as parents.

Mozilla has announced that they intend to unship XSLT. https://groups.google.com/a/mozilla.org/g/dev-platform/c/ZRy...

I've been making Easel (https://easel.games) for four years so far! A place for teenagers to make multiplayer web games and share them with each other. Still a long way to go but this is the goal!

> What's the simple goto for making web based games that kids can mess around with? It was Flash, and now it's nothing.

Pico-8, Picotron, Tic-80, GameMaker, Godot all have simple web exporter.

Realistically, right now, it's Roblox.

Which is also a pedophile safe-haven (as proven by Chris Hansen and associates) so I wouldn't let my kids use it.

>What's the simple goto for making web based games that kids can mess around with?

Web games? Is that like Roblox on your school chromebook?

I think Roblox is the game design space for kids these days (though I would recommend parents to protect their kids from that game until they actually stop the paedophiles).

If you do want to target the browser, the sky is the limit. WASM has made any desktop game design platform compatible with browsers. Thanks to Ruffle, you can build flash games and they will even work on your iPhone, despite Steve Jobs' personal vendetta against Adobe's CEO.

RSS can have CSS stylesheets if you intentionally break the content type, so you can try your hand at making RSS feeds pretty. However, realistically, the kids aren't using RSS anymore. Browsers don't really support them, clients are run by stubborn people like me refusing to give up on what could have been, and RSS sources are dying out one by one.

HTML5 could have taken the extra step of defining a canonical XML or XML-compatible DOM encoding, or at least encouraged it. But the anti-XML sentiment was explicit and spiteful. Still, popular XSLT processors are built to consume and even produce HTML5, I'm just not sure how thorough those capabilities are or whether they're based on any formal or informal standards. (Maybe the W3C has/had something like that, as part of it's attempts to rollup HTML5 snapshots into versioned standards?)

I lost any enthusiasm for XML after my experience with WDDX and XML-RPC, but as a foundation for HTML it was the best thing going. And maybe still is, given the absence of cross-toolchain contenders? Ditto for XSLT, at least if disregarding the choice to make the syntax homoiconic. In fact I circled back to XSLT long after it was clear it was a dead end. A good tool is a good tool, and the fact it remains so despite the wanton neglect only proves it.

> XHTML was dropped in favor of HTML5 and XSLT was pretty much useless after that

Client-side XSLT was always pretty useless, but I dont see what HTML5 has to do with it?

The only real use case for client-side XSLT was for styling/layout back before CSS became widely supported. Improvements in CSS support made XSLT unnecessary.

i think xhtml happened before the wider world of web devs were ready for it. Component based architectures took longer to be adopted than I certainly expected.

It might actually work if reintroduced these days as long as we can consider many components to be valid documents.

The XSLT 1.0 spec specifically was written pretty badly, though, to my recollection; I had a hard time at making sense of it

And the rendering was very slow back at the day.

XSLT is not going away, it is only in-browser XSLT which is removed. If you are happy with XSLT there is no need to abandon it. Just perform the transformation on the backend.

Semi-serious suggestion: wrap the files in an (X)HTML page that links to a Javascript file loading a full XML parser compiled to WebAssembly, which then does the full transformation live, in-browser. You wouldn't need to change your templates or your generation logic much if you structure the surrounding skeleton right!

Of course, you'd need to get over the lunacy of loading a full DOM transformation library into the browser DOM.

Yes, because XSLT won't work in Chrome and Edge anymore.

A great way to convince you you've always been wrong:

Step 1: Gain browser monopoly

Step 2: Generate fake security scare

Step 3: Gaslight everyone that only way to mitigate is to get rid of it completely like Flash.

Step 3a (corollary): There isn't anyone available that can fix the bugs because we spent all resources on UI/UX experimentation

yes

> this was the only widely supported way to pull in shared bits of HTML like headers, navigation, and footers without anything dynamic on either end

Framesets. Not great UI though.

I'd consider getting your workflow running in wasm (in wasmtime on the server) and then you can migrate the same workflow to the client using the same wasm module. Nearly all LLVM based compilers can compile to wasm (WebAssembly).

In retrospect I really think it was a deliberate plan by IBM and Sun to turn software development into such an awful, impenetrable quagmire that they would be the only ones who could build and maintain any system.

> It works fine on Firefox.

For now... This warning is logged in browser console and devtools for your page:

> XSLT will be removed from this web browser soon. See https://github.com/mozilla/standards-positions/issues/1287

The obvious answer is that LLMs are not quite the machine gods they're marketed as, innit.

> what are the good reasons for dropping legacy code?

Reducing attack surface.

XSLT is rarely used, a significant attack surface, and the upstream libraries are riddled with vulnerabilities. LLMs make the problem worse by lowering the cost of finding new vulnerabilities.

Yea me too, not sure if hug of death or geo block

Style them with CSS. https://danfabulich.medium.com/beautify-your-rss-atom-feeds-...

Not style them?

Use css to style them instead?

The article says as much in the opening. It also includes a statement from Microsoft noting they do not intend to carry this forward separately, with a salient comment in one of the Microsoft page citations:

> For functionality and compatibility reasons, Microsoft Edge adopts nearly all of the Chromium project's changes to the web platform. However, Microsoft retains full control of the Microsoft Edge browser and may defer or reject changes.

Removed features don't always follow the same timelines either (and not just because of a lag in syncing to upstream Chromium).

Bless the Internet Archive for basically hosting a second copy of the internet with sufficient bandwidth to serve whatever is currently down, while this single site didn't survive the traffic it got individually

They were wrong about one thing: tooling matters.

The XHTML/XML/XSLT tooling was bad, and XSLT was hard to reason about. That meant that amateurs had no way to learn it, and those amateurs went to school and became the workforce.

The web became a winner because it was easy to get something working. And then Google made it a mission to make great developer tools in everyone's hands for free.

I think in 2026 we could build the tooling around a better experience, but it would require thinking about the developer experience first.

You could do some awesome things with XML/XSL. My favorite was RSS feeds or OPML collections of RSS feeds (both flavors of XML) calling an XSL transformation when viewed in a web browser instead of mined by computers for data; same with TEI files, although that was a bit more arcane. The idea was that you'd have one data file for machine use and a way to present that data to humans as a web page.

But, as a stack, the XML/XSL/XPath/etc combination was weak because XSLT was hard to comprehend and never updated. No browser supports XSLT 2 or 3; they froze support with 1. XSLT 2 was 2007, a year before HTML 5 was a thing, yet it never got picked up by browsers. Javascript was just easier to understand than XSLT. Development of XHTML was also glacial, and people wanted new tags, especially for video.

I can't help but agree, and sometimes I think about the alternate version of the web where XML realized its full potential as the dominant technology. The obvious problem with XML is that the syntax is so verbose and redundant that it's only barely human-writable, but this is 100% a solvable problem.

Is that really accurate? In a world where HTML5 never happened, how would XHTML/XSLT solve the same problems that modern front-end Javascript frameworks do (interactive data-driven websites)? I say this as someone who thinks XSLT is a really useful technology, and doesn't want it to be deprecated.

XSLT however has an absurdly steep learning curve, on top of it (like XML) being utterly verbose. There is a reason neither technology ever caught on outside of big enterprise or government projects.

yet people will say that HTML5 is all you need or something

So, this site breaks, we know that much