We are live!
The Workshop blog is finally up and running, in all its static glory. This makes the site practically complete, at least as complete as a website can ever be anyway. It also works great with my Multiblog plugin.
The Workshop blog is finally up and running, in all its static glory. This makes the site practically complete, at least as complete as a website can ever be anyway. It also works great with my Multiblog plugin.
At this point I could start to make rewriting my website an annual tradition. There have been a number of little details that have been rubbing me the wrong way for almost a year now; the biggest one was the navigation bar on sub-sites like the Grid Framework product site. There were also accessibility issues relating to the lack of a proper HTML document outline and the use of JavaScript.
If you were to run the Workshop through an HTML validator you would notice a lot of warnings about the document outline. What is going on here? HTML 5 defines an outline algorithm which allows browsers and assistive technologies to create an outline of the page. In theory a blind person could ask their reader for the outline of the page and get a sort of table of contents which they could use to quickly jump to a specific part of the page.
In the process of de-Bootstrapping the workshop I have to replace whole components provided by Bootstrap with my own constructs. The menu bar is one of the larger components I use, it’s fairly complex and requires a lot of non-semantic markup to get working. In this blog post I will describe step by step how I built mine, which requires less markup and does not rely on Javascript. You can try the demo to see what we are going for (please resize your window to see the responsiveness).
The first major step in phasing out the bloat that is Bootstrap from my website is done. None of the layout depends on any Bootstrap classes and markup. Instead, the layout is built from scratch using the new Flexbox and Grid features.
About a year ago I wrote about the first step in de-Bootstrapping my website, where I made my site layout independent of the Bootstrap CSS framework. I have now finally removed Bootstrap entirely from the website.
I got bitten by the Lisp bug recently again, and so I decided to clean up an ugly wart in my static site generator which I use for generating the Workshop. The goal was to create an embedded domain-specific language (DSL) for defining web pages.
In my previous blog post I presented how I had come up with an embedded domain-specific language for creating web pages in my custom static site generator. I also mentioned the concept of “templates” in passing. Of course it was only logical to follow the page DSL up with a custom template DSL to smooth over the code duplication and pattern repetition.
In January 2019 I switched the static site generator for this website from Pelican to a custom one written in GNU Guile. Most (or all?) static site generators out there have an opinion on what a website should be made of. You might have full control over the layout and content of individual pages, but not so much over how the web site itself is composed. Writing my own static site generator freed me from these constraints. Now if I want to have sub-sites and multiple blogs I can do so. However, the custom generator was suffering from the same problem: it had one specific web site composition in mind, it just happened that this time it fit my needs. That is why I have created HSSG: the Hackable Static Site Generator.
A while ago I announced my new pet project HSSG, the hackable static site generator. The final step of generating a web site is writing the actual files to the file system of the operating system. So far this has been a messy affair where information about file paths had to be dragged through the entire chain from start to finish. This was ugly, hard to maintain and it muddied the layers of abstraction. In this post I will explain how I brought order to HSSG through a file system abstraction.