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.