CSS is hard and it should be hard. For good reason:
CSS isn’t just a complex language, it’s one of the most advanced graphics, layout, and typesetting languages available in computing.
The deskilling of web dev is harming the product but, more importantly, it’s damaging our health – this is why burnout happens - Baldur Bjarnason
Hard isn’t a negative label. You know what else is hard? Applying silicone sealant to waterproof bathroom fixtures. It’s hard enough that such expertise are worthy of a profession. Regardless, I decide it should be easy. I made a proper mess and my hands are now hydrophobic. Seriously, any tips applying this gunk?
CSS is deceptively hard as a whole despite many of the constitute parts being simple. CSS syntax is simple (mostly). CSS properties and values are simple (to lookup). What is hard is deciding how to organise styles. What we like to call: CSS methodology.
Methodology
Every developer has their own preferred methodology. Over the years we’ve seen many notable examples published — SMACSS, OOCSS, BEM, ITCSS, CUBE — to name a few. These methodologies have several things in common:
- Naming conventions
- Modular composition
- Cascade management
- Controlled specificity
The CSS spec does not dictate methodology. You are left to bring order to chaos. The correct methodology is the one that you and your team can adhere to.
Historically, I’ve used a basic BEM-like naming convention. I prefer flat specificity and a logical order to match the design hierarchy. I think component-first and avoid getting too DRY because I can’t control who is going try their hand at styling later.
Modern CSS is moving too fast to settle on one methodology. Custom properties allow design tokens to be part of the system. @container and @scope rules add a new depth to encapsulation. Cascade layers and the unassuming :where pseudo-class have all but nullified specificity wars.
As CSS gets more complex, I dare say CSS is actually getting easier (for a professional).
Strict methodological conventions become less important when the laws they impose can be safeguarded by the code itself. That frees us to explore more adventurous and less rigorous styles. Safe in the knowledge that any mess is more readily contained. CSS technical debt is a cheaper commodity. Some kind of CSS methodology is still necessary but breaking the rules is not the headache it used to be. Gnarly selectors are not the bane of my existence anymore.
Behold!
Now this is the point where you’re expecting me to announce my brand new CSS methodology with a trendy domain and a ten part TikTok series. Maybe a few practical code examples to backup my bold claims?
You’re going to be very disappointed. That is not this post.
I just think it’s neat to capitalise component class names like they’re proper nouns.
<article class="Post">
<h2>Hello, world!</h2>
</article>
<!--/Post-->Isn’t that fun? I find it adds clarity to a component’s scope. I even add an HTML comment after the closing tag so that source-spelunkers don’t get lost.
I do plan to write a more groundbreaking thesis on CSS one day. The world is not ready for my radical ideas yet and I’ve got a bathroom to finish redecorating.
Interesting tidbit from the original CSS level 1 specification (emphasis mine).
CSS gives so much power to the CLASS attribute, that in many cases it doesn’t even matter what HTML element the class is set on -- you can make any element emulate almost any other. Relying on this power is not recommended, since it removes the level of structure that has a universal meaning (HTML elements). A structure based on CLASS is only useful within a restricted domain, where the meaning of a class has been mutually agreed upon.
1.4 Class as selector - Cascading Style Sheets, level 1
class considered harmful!
Thanks for reading! Follow me on Mastodon and Bluesky. Subscribe to my Blog and Notes or Combined feeds.