And it's done. It's over. The efforts to write an stylesheet to generate , and I mean actual sparklines, from an description of the activity in the Wok has finally brought fruit. The stylesheet I've discussed a couple of days ago has matured and is now able to generate graphical sparklines which are richer in information and lighter in weight than the previous pseudo-sparklines generated via a combination of shell scripting and awk, relying on the limited set of Unicode block characters for visualization.

You can now see it in action at the root index page as well as in any other index page (such as the Tech column index). If you want to compare this with how it used to look, here's a backup of the website index from the Internet Archive before the update that brought “real” sparklines into play.

The upsides

Although the final look is subject to change, there's already a few clear differences that jump to eye.

First of all, the sparkline includes both time series: the commits, and the publication dates. With the pseudo-sparklines, I used to generate both, but limited display to the commit series, because the screen estate that would be occupied by both series was excessive. Now the plot can be combined in a single double-sided sparkline.

I have tried to preserve the “year highlight” effect, adapted to the new format. I'm not entirely satisfied the result, so this may be subject to change, but at the moment it at least manages to convey the same information.

The time series is wildly different in some cases because of the start date: the old commits-series pseudo-sparklines started on August 2010, which is when I started working on the website structure a few months before the Wok went live, but the new “global” (root) time series goes all the way back to 2004, as it includes the articles I “dug out” from the archives of some of my past blogs. I will probably add markers to the longer time periods to show when activity started.

The single most important change, however, is that I can now afford to show the sparklines for each column in the index page: while the old pseudo-sparklines wrapped, taking up a lot of vertical space in single-column displays, the new ones plots designed to fit on a single line, stretching (or contracting) as needed. The root index can thus fit both the “global” sparkline, prominently, and each individual column sparkline under the corresponding heading —which was always the intended way to present these sparklines: I'm finally getting close to what I wanted in the first place.

The cost

Let's talk about bytes, both on disk and on the wire. First of, the stylesheet. Adding the features needed for the new sparklines has made the file grow in size, from barely more than 21KiB to well over 37KiB: that's almost 16KiB of extra weight, but then again, no effort has been made (yet) to minimize its size.

The sparklines themselves are a different matter: as previously mentioned, the old pseudo-sparklines were on average 30KiB each, for a total of 344KiB. The new sparklines are generated (all by the same stylesheet) from wrappers that are around 368 bytes long (4KiB total), loading data that is on average less than 5KiB (median 3.7KiB, the global index is an outlier at 14KiB), for a total of 54KiB for all series. The generated SVGs, on the other hand, are on average over 88KiB each (median 83KiB) for a total of over 973KiB.

So, on first load, the front page of the Wok (which itself is almost 1.2MiB) now loads nearly 3 times more bytes for the sparklines (from 36KiB to around 97KiB), but manages to show 11 times more information (sparklines for 10 columns plus the global series) with images that would have taken 10 times as much if generated server-side.

When any of the index data changes, the stylesheet itself is likely to be still in cache (unless modified since) scrapping its 37KiB from subsequent loads.

Even in the individual column index pages there are benefits, since the total size of the stylesheet plus the data is about half that of the generated SVG, even if 50% larger than the server-generated textual pseudo-sparklines. And of course, the cost of loading the XSLT stylesheet gets amortized over multiple page loads (on the site), doubly more so if there are other sparklines in the page.

The downsides

The main downside of this approach is that, since the SVGs are created client-side on page load time, users will experience a “repaint” as the page needs to adapt its layout to the final images. I haven't found a way to avoid this effect, but I'm open to suggestions.

There is also a matter of speed, particularly for larger sparklines: this is not an issue with the choice to use XSLT to generate the images client-side, but a fault in most User Agents, that have undeservedly neglected this aspect of the web platform.

This is an issue that presents itself in three ways.

First of all, the XSLT implementations in the three major engines (Google's Blink, Apple's WebKit, and Mozilla's Gecko) is over 20 years old, not particularly optimized, and bugged by the usual billion-dollar companies not contributing to the maintenance of the free software they rely on.

Secondly, their implementations, being old, are limited to XSLT 1.0, which is quite limited, requiring very complex implementations of features that are either built-in or trivial to implement in more modern version of XSLT.

Thirdly, their implementation being limited to XSLT 1.0 also requires the stylesheet developer to be exceptionally competent to write efficient implementations of the missing features —and I'm not a particularly competent XSLT coder (although, given the limited usage XSLT has, I wouldn't be surprised to find myself “high” in the list of web developers in general, XSLT-wise). Of course, the thing is that I wouldn't need to be particularly competent if the browser developers invested into bringing their implementations up to the latest language revision, instead of wasting inordinate amounts of development resources chasing user-hostile features such as ad-blocking-blocking or shoving “artificial intelligence” features down everybody's throat (from which we can surmise that the issue isn't lack of resources, but misplaced priorities).

Conclusions

I'm exceedingly satisfied for having managed to finally get sparklines in the Wok that look more or less like I wanted them to look since the inception of the idea last year. I will probably work on the styling some more, and probably add a few more features, but I can say that I'm much closer to my objective today than I was even just a month ago.

has confirmed itself to be an exceptionally well-suited language for web development, when even an amateur like me has been able to achieve such results in a constrained environment like the XSLT 1.0 that self-proclaimed “modern” browsers restrict the users to. Given what I've been able to obtain, and how relatively easily, I can't even begin to fathom what this language can do in the hands of an expert, or what could be achieved by anyone if more modern versions of it were widely available.

This experience of mine goes to confirm that the WHATWG antagonistic attitude towards in general and in particular poses a direct threat to the open and indie web, which would instead benefit from more recent version of the XSLT standard to be widely available in order to minimize server and bandwidth costs while providing a richer experience to their users and readers.

The WHATWG is trying to play the metrics game to justify deprecation of XSLT, conveniently forgetting that with the current size of the web (both server and client side) metrics as small as 0.01% for the dominant browser hide over a million people affected, when accounting for privacy-conscious users (which are also the ones more likely to visit less common corners of the web) and users of other browsers.

Do not let them win. Take this as an opportunity to play with XSLT yourself, and make it a staple of your indie website.

Keep the signal alive.

[Global sparkline for the activity of the Wok]