Background / Story time
I have been writing/programming CSS/boxes today (where today = last Friday…) for a volunteer project working on the website for The Center for Artistic Activism (we have a cool CSS algorithm for image filters that I need to write about, too). Writing CSS in a Twenty Nineteen child theme is very different from my job-work which, as opposed to “writing CSS”, is more like writing project-agnostic CSS and building tools so that other developers don’t write new CSS.
Generally speaking with WordPress child themes, you are all but guaranteed to get into the weeds of specificity, hunting around theme style-sheets that you didn’t author, trying to figure out what existing declaration is preventing you from applying a new style, and then figuring out the least specificity you need to override it, and then thinking “Maybe it would be faster if I just wrote all of this myself”.
This experience is not unique to CSS. In any programming language, working in code you didn’t author is a recipe for large refactors and frustration – we (well, speaking for myself here, but I think we, as in most programmers, can relate to this) have a tendency to be very critical of other people’s code, especially if we are having trouble: “Ugh why would they do it this way…obviously this other way, that just happens to be my way, is SO much better. I’m going to re-write all of this, and everyone will definitely thank me later.” LOL.
So, there was definitely some of that going on in my mind. But with a CSS code-base, as soon as I am battling specificity, I’m like, “Yes, this other way (my way, developed over about nine years of CSS experience) is better”. Specificity breeds, much like conditionals breed in imperative languages (I believe I read that in Sandi Metz’s book, 99 Bottles of Object Oriented Programming). Adding specificity is adding conditional logic. Once you start adding that logic, the code-base snowballs and it becomes difficult to understand, and thus difficult to maintain.
The problem is…unless you are “a CSS person” this understanding of specificity and its impact on the future of the code-base is somewhat specialized knowledge. Should everyone who writes CSS be expected to understand these details? Maybe, but the more experienced I become in all kinds of development, I’m starting to think that’s an unrealistic expectation given how much other stuff we have to know as developers.
I had some thought-leadery thoughts related to the above cycling in my mind after working in that child theme CSS, and after seeing an outside agency struggle with our design system at work over the past few weeks. Here they are (unsure if I will actually post this as a Twitter thread).
(Internal dialog: Ohhh wouldn’t it be cool to make a Gutenberg block for these Twitter-threads-in-blog-posts!? And a special style for these “internal dialog” interjections that may become a pattern in future posts? Yes, Lara, it would be cool…but…no. Finish writing this post, sheesh.)
Twitter Thread (still needs some pruning if I decide to actually tweet it)
Problems with CSS are not a result of flaws in CSS. The problem is how we write CSS. We don’t think when we write CSS.
(take the use of “we” in this thread lightly, and to mean “programmers at large, most of whom are not CSS specialists”) 1/
The default mindset for CSS authoring is this kind of auto-pilot, “bang-it-out” approach: just get it to work or match the design or whatever and wash your hands of it.
“It’s just CSS”… get it done and get onto the real programming that is way more interesting and actually matters. (read this last line in very sardonic tone) 2/
WE HAVE TO STOP DOING THIS!! CSS *IS* REAL PROGRAMMING! OUR INTERFACES MATTER A F*&CKIN LOT!!! THIS IS HORRIBLE AND CAUSING SO MUCH PAIN AND WASTED TIME ON TEAMS!!!
And CSS is so freaking cool and interesting!!!!!! GarrhhhH!! 3/
But it’s no one’s fault, except capitalism’s. As developers in 2020, there is so much to do and so much to know. We need our tools, standards, and languages to make it easier for us to write different kinds of code. 4/
Languages provide varying degrees of structure and guidance out of the box, but when it comes to teams and the longevity of code-bases, order is ultimately maintained through standards, and tools that help us write code consistent with those standards. 5/
*CSS is no different.* It isn’t “just CSS” and it isn’t a broken language that can be fixed by making it more like other languages – it seems like that’s the intent of our most popular tools (availability bias: I am thinking Sass and CSS-in-JS tools). 6/
On the flip side, design tools generate CSS according to the visual design only. This sounds good in theory, but that machine-CSS is totally divorced from the rest of the code-base, and very difficult to maintain (see the part in this post about working in code you didn’t write) and is generally poor quality CSS. 7/
What if we took a different approach? CSS is a language for describing the rendering of documents…what if our tools and standards sought to bring CSS closer to that context? We manually test and debug our CSS in the browser’s developer tools…why do we rush to leave to a text editor? 8/
CSS only truly exists in a browser. As soon as we start writing CSS outside of the browser, we rely on guesses and memorization and an intimate understanding of the rules. A text editor will never be able to provide as much information as a browser can. 9/
I feel like the browser is where we should be working. Not a text editor, not copying from a design tool, and not piping CSS through build tools that fill in the gaps for us, but describing the rendered documents in the context of the rendered documents (a.k.a. programming boxes in the context of boxes!!). 10/
More thoughts coming…eventually…
More thoughts on this…later. But one more thing:
This paper, Ply: A Visual Web Inspector for Learning from Professional Webpages, by Sarah Lim, Joshua Hibschman, Haoqi Zhang, and Eleanor O’Rourke majorly inspired my thinking here, and I’m excited to research more of their work.
The paper identifies implicit dependencies as a critical challenge in CSS authoring, and that concept morphed into a FANTASTIC addition to Firefox Developer Tools, Inactive CSS that has helped me (and I’m sure many others) so many times! I still need to read the paper in detail, and then will potentially write more about it in a separate post.
TL;DR – When it comes to making CSS safer and easier to learn, instead of CSS-in-JS, maybe we would be further ahead contributing to dev tools?
Says the person who has never written one line of CSS-in-JS…😜