Comment by ndriscoll
2 months ago
I'm not sure how xslt itself is a downside. It's a pretty natural template language to use if you already know HTML. You don't need more than 1.0 for your simple use-case. e.g. here's a complete example (tested in Firefox and Chrome):
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="nav-menu">
<nav>
<ul>
<li><a href="page1.xhtml">Page 1</a></li>
<li><a href="page2.xhtml">Page 2</a></li>
<li><a href="contact.xhtml">Contact</a></li>
</ul>
</nav>
</xsl:template>
<xsl:template match="*">
<xsl:copy><xsl:apply-templates/></xsl:copy>
</xsl:template>
</xsl:stylesheet>
Then here's a page to use it:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="templates.xsl"?>
<html>
<head>
<title>Welcome to my page</title>
</head>
<body>
<nav-menu/>
<h1>Welcome to the page!</h1>
<p>This is the content</p>
</body>
</html>
Anywhere you want more templates, you add another
<xsl:template match="my-element">
<!-- HTML for my custom element -->
</xsl:template>
And now you can use your custom <my-element/> directly in your HTML. You can of course also have attributes and children for your custom elements and do all sorts of programming things like variables and conditionals with XSLT if you dip your toes in a little further.
As far as longevity goes, it's lasted 25 years now, so that's something. As far as I know, there are a bunch of government services out there that still use it (which is great! Governments should be making things cheap and simple, not chasing trends), so removing support for it is somewhat infeasible. If it were removed, you could always make a Makefile that runs `xsltproc` on all of your xhtml files to spit out html files, so worst case you have a build step, but it's the world's easiest build step.
One nice benefit of doing things this way is that just like with CSS files, the more you pull into the template, the smaller all of your pages can be since you have a single static file for most of the page, and each page is only its unique data. If you lean into it a little more and are building an application, you can also have each page be its own "API endpoint" by returning XML in your native domain model. Databases can also output such XML directly, so you can make highly efficient single queries to build entire pages.
for the record for anyone finding this in the future. this example works in firefox, but not in chromium. there it loads the page and the xsl stylesheet, but it displays an empty page.
a more elaborate example has the same results. chromium is empty. firefox works except that it looks like attributes to tags in the main content are ignored, which prevents css classes or links from working and images from loading. both work in the menu that is included from the template.
found it: the problem was that <xsl:copy><xsl:apply-templates/></xsl:copy> doesn't copy attributes. it needs to be:
oh, and the inspector doesn't work with my example, making this thing hard to debug. xsl support in the browser appears to be limited. and unfortunately, if i can't get it to work in chrome, i won't be able to use it.
you are right. xslt is not that bad. especially not for simple cases. your example would be just about enough for my website. thanks for that. i have used xslt before, but that was a long time ago.
however if you read through the comments there are a lot of people complaining, so they definitely see a downside to using xslt. as for longevity, well, a search led me to a chrome proposal to remove it that was made 10 years ago and ultimately rejected at the time. so maybe you are right about that too.