I was sent this methodology and gave it a good read-through. There’s some bits that I can’t agree with, such as this:
“CSS is a designing language, not a programming one.”
I personally think CSS is a programming language that designers would benefit in learning, but I won’t get stuck on language because there’s some really good thinking in this methodology too.
I like this part about the understandability of CSS:
“thumbnail as-circle with-border” is instantly understandable while “h-10 w-10 bdr-50 br-1 overh” is not. Code should communicate information. The clearer the information, the easier it is to understand the system. Mistaken semantics should give way to expressiveness. Expressive best practices work.
I’m, of course, very CUBE CSS-pilled and utilities — depending on the complexity of the project — can be utilised quite heavily. I have certainly found that I’ve implemented more design token related classes, such as text-primary font-bold text-step-1 , rather than say, creating a light, handwritten utility/block like lede. Food for thought for me at least.
There’s a few more principles that I like too:
- Empowering designers to refine their work autonomously is efficient.
- CSS Selectors are vehicles for intention.
- Global scope in CSS is not a sin.
- HTML should be as simple and expressive as can be.
- Let the browser do as much of the rendering work as it can.
I think some of the rules are a touch opinionated, but I also like that in the whole, they encourage you to write understandable CSS.
All-in-all, will I look into ECSS over CUBE CSS? Probably not, but not because I think CUBE is better. More, CUBE works really well for me, my team and our clients. But, if that were ever to change, I think ECSS has legs for sure.