WordPress Themes and Web Development
Post from July 31, 2016 (↻ December 5, 2016), filed under Web Development.
In this brief episode about terminal code disease and maintenance trauma, the first thing I noticed were an exuberant number of
line-height definitions—77 when I searched, down from 165 in the Twenty Fifteen theme. The first thing I thought, then, was that there was not a single web project on this planet (that isn’t typography-related) that needed as many definitions for their leading—and that the WordPress theme style sheets felt just a little too WET, unnecessarily driving WordPress users to despair and complain (it happens).
But that was leading; working and poking further revealed many grave maintenance problems—Twenty Sixteen was not just WET (as the Atlantic, as I happily wrote in the first draft of this), but also presentational (from
.alignleft), verbose (leading zeros and such), and inconsistent (underscore as well as dash separators). The whole adventure spanned more than 6,000 lines, too, for a default style sheet and basic theme (cf. about 2,000 lines for Google’s entire reformatted Maia framework, or 1,000 lines for this site). Not intending a plug for a book, neither the usual pointer to maintainability guidelines, but noting that that was, sadly, lacking.
At this point I was torn between speculating—yet it should rather be the WordPress team to analyze what led to the different issues—and cheekily betting that anyone maintaining Twenty Sixteen was over-cautious and loathing, perhaps, to touch it. That suspicion got fed after having a closer look at another bad habit among web developers, the old reset fallacy—in its most beautiful form, namely the one that, on removal, demonstrates not only how inefficient but unnecessary resets (and “normalizers”) are:
And yet! There still are much worse style sheets than this. There are a few really good things to note in Twenty Sixteen, from structure to comments, and there’s a good chance of the theme developers simply paying tribute to complexity (when I said “basic theme” then in the awareness that for such a versatile tool as WordPress, there’s no such thing as basic).
Am I contradicting myself? WordPress CSS is bad, WordPress CSS is good? No. The particular problem here is that WordPress is so incredibly popular—an amazing success story—that code suffering from problems like the ones described, spread through thousands or more of installations, is troubling as are epidemics in physical life.
When we share code, and be it for skins and themes, we have a special responsibility: Such code, more than any other code we write, needs to be excellent. The least we want are problems like the ones mentioned to explode by overwhelming our less experienced peers and encouraging them to, for example, write little maintainable, “fire and forget” style code as well, or petition W3C folks to “do something.” So as always, you can tell, we have a rant with a positive twist, and I hope WordPress has some leads, at least votes for their bug requests, to investigate so to tailor and further increase the code quality of their themes.
I decided to use a general title for this post because of similar issues in other WordPress themes I looked at, standard themes and not. The title is still a hasty generalization, which means there may be other themes that are exactly as excellent as so requested.
I’m Jens Oliver Meiert, and I’m a web developer and author. I love trying things, including in the fields of philosophy, art, and adventure. Here on meiert.com I share some of my thoughts and experiences.
If you have any suggestions or questions about what I write, leave a comment or a message.
Have a look at the most popular posts, possibly including:
Perhaps my most relevant book: CSS Optimization Basics (2018). Writing CSS is a craft. As craftspeople we strive to write high quality CSS. In CSS Optimization Basics I lay out the, at least some of the most important aspects of such CSS.
Looking for a way to comment? Comments have been disabled, unfortunately.