I've mentioned before that I'm not satisfied (anymore) with for the Wok, but also that I haven't found an appropriate alternative yet. The net result of this is that I find myself pushing the limits of what IkiWiki can do, working within the limits of the system when possible, and hacking at it when not.

Last night I went through the former to bring more “semantic”, “modern” figures to Ikwiki, using the appropriate tags from (figure and figcaption) instead of hand-rolled classes for nested divs and ps.

I don't actually use a lot of images in the Wok, although things have started to change recently, and even if I haven't exactly shied away from hand-coded images, especially in the Mathesis, Ars and Ludica categories. In the more recent instances, I had actually already started manually wrapping figure tags around the standard IkiWiki img directives (for “internal images”) or hand-coded HTML for external images, in place of the (again, manually placed) div tags I was using (much) earlier, so the intent now was to automate it all.

I would have loved to replace the img directive with a figure directive that did the job for me, but IkiWiki doesn't really offer a way to define new directives without writing plugins, so I went with the closest alternative, which is templates. The only downside of this is that instead of a more lightweight [[!figure  …]] syntax I have to use the more convoluted [[!template id=figure …]]. I can survive.

The template is designed to be “flexible”, in that it should be usable in place of both the hand-coded HTML for external figures and in place of the “native” IkiWiki img directive —and even, for the few cases where this is necessary, for the instances where I use obj in place of img, which is for SVGs that would not render correctly as plain images (e.g. because of interactive features, or dependency on external resources).

What the template does is to open a figure tag, then choose “what” to include based on available parameters: if an img parameter is available, then an img directive is re-created (passing through any size, alt and title parameters to it), otherwise an obj directive is re-created if an obj parameter is available, and finally some hand-coded HTML is inserted using the src parameter (which should be present in this case), to produce an img HTML tag wrapped in a link (to the image itself, unless an href parameter is specified).

The nice thing about the template is that it also automatically reuses the title attribute not only for the image (or object), but also for the figure caption, which covers the most common cases. Of course it's possible to override this by specifying a caption attribute instead.

I've then gone through all of the uses of the img (and obj) directives and hand-coded HTML through the source of the Wok, replacing them with the template. I could have actually automated most of this, but I opted for doing it manually, taking advantage of the process to review many of the alt texts for the older images, turning them into proper descriptions rather than copies of the title attribute as they often were.

(I have the to thank for the deeper understanding I have now of the role of the alt text and how it should be used.)

The end result is that while the markup for the figures is now generally more compact than before (which was by and large my primary intention), sometimes the source files have grown larger simply by virtue of the new alt texts being longer than the bytes gain by simplifying the markup. At least it's a useful “weight” gain.

There is only one use case that the template doesn't cover yet, and it's the case of the picture element, that has been introduced in HTML5 to allow more sophisticated specifications of the images to use. I actually use this in the Wok as part of my initiative to support JPEG XL: the few binary images that are present on the site have both a JPEG XL and a (heavily crushed) PNG version, and they are placed in figure elements preferring the version and using the as fallback.

(I've actually had to hack IkiWiki for this, exporting the “best link” feature in a directive to ensure that links to the images in the source srcset attributes would resolve correctly both for main pages and for inlined content.)

A directive or template to replace the whole picture construct in the general case would be overkill for the Wok, so I can probably work something out for my specific use case (two images, same name but different extension, prefer JXL, fallback to PNG, although I should probably allow a JPEG fallback too). A template would be preferrable (hacking the IkiWiki source for something this specific doesn't feel like the right way), but at the same time the template system doesn't allow extensive string manipulation (for the curious, it's based on Perl's HTML::Template module), so it'll require some funky syntax if I want to support both PNG and JPEG as alternatives to the JPEG XL.

And of course this would have to be separate from the figure thing, since e.g. in two of the three uses (the 7SEEDS review and my Italian article on the unculture culture, the third case being my “Fediverse debate” comic) there are two pictures in the same figure. (Because . It's always 7SEEDS that makes it, for me.)

All in all, it doesn't seem worth it to look into this yet. At least until I start writing enough to overcome the image-to-text weight ratio issue.