Skip to content
Daniel Shaw ยท WordPress & WooCommerce Developer Wellington, New Zealand

๐Ÿ‘‹ Not available for new client work right now!

A block editor theme called Maisie

Screenshot of an example layout for the Maisie theme
Cat image by Manja Vitolic

Now archived

Maisie was an experimental "full site editing" theme, natively supported by WordPress since its 5.9 release in January 2022. The goal for the theme was to serve as a base to extend rather than as an endpoint with a resolved visual design. The theme was never suited to a production website and has since been archived.

Maisie is an experiment

This is the first theme I’ve worked on unprompted by a content brief, because I’ve always struggled to understand speculative design that isn’t informed by real-world “content”1. Whether CMS- or theme-driven, technology-first approaches to composing layouts often result in a hostile user experience. This was always going to be a bit of an odd fit for me.

As a result, Maisie went through many iterations: from niche theme with highly resolved design, back to a starter theme with a bare minimum of default configuration, to where it finally landed: a solid head-start for the type of projects I work on but not so much as to require heavy revision per use. An initial plan to contribute to the theme directory was sadly dropped due to filtering the core function wp_render­_layout_support_flag(), required to adapt per-block generated styles to use CSS Grid properties.

Why do this?

The question Maisie poses is this: is it feasible to support, long-term, a block theme that has opted out of WordPress-provided CSS?2 While I genuinely appreciate the standardisation blocks represent, the gentle lock-in inherent in the multiverse of “classic” WordPress set-ups has been replaced by an approach to managing styles that sees the entire project slowly creeping towards becoming a walled garden.

For me, working with the block editor as intended currently feels like a major trade-off because the full expressiveness of CSS is lost. There’s a world of difference between composing a site within the constraints of the block editor and attempting to realise a 3rd-party design brief within those same tight constraints.

A simple example from many encountered when working on Maisie: a border UI control is natively available for various block elements. Assigning a border with a “primary” colour, style, and width results in the following being added to the block‘s markup:

  • Class selectors has-border-color and has-primary-border-color
  • inlined styles for border-style and border-width

The inlined styles mean the border setting is tightly coupled with the CSS border property. There‘s an immediate problem with this because, depending on the design brief—say, a motion effect on hover—it may be better or even required to use something like box-shadow to achieve the desired outcome. This creates a situation where a choice must be made between using the editor-provided border option and accepting a crippled design versus using a custom solution and opting out of allowing user control, though this is sometimes further complicated by there being no provision for hiding a native control if not required.

Marking a farewell to WordPress, kind of

At heart, Maisie is an attempt to “bend the tool”, something conventionally considered a bad idea in the software world. I would like to say it’s been a fun exploratory project but on reflection, despite a few small victories, it’s been the least enjoyable thing I’ve worked on.

There were a couple of goals I had when starting on Maisie: to help understand new opportunities and limitations of the block editor, and to finish with a flexible, production-ready theme as a starting point for building client projects. Upon completing Maisie—in so far as an initial release now exists—it’s sadly clear WordPress is no longer a suitable option for how I approach making websites.

The key issue

Modern WordPress is a moving target that's difficult to scope against, so development and maintenance costs have soared. This is an important issue for me because the majority of projects I’ve chosen to work on are those with small budgets which may otherwise have not had a chance to be realised.

There have been some promising signs recently, with small but significant shifts in direction arising from increased sensitivity by the Gutenberg team towards real-world design & development requirements. There’s also been an increase in visible discussion around concerns that have been bubbling away since the new editor launched in WordPress 5.0. What ultimately remains troubling for me is that, despite closely following the project closely for ~5 years, I still cannot clearly see where this is all heading.

From here

Maisie will continue to be nurtured as a hobby project and a point of contact with the WordPress project. I’m curious as to whether a time will arrive where:

  • the theme breaks irreparably
  • the overlap between theme and block editor development aligns enough to feel comfortable building a project using Maisie

More broadly, I’ll no longer be starting new projects with WordPress, instead shifting focus to maintenance and feature work for existing websites.


  1. Such a horribly reductive term. โ†ฉ
  2. This is something I’ve already been doing for most of the custom client block themes I’ve written. It‘s proven more challenging long-term to manage CSS that dramatically extends core styles than writing custom styles from scratch. โ†ฉ