WebComponents with XSLT
I’m a sucker for standards. Especially those more theoretical standards: peak theoretical standards era for the web is the era that promised the semantic web; early 2000’s.
Some history
In that time, the first version of this site was built using an XML-based index file, XML files that provided meta data on certain topics and XHTML files that featured the content. With PHP-code to tie requests and responses together, the site was mainly powered by several (big) XSL-Transforms that rendered the pages (it (c|sh)ould’ve been a static site).
Fast forward to today. While WebAssembly is gaining traction, these days the focus is on JavaScript for components. Popularised by frameworks such as React, new elements are defined in JavaScript that can be used in the DOM (the latter is not what React uses btw). The (promoted as) ‘standard’ way to make custom elements is using WebComponents. Yet this effort is driven primarily by Google.
And I’m still closing my <li>’s and write <br/>.
But the idea behind WebComponents is nothing new. From the history of the HTML spec:
The following year [1998, ed.], the W3C membership decided to stop evolving HTML and instead begin work on an XML-based equivalent, called XHTML. This effort started with a reformulation of HTML4 in XML, known as XHTML 1.0, which added no new features except the new serialization, and which was completed in 2000. After XHTML 1.0, the W3C’s focus turned to making it easier for other working groups to extend XHTML, under the banner of XHTML Modularization. In parallel with this, the W3C also worked on a new language that was not compatible with the earlier HTML and XHTML languages, calling it XHTML2.
This modularisation drive was put on hold when the major browser makers at that time (Apple, Mozilla & Opera) decided to focus on a more pragmatic approach, geared towards practical implementation and alignment of standard-interpretations by browser makers, which lead to more consistent rendering & a simpler path to adding new tags (and hence <nav>, <header>, <footer>, and <input>-types such as date, email were added).
Web developers started to forget about XML-technologies and adopted JavaScript as the language to fix all that browsers did not (yet) offer. Which is fine, except that everyone wrote components in their own quirky fashion. Hence frameworks/libraries arose that standardised this for some company or the other, and later shared with the broader web community. And while WebComponents are presented as the final all encompassing standard that should make the previous attempts at making components obsolete and/or old-fashioned, I started wondering what things would look like if we would’ve moved forward.
Enter: XML namespaces and XSLT
What if your ‘HTML’ could look like this to create a card with a button:
<my:card>
<header>
<my:h><em>This</em> is a card header</my:h>
</header>
<footer>
this is a test <em>footer</em>, don't you see
</footer>
<my:body>
<p>This is the <strong>body</strong> of the card</p>
<my:button onclick="alert('Yes?');">Push me.</my:button>
</my:body>
</my:card>
Which is then rendered to the desired output?
That is what XSL-Transformations allow you to do. Not only recently, but 20 years ago. I created a small demo just to prove that XSLT-Components could be a thing.
It works because of this header:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="xsltcomponents.xsl"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:my="http://murb.nl/demo"
>
<head>
(…)
The XML Stylesheet transforms the registered namespaces. In the xsltcomponents.xsl-file other XSL-files are loaded subsequently to copy all the standard HTML (base.xsl), render the card-XML to HTML that browsers grasp (card.xls) and a an XSL to render the button (button.xsl), here as an example (this additional <html:div> that is rendered around the <html:button> is there really for no good reason other than demonstrating that one element could become two nested HTML elements):
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:my="http://murb.nl/demo"
xmlns:html="http://www.w3.org/1999/xhtml"
>
<xsl:template match="my:button">
<html:style>
.button {
background: #000;
color: #fff;
border: none;
font-family: Helvetica, sans-serif;
line-height: 3em;
padding: 0 1em;
}
.button-wrapper {
display: inline-block;
padding: 3px;
border: 3px solid #000;
}
</html:style>
<html:div class="button-wrapper">
<html:button class="button">
<xsl:apply-templates select="@*"/>
<xsl:apply-templates />
</html:button>
</html:div>
</xsl:template>
</xsl:stylesheet>
Concluding notes
As I wrote above, this is all old, existing, technology. XSLT exists already since 1998, although if I remember correctly browser support was lacking for years, perhaps only IE was quite advanced in the early 00’s.
Note that transforming XML with XSLT is not what the modularisation effort of the W3C was all about; it was about creating separate standards-tracks that could evolve independently from the main standard, hence evolving faster. I think it is fair to conclude that HTML5 has proven that not to be a requirement. XForms never got serious support, but I can imagine how XForm-support could actually be ‘polyfilled’ using the approach that is used in the demo, and we got plenty of new tags and attributes/types to work with.
I like how the namespaces could allow for mixing and matching components form different authors / libraries. And how it works has all been there, for years. Working across browsers.
Disadvantages
- There is no shadow DOM; which allows for private styling and scripting of the components.
- The inline scripts and styles are not ideal; and will lead to CSP failures when their inline code isn’t on the CSP allow-list using a hash (not tested; might even be working if self is allowed)
But in my defence: my XSLT-compents is just a demo :)
Enjoyed this? Follow me on Mastodon or add the RSS, euh ATOM feed to your feed reader.
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .