This is a response to this recent post from the core team: Core Styles and Theme Customization: the next steps. I strongly recommend reading it first as it does a fantastic job of laying out the landscape and the big issues that are facing the community going forward.
Let’s start with a quick recap of the post above: Controlling the front-end design of WordPress sites can feel like a bit of a hot mess these days. Between the default block styles, theme.json, various stylesheets from plugins and themes, and user-generated design tweaks inside the block editor, creating and keeping a coherent design system for a WordPress site is getting a lot harder.
Before the block editor came around, WordPress was almost completely impartial when it came to the front-end of your website. Theme developers had the ultimate control, from HTML to CSS. Sure there was some markup being generated in the old “Classic” editor, but for the most part what you saw was very basic HTML with maybe an inline style attribute here or there. Even those original dynamic blocks of content – shortcodes – were completely built and styled by plugin and theme authors. Disable your theme’s stylesheet and you really saw a fairly blank canvas reminiscent of the old CSS Zen Garden days.
As the block editor gets more advanced, and absorbs more control over the rest of the CMS, much more of the CSS on the front-end of the website is being provided by WordPress core itself. We’re hitting an inflection point where the community needs to pause and consider the options going forward, as the authors of the post above are clearly arguing. If we as developers are not going to have as much control over the front-end in the future, then it seems fair that we are at least asking for a more consistent structure to build off of.
It’s easy to be cynical and suggest that the Gutenberg team should’ve thought about organizing this earlier, before they deployed the page-builder on 43% of the web. However, I’m grateful for how open they’re being regarding the level of uncertainty out there. I enjoy watching them “bake” these tools in public, from dealing with the glaring accessibility gaps in the earlier iterations, to the concerns around meta boxes that had many of us clutching our pearls so many years ago.
These new questions regarding the state of CSS and styling are not actually new, but they’re definitely hitting a critical mass as the theme.json file and full site editing both start to reach maturity (we hope). A lot of great suggestions for these CSS issues have been trickling in, so kudos to the team for opening up space for this discussion. Iterating in public is not easy, but it beats stagnation any day.
Here’s a few high-level thoughts we’ve had while dealing with the block editor and the CSS it creates.
Block Themes are Not For Coders
The context for this entire conversation is that Block Themes are not actually meant for developers. Whether we’re talking about creating OR using Block Themes, they are not, in any way, meant to appeal to, be used by, or be built by, people who like to write code. If you’ve never created a block theme, it’s important to step back and understand this key distinction.
Block themes do not use any of the classic PHP templates to render content – they’ve replaced them with HTML files, albeit with helpfully matching filenames. For example, instead of single.php handling the design of an individual blog post, you have single.html.
The bigger difference here is that you can’t actually write the HTML inside of single.html yourself. These HTML template files have to be generated by the block editor itself, because they’re meant to be injected and processed by the block editor. If you were to write your own HTML for use in a block theme, it would not be able to be understood by the block editor. Believe me, I foolishly tried when creating my first block theme.
What’s important here is that any unique or custom HTML you want to include in your theme must be created as a custom block for use in the block editor. So your options for block themes are either no-code (build templates using existing blocks) or very high-code (build new blocks using React.js and a fairly hefty build process). Block themes basically jump over the ‘sweet spot’ that classic themes occupied: anyone with just a little knowledge of HTML and CSS could be dangerous enough to tweak it.
Once you enable a block theme, you typically lose access to the theme file editor (you don’t need it) and the Customizer’s CSS panel (you sorely need and miss it). Where WordPress used to be a step from no-code to ‘hey I’m learning a little code’, that transition is gone. But it’s not just the lack of custom HTML code that stings, it’s also the new methods for styling your themes.
Writing CSS as JSON Sucks
This probably falls under the ‘old man yells at cloud’ category, but building out the styles for a website in JSON instead of CSS is just no fun. It rubs against decades of familiarity with a language that has a very long history of successfully applying styles to HTML in web browsers. CSS is great, and with CSS variables pretty widely supported and heavily used in WordPress, it feels like there’s already a strong system in place for setting basic default style values without bringing in another machine-centric tool.
Abstracting CSS out to an almost unreadable object format is great for developers who are working primarily in JavaScript, but it’s really unintuitive for us “old school” developers who actually want to write some regular ol’ CSS when designing a website. Let’s leave aside the fact that class names in the block editor are still not stable between releases, let alone the lack of consistency among themes, plugins, and blocks. On top of that, we have the heavy reliance on the !important rule to deal with. When it comes to CSS, WordPress is turning into the high-end car company that makes it almost impossible to change your own oil, again edging out the hobbyists and tinkerers.
Some would disagree with that statement, arguing that the block editor and new features like the Block Pattern Directory actually offer more control to novice users. While that’s true, it’s within the stark limits of the block editor itself. What it does not offer is the true freedom of writing your own code. Think of it as “income inequality” for code – the “middle class” of users slowly learning basic HTML and CSS are being squeezed out by the “upper class” of developers who continually make things feel more controlled and more complicated.
Tangent Alert.
When Gutenberg was first being introduced, there were many in the community that wanted to see all of your post content saved as JSON in the database. Even I thought this made a lot of sense in the context of how the new block editor was going to work.
What we got instead was raw HTML with very unusual HTML comments that included serialized data about the blocks themselves. This felt like a weird and unpopular concept at the time – JSON just seemed like a much simpler way to store the content data, especially since the “truth” of the content actually existed more inside the JavaScript powering the editor than in the DOM itself. But I think WordPress ultimately made the right call: at the end of the day, your content is HTML, and it was important to keep it sitting in the post_content column as good old HTML that could be exported and changed and understood by any other CMS out there.
That’s why I am surprised that we’ve made it so difficult to write basic CSS styles for the block editor. I understand why the JSON file makes sense – we need to feed a lot of these decisions into the block editor so it can handle the many settings panels and color pickers. That’s logical, but imagine if instead of JSON, we could use something like SASS variables based off a standardized design template that ships with WordPress. Imagine if the final compiled stylesheet for all front-end design could be completely generated inside your theme (as in a classic theme) rather than requiring an extra layer of !important tags and ultra-specific selectors.
The fact that Full Site Editing actually hides the custom CSS option in the customizer (you know the one with the actual front-end, live-reloading preview of your site?) is a clear ‘shots fired’ towards our ability to write CSS and style our sites in a modular way. If you’ve ever had to update a font or color across a vast block-centric site, then you know what I mean.
Design Frameworks Exist, So We Know They Work
We were big fans of the Understrap open source theme framework even before we acquired it. For us, the ease of use with a framework like Bootstrap is well worth the criticism many developers hurl at the Bootstrap crowd. The utility classes solve many design problems in minutes, the documentation is great, and the familiarity means we can trade responsibilities and projects between developers pretty easily. Plus, with a decent build process built in, you can comment out entire sections of SASS/JS and end up with a pretty small file size.
Now, I’d never suggest that WordPress itself should ship with a library as robust and specific as Bootstrap, not unless I wanted to be torn apart by the ravenous gatekeeper wolves. Yet in many ways it really does feel like we’re re-inventing the wheel here, or that we’re circling the same unspoken conclusion that we all know is coming: WordPress needs a smarter, more opinionated design framework. Bootstrap is a decent frame of reference, and even something like Tailwind makes sense as a concept here.
WordPress needs consistent and reliable way to add custom – and I really mean custom – design flourishes to the core blocks. I’m not happy that we’ve come to this point, but once we’ve decided to build an entire page builder into the post editor, the separation of style and design from content has really gone out the window.
If you don’t agree, I’d like to point you to Exhibit A: the columns block. Turning back the clock, Bootstrap’s original killer feature was the great framework for grids using rows and columns. The fact that WordPress now comes with this feature bundled into core is pretty strong evidence that the block editor has some stronger opinions than in the past.
The reality is that building WordPress websites to meet a specific design spec has become harder with the block editor. Instead of writing HTML and CSS, we’re now jumping between HTML, CSS, JavaScript/React, JSON files, and the many, many buttons and panels of the block editor. I need a build process for my build process.
Many developers trying to deliver a website against a detailed spec and a hard budget find it very hard to make the case for the block editor for anything other than writing blog posts. Integrating the block editor requires more, not less, development time, and the benefits for our types of clients are still relatively minor. The block editor makes it pretty easy to get 90% of the way there, but almost impossible to get that last 10% of accuracy or functionality without some pretty heavy custom development.
I’m excited to see where this conversation leads us, and I’m optimistic that as the block editor matures, some attention will turn back towards that “middle class” of WordPress users: the tinkerers and hobbyists who tried to fiddle with some basic HTML and CSS, probably broke their website, and then ten years later have an entire development career thanks to WordPress.
