Google is killing the open web, part 2

Obviously not in every way. XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. It gives a very low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements. You link a template just like you link a CSS file to reuse styles. Obvious.

The equivalent Javascript functionality's documentation[0] starts going on about classes and callbacks and shadow DOM, which is by contrast not at all approachable for someone who just wants to make a web page. Obviously Javascript is necessary if you want to make a web application, but those are incredibly rare, and it's expected that you'll need a programmer if you need to make an application.

Part of the death of the open web is that the companies that control the web's direction don't care about empowering individuals to do simple things in a simple way without their involvement. Since there's no simple, open way to make your own page that people can subscribe to (RSS support having been removed from browsers instead of expanded upon for e.g. a live home page), everyone needs to be on e.g. Facebook.

It's the same with how they make it a pain to just copy your music onto your phone or backup your photos off of it, but instead you can pay them monthly for streaming and cloud storage.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

Functional programming languages can often feel declarative. When XSL is doing trivial, functional transformations, when you keep your hands off of xsl:for-each, XSL feels declarative, and doesn't feel that bad.

The problem is: no clean API is perfectly shaped for UI, so you always wind up having to do arbitrary, non-trivial transformations with tricky uses of for-each to make the output HTML satisfy user requirements.

XSL's "escape hatch" is to allow arbitrary Turing-complete transformations, with <xsl:variable>, <xsl:for-each>, and <xsl:if>. This makes easy transformations easy and hard transformations possible.

XSL's escape hatch is always needed, but it's absolutely terrible, especially compared to JS, especially compared to modern frameworks. This is why JS remained popular, but XSL dwindled.

> It gives a low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements.

JavaScript is a much better low-effort high-power on-ramp to templated web pages with no build steps or server software. JavaScript is the natural fit for adding custom HTML elements (web components).

Seriously, XSLT is worse than JavaScript in every way, even at the stuff that XSLT is best at. Performance/bloat? Worse. Security? MUCH worse. Learnability / language design? Unimaginably worse.

EDIT: You edited your post, but the Custom Element API is for interactive client-side components. If you just want to transform some HTML on the page into other HTML as the page loads, you can use querySelectorAll, the jQuery way.

This is patently false. It is much better for security if you use one of the many memory-safe implementations of it. This is like saying “SSL is insecure because I use an implementation with bugs”. No, the technology is fine. It's your buggy implementation that's the problem.

Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively?

I'd be willing to bet good money that the Venn diagram of users that fit the intersection of "authoring content for the web", "care about separating content from HTML", "comfortable with HTML", "not comfortable with JavaScript", and "able to ramp up on XSLT" is pretty small.

At some point, we have to just decide "sorry, this use case is too marginal for every browser to maintain this complexity forever".

I'm not sure what I mean by this, WRT XSLT vs Javascript.

The fact that the web's new owners have decided that making web pages is too marginal a use-case for the Web Platform is my point.

If someone wants to make a web page they need to learn HTML and CSS.

Why would adding a fragile and little-used technology like XSLT help?

That's what CSS does.

See all these "static site generators" everyone's into these days? We used those in the mid-90s. They were called "Makefiles".

XSLT is a functional transform language. The equivalent JavaScript would be something like registry of pure functions of Node -> Node and associated selectors and a TreeWalker that walks the XML document, invokes matching functions, and emits the result into a new document.

Or you could consume the XML as data into a set of React functions.

Admittedly this was 20ish years ago, but I used to teach the business analysts XSLT so they could create/edit/format their own reports.

At the time Crystal Reports had become crazy expensive so I developed a system that would send the data to the browser as XML and then an XSLT to format the report. It provided basic interactivity and could be edited by people other than me. Also, if I remember, at the time it only worked in IE because it was the only browser with the transform function.

But in the case of docs (eg XML-FO for docbook, DITA etc) XSLT does actually separate content from styling.

    <xsl:template match="abc">
      <def ghi="jkl"/>
    </xsl:template>

    CreateElement("def").setAttribute("def", "jkl")

This is a fantasy world that does not exist.

People used PHP, or a tool which created HTML (DreamWeaver), or a website, or maybe a LLM today.

And then you want to merely render this semantically rich document into HTML. This is where XSLT comes in.

Hi! I'm a non-programmer who picked up XSLT of my own volition and spent the last five-ish years using it to write a website. I even put up all the code on github: https://github.com/zmodemorg/wyrm.org

I spent a few weeks converting the site to use a static site generator, and there were a lot of things I could do in XSLT that I can't really do in the generator, which sucks. I'd revert the entire website in heartbeat if I knew that XSLT support would actually stick around (in fact, that's one of the reasons I started with XSLT in the first place, I didn't think that support would go away any time soon, but here we are)

A few years ago I bought a bunch of Skylanders for practically nothing when the toys to life fad faded away. To keep track of everything I made a quick and dirty XSLT script that sorted and organized the list of figures and formatted each one based on their 'element'. That would have been murderous to do in plain HTML and CSS: https://wyrm.org/inventory/skylanders.xml

I eventually started using server-side XSL processing (https://nginx.org/en/docs/http/ngx_http_xslt_module.html) because I wanted my site to be viewable in text-based browsers, too, but it uses the same XSLT library that the browsers use and I don't know how long it's going to be around.

Maybe! How much Javascript would I have to learn before I could come up with a 'trivial' solution?

> the hundreds of lines of XSL you wrote.

Those hundreds of lines are the same copy/pasted if statement with 5 different conditions. For each game, I create a table by: alphabetizing the XML > going through the list searching for figures that match the game > each time I find one go through the color list to find the color to use for the table row. There are 10 color choices per game, which means that I repeated a 10-choice if statement 5 times.

There's nothing difficult here, it's just verbose.

  <table>
  <tr><th>Skylanders figure</th><th>Note</th></tr>
  <xsl:apply-templates select="skylanders/figure[name/@series=1]">
  <xsl:sort select="name"/>
  </xsl:apply-templates>
  </table>

  <skylanders>
    <figure name="Hijinx" element="undead" series="3" note=""/>
    <figure name="Eye Small" element="undead" series="3" note=""/>
    <figure name="Air Screamer" element="air" series="3" note="Storm Warning"/>
     ...
    <figure name="Blast Zone" element="fire" series="2" note="Bottom only"/>

    <series name="Skylanders Giants" id="1"/>
    <series name="Skylanders SWAP Force" id="2"/>
    <series name="Skylanders Trap Team" id="3"/>
    <series name="Skylanders Superchargers" id="4"/>
    <series name="Skylanders Imaginators" id="5"/>
  </skylanders>

  <xsl:template match="series">
  <h2><xsl:value-of select="@name"/></h2>
  <table>
    <tr><th>Skylanders figure</th><th>Note</th></tr>
    <xsl:apply-templates select="/skylanders/figure[@series=current()/@id]"><xsl:sort select="name"/></xsl:apply-templates>
  </table>
  </xsl:template>

  <xsl:template match="figure">
  <tr class="element-{ @element }">
    <td><xsl:value-of select="@name" /></td>
    <td><xsl:value-of select="@note" /></td>
  </tr>
  </xsl:template>

  <style>
  .element-air      td { background: skyblue;      color: black; }
  .element-dark     td { background: dimgrey;      color: black; }
  .element-earth    td { background: saddlebrown;  color: white; }
  .element-fire     td { background: firebrick;    color: white; }
  .element-life     td { background: darkgreen;    color: white; }
  .element-light    td { background: ivory;        color: black; }
  .element-magic    td { background: purple;       color: white; }
  .element-tech     td { background: orangered;    color: white; }
  .element-undead   td { background: midnightblue; color: white; }
  .element-water    td { background: blue;         color: white; }
  .element-none     td { background: black;        color: white; }
  </style>

Then in your body area:

  <xsl:apply-templates select="skylanders/series"><xsl:sort select="id"/></xsl:apply-templates>

  <?xml version="1.0" encoding="UTF-8"?>
  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:output method="xml" indent="yes" />

  <xsl:template match="/skylanders">
    <skylanders>
      <xsl:apply-templates select="figure"/>
    </skylanders>
  </xsl:template>

  <xsl:template match="figure">
    <figure>
      <xsl:attribute name="name">
        <xsl:value-of select="name"/>
      </xsl:attribute>
      <xsl:attribute name="element">
        <xsl:call-template name="convert-element">
          <xsl:with-param name="code" select="name/@element"/>
        </xsl:call-template>
      </xsl:attribute>

      <xsl:attribute name="series">
        <xsl:value-of select="name/@series"/>
      </xsl:attribute>
      <xsl:attribute name="note">
        <xsl:value-of select="normalize-space(note)"/>
      </xsl:attribute>
    </figure>
  </xsl:template>
  <xsl:template name="convert-element">
    <xsl:param name="code"/>
    <xsl:choose>
      <xsl:when test="$code = 0">air</xsl:when>
      <xsl:when test="$code = 1">dark</xsl:when>
      <xsl:when test="$code = 2">earth</xsl:when>
      <xsl:when test="$code = 3">fire</xsl:when>
      <xsl:when test="$code = 4">life</xsl:when>
      <xsl:when test="$code = 5">light</xsl:when>
      <xsl:when test="$code = 6">magic</xsl:when>
      <xsl:when test="$code = 7">tech</xsl:when>
      <xsl:when test="$code = 8">undead</xsl:when>
      <xsl:when test="$code = 9">water</xsl:when>
      <xsl:when test="$code = 10">none</xsl:when>
      <xsl:otherwise>unknown</xsl:otherwise>
    </xsl:choose>
  </xsl:template>
  </xsl:stylesheet>

As I've said elsewhere, I like XSL for its beginner-approachability, so not doing a bunch of factoring is fine, but I also like it for its power: such factoring into simple templates is possible once you wrap your head around the idea (as with CSS). Using for-each or choose should be a sign you're doing it wrong. Ideally if you did your data model well, you just do simple template expansions everywhere.

I wouldn't say that I did it wrong, I just didn't do it efficiently. And I knew that at the time.

I appreciate the work, but I've said it elsewhere: I'm not a programmer. This was something I spent a couple of afternoons on five years ago and never looked at again after getting the results I wanted.

The thing about doing it wrong was meant as a reply to the comment upthread about for-each etc. being necessary. For something like you have, they're absolutely not. It's fine if that was the easiest way for you to do it though. My whole point was that I've always seen XSLT as much more of an approachable, enabling technology than modern JS approaches.

Less than the amount of XSL you'd need.

> Those hundreds of lines are the same copy/pasted if statement with 5 different conditions.

With a programming language, you could have used loops.

  <xsl:template match="series">
  <h2><xsl:value-of select="@name"/></h2>
  <table>
    <tr><th>Skylanders figure</th><th>Note</th></tr>
    <xsl:apply-templates select="/skylanders/figure[@series=current()/@id]"><xsl:sort select="name"/></xsl:apply-templates>
  </table>
  </xsl:template>

  <xsl:template match="figure">
  <tr class="element-{ @element }">
    <td><xsl:value-of select="@name" /></td>
    <td><xsl:value-of select="@note" /></td>
  </tr>
  </xsl:template>