For reasons that this margin is too narrow to contain, I don't have the time to maintain a lot of my open source projects now.

I don't like to abandon them, however. I should have probably done this a few months ago but better late than never.

I'm looking for someone to take over Hardy and csste.st.

Hardy

https://github.com/thingsinjars/Hardy

Automated CSS testing framework. Back when I used to do CSS for a living, I got interested in the concept of visual regression testing. Not finding the right tool for what I had in mind, I built Hardy. It was quite popular for a while but has been quite neglected for about a year for various reasons. The main reason being that I don't actually write CSS any more. Well, not for a living. The tool worked for me while I needed it and when I didn't, I stopped updating it.

If anybody would like to take over the project and keep it going, get in touch.

csste.st

https://github.com/thingsinjars/csstest

This was supposed to be a community-driven collection of information about CSS testing - tools, techniques, tutorials, etc. I'd love it if it could continue like that but I had a difficult time keeping up my enthusiasm after the umpteenth demand from some "CSS testing as a service" start-up founder demanding a favourable write-up. Quite a few of these founders also wanted some kind of guarantee that I would continue to maintain Hardy for free so they could build a business model around selling it.

Again, if anyone has ideas for how to take the project forward, let me know.

---

I'm going to renew the domains hardy.io and csste.st for another year to see if I can find maintainers but after that, I'll retire them if I haven't found any.

Seeing as both Prolog and CSS are declarative languages, I found myself wondering if it would be possible to create a mapping from one to the other. It was an interesting thought experiment that quickly found itself being turned into code.

Way back when, Prolog was actually one of the first languages I learned to program in. It had been a while since I'd last used it for anything (a chess endgame solver in high school, I think) so I looked up an online tutorial. The following example is derived from section 1.1. of Learn Prolog Now

Simple rules

If you think of Prolog facts as denoting true/false attributes of elements, you can consider every known item in a KnowledgeBase (KB) as a DOM Element. For example:

mia.

Is equivalent to:

<div id="mia"></div>

While

woman(mia).

Equates to:

<div id="mia" class="woman"></div>

You can make multiple statements about an item in the KB:

woman(jody).
playsAirGuitar(jody).

Which is mapped to:

<div id="jody" class="woman playsAirGuitar"></div>

You can then represent these facts using visual attributes:

.woman {
  background: yellow;
}
.playsAirGuitar {
  border: 1px solid black;
}

The only real issue is that CSS values can’t be aggregated. If they could be, you could always use the same attribute (e.g. box-shadow) and combine them:

.woman {
  box-shadow: 1px 1px 0 red;
}
.playsAirGuitar {
  box-shadow: 2px 2px 0 red;
}

You'd want this to render two box-shadows, one with a 1px offset and one with a 2px offset.

Instead, you have to use a unique CSS attribute for each class of facts. However, for the simplest examples, It’s not too complicated...

If you want to query the KnowledgeBase, you need to map a standard Prolog query such as:

?- woman(mia).

Into the a different output mechanism: HTML.

The response is visualised in HTML and CSS using the following rules:

• There is an element with id "mia"
• There is a class "woman"
• The element with ID "mia" has the class "woman"

In the demo below, you can read this by verifying that the #mia div has a yellow background. Done.

Here's the complete KnowledgeBase for the first section of "Learn Prolog Now".

<!-- woman(mia). -->
<div id="mia" class="woman"></div>

<!-- woman(jody). -->
<!-- playsAirGuitar(jody). -->
<div id="jody" class="woman playsAirGuitar"></div>

<!-- woman(yolanda). -->
<div id="yolanda" class="woman"></div>

<div id="party"></div>

And here are the queries that could be answered by looking at the visual output:

?- woman(mia). 
Yes (the element with id="mia" has a yellow background)

?-  playsAirGuitar(jody).
Yes (the element with id="jody" has a solid black border)

?- playsAirGuitar(mia).
No (the element with id="mia" does not have a solid black border)

?- playsAirGuitar(vincent).
No (there is no element with id="vincent")

?- tattooed(jody).
No (there is no CSS style for a class '.tattooed')

?- party.
Yes (the element with id="party" exists)

?- rockConcert.
No (the element with id="rockConcert" does not exist)

View the output

More complex rules

It starts to get tricky when you have rules depending on other values such as

?- happy(jody):- playsAirGuitar(jody)
(“If jody plays air guitar, jody is happy”)

But I think some clever element nesting could handle that.

First, change the structure so that the classes/properties are on parent elements

<div class="woman">
    <div class="playsAirGuitar">
        <span id="jody"></span>
    </div>
</div>

Make properties into divs and entities into spans

Then update the structure of the rules:

.woman span {
    background: yellow;
}
.playsAirGuitar span {
    border: 1px solid black;    
}

Now you can make rules dependent using the cascade. First, add the property:

<!-- happy(jody):- playsAirGuitar(jody) -->

<div class="woman">
    <div class="playsAirGuitar">
        <div class="happy">
            <span id="jody"></span>
        </div>
    </div>
</div>

Then create the rule:

.playsAirGuitar .happy span {
    box-shadow: 1px 1px 0 red;  
}

The rule for happy(jody) will only be true (show box-shadow) if the rule for playsAirGuitar(jody) is also true.

View the output

Conclusion

Sure, it's all a bit silly but it was quite a fun little experiment. There are probably a few big aspects of Prolog that are unmappable but I like to think it might just be possible to create a chess endgame solver using nothing but a few thousand lines of CSS.

(I'm still taking a break from tech writing. There will be more in the future, don't worry. If you really need a web dev reading fix, I recommend Val Head's book on CSS animations and not only because I was the technical editor on it.)

Okay, How To Catch a Cold is still in the same state it was before (finished but unpublished) but the second of the three books I started is now finished, too!

This one is a children's novel about The Greatest Sea Captain the World Has Ever Seen. Gasp as he navigates his ship through the Floating Flames, be amazed at spectacle of a sea covered in Pink Cloudweed, hold your breath as he confronts The Dreaded Pirate Captain Montigus d'Ark!

I'll need to do a few rounds of edits before sharing any samples but this one was a lot of fun to write.

When I decided to take a break to write, I really should have been stricter with myself and only started one book. Instead, I started three. While multitasking and context-switching may be a good thing in the fast-paced, high tech world of the Internets (and I'm not convinced it is), there's a chance it's really unhelpful when you're trying to write a book.

That said, I have at least finished one of the books:

How to Catch a Cold

It's a pencil and watercolour illustrated story about a boy's attempts to avoid school by catching a cold.

Now to move onto the second stage of book writing: wallpapering my bedroom with rejection letters.