I don't feel fully satisfied with the CSS of this blog. I handcrafted it from scratch, and while overall I like it, there are a few quirks here and there (like the spacing of list elements on some edge cases) that bother me. At the beginning of writing the CSS, it was feeling good because I was mostly targeting elements by type. However, as I needed to add exceptions and customizations, I began using child combinators with the types. Eventually, that was not enough, and ended also adding some classes and even targeting by ID.
This approach isn't inherently bad, but it made me realize that I didn't have a strong guideline for what type of selector to use. I was trying to target by type as much as possible because somehow it seemed to help to enforce using semantic HTML, which is a good thing. But that was it. All the other decisions seem too ad hoc.
Something similar is happening at work. We don't have any guidelines for writing CSS or HTML; we only have them for JavaScript. Additionally, no one on the team is a web design expert who could teach the rest of us. We have been using PrimeNG on most projects and dabbled a bit with Tailwind CSS on a few others, but the former just gives you some pre-built components and the latter a set of utility classes (which I have a gut feeling is not the right way to go). Neither of these resources teaches you about layouts or how to organize CSS properly.
I started doing some research and discovered two resources that I read during my last vacation. They not only seemed to be what I was looking for, but their approach and philosophy made me feel excited about writing CSS!
The first resource is the website about CUBE CSS. Citing the homepage:
CUBE CSS is a CSS methodology that’s orientated towards simplicity, pragmatism and consistency. It’s designed to work with the medium that you’re working in—often the browser—rather than against it.
Among other things, CUBE CSS proposes a methodology for organizing your CSS. I'm not going to summarize or try to explain what it is. The website itself does a better job than I would. And if you don't feel like reading, there are a few videos covering the same content. What I will do is highlight why I like it and cite some parts that resonate with me:
- It relies on the browser to do its job, in opposite of replicating/duplicating its built-in functionality like many try to do with a JavaScript-heavy approach to web development. It promotes the idea that the web is fluid and rigid layouts are destined to break:
The browser is hinted, rather micro-managed to do what it knows best in the context that it finds itself in.
- It doesn't force a library or tool, it's a way of thinking about vanilla CSS:
CUBE CSS is completely tool agnostic because it is more of a thinking and organisational methodology, rather than a tooling methodology.
- It acknowledges that CSS is not easy. It shouldn't be treated as a second-class citizen of the web, and to properly build good designs one must learn it properly, not avoid or hide it:
CSS is an incredibly complex programming language because a lot of knowledge is in how it works—not just how to write the syntax—which is understandably difficult when someone is used to other programming languages breaking and/or throwing errors, like JavaScript.
While reading about CUBE CSS, I found many references to Every Layout, and I realized it was a book I had seen often praised on social media and blog posts. This is the second resource I wanted to talk about.
I loved it. This book is not a set of CSS tricks or a bunch of pre-packaged code ready to be copy-pasted without thinking about it. It's a philosophy, a way of creating resilient layouts and making you write good and powerful CSS. As it is focused on layouts, it's a great resource to use when building the composition layer of CUBE CSS for your site. It assumes you already know the basics of CSS, so it's not for learning CSS from scratch. But if you have some basic notions you will have no issues following it.
I strongly recommend buying it if you are a web developer who does any frontend at all. Like before, I am going to mention some ideas and citations that I found very attractive and made me think "Writing CSS is fun!"
- It takes accessibility seriously. It is treated as any other design consideration, not as an afterthought.
- When coming up with sizes/proportions, it relies on delegating to an algorithm how to determine the value rather than hard coding it as a px-based width.
To design “adaptable pages” (Allsopp’s term), we must relinquish control to the algorithms (like text wrapping) browsers use to lay out web pages automatically. But that’s not to say there’s no place for influencing layout. Think of yourself as the browser’s mentor, rather than its micro-manager.
The layouts of Every Layout do not explore or prescribe styles for simple elements; that is for you to decide. It is the imbrication of simple elements into composite layouts that we are interested in here.
...it’s better to provide suggestions rather than diktats about the way the visual design is laid out. An overuse of @media breakpoints can easily come about when we try to fix designs to different contexts and devices. By only suggesting to the browser how it should arrange our layout boxes, we move from creating multiple layouts to single quantum layouts existing simultaneously in different states.
With all that said, I'm planning to rewrite the CSS of this blog and probably of my homepage using these patterns. I'll possibly write up how my experience goes after the fact. Wish me luck!