CSS works in weird ways. You typically want to have the least amount of CSS possible. You want to be able to add on the system freely. At a certain point in a bigger project's code lifecycle, things can become so entangled that trying to write new CSS becomes a fight.
Various attempts have been made to “fix” the problems with CSS, most recently by putting CSS in JS (ugh). The problem here is that re-implementations of CSS do away with what makes CSS powerful, which is the cascade.
The most interesting method of dealing with CSS is to compile CSS at the component level (like in Svelte). While interesting this ties the code to a specific framework, which is usually not what you want in a complex application using various technologies.
The way to fix CSS is to write proper CSS. But proper CSS, what does that even mean? It means writing CSS with conventions that are rigid enough to support working together.
It's writing CSS in a way that it can easily be removed and added across a giant codebase. It's writing CSS in a way that is portable.
But what are proper conventions? That's how we arrived at Ygdir. It's a set of conventions that can be used to write CSS in a way that avoids the problems of CSS at scale.
Ygdir builds on great work done by CSS experts such as Harry Roberts and Necolas Gallagher.
Ygdir was a codename for a CSS framework. I told him about my plans to provide a framework that was convention first. He came up with the idea that Ygdir could stand for: You gotta do it right! I liked that.
By no means do I want to tell people how to write their code. There is not a "single right way to do things". At the same time, there seems to be a lack of understanding of how CSS can work optimally in large codebases. As a CSS old-timer I have the feeling a lot of lessons from the past have to be re-taught again.
What is Ygdir for?
Applying the Ygdir conventions works best when you have to write CSS at scale. For example, CSS that powers hundreds of functionalities in a web application. CSS that has to be skinnable and that has to work in different contexts.
Writing code Ygdir-style might not suit everyone. You might not find a use for it. You might find it too strict. We welcome all feedback, to get to a version that is widely accepted. Also, feel free to fork it and make your own version of the rules. We would love to see which variants you come up with.