Theme Authors Should Be Able To Opt Out of Any Design Feature
As I debugged issues with the new block gap feature added in Gutenberg 11.4 last week, I found the ticket introducing it. And, there was already a new ticket for one problem I had hit. However, there was some discussion over whether themes should be allowed to opt-out, rolling their own solution. There was no way to do it at the time.
It felt like a no-brainer, something I would not think twice about. I quickly chimed in:
Should theme authors be able to opt out? If this is ever a question that comes up, the answer is always: Absolutely, 100%, yes!
With the introduction of the Gutenberg project and its evolving feature set, WordPress continues stepping into front-end design. This carries the benefit of standardizing the relationship between the platform, themes, and users. It makes things like block patterns universal, and it will continue doing so as we get into more advanced layout tools. This is a future that I am eager to witness because it will make theming much easier.
However, within the in-ticket discussion, I came across one of the fundamental rifts between some people working on Gutenberg and third-party developers:
I disagree with this take. This means that everything should be optional in WordPress and goes against the decisions not options. some things need to be options but not everything…I don’t think it should be a rule to have an opt-out for everything personally. For instance for structural styles, I’d rather have the themes rely on Core always instead of reinventing their own. Themes are here to bring personality and design but not to define what “horizontal alignment” means for instance.
If such a stance becomes one of the cornerstones of block theme development, it will turn many traditional themers away.
I agree with the principle that this should be the foundation, the default way that theming works in WordPress going forward. The more pieces that we can standardize, the better. But, as a rule of thumb, theme authors should be able to opt out of any design-related feature. Then, we make rare exceptions to that rule when the need arises.
Regardless of what Gutenberg and, ultimately, WordPress does, theme authors will find a way around it. Let us pretend that “horizontal alignment” is defined by CSS flexbox in core. I guarantee that someone will come along and use CSS grid.
In the case of the “block gap” feature introduced in Gutenberg 11.4, it is essentially a fancy name for a global top margin that gets applied to blocks (not to be confused with the actual CSS
gap property). In essence, it is a system for defining part of the default vertical rhythm.
This feature has long been on my wish list, but the idea of mandating it never crossed my mind. If you want to see a heated discussion, throw a handful of web designers in a room and have them discuss the myriad ways of handling vertical spacing between elements. I am in the top margin camp.
Fortunately, theme authors will be able to enable or disable the block gap feature. But, that is merely one battle.
I had planned to reply in-ticket, but I did not want to get too far off-topic. I also wanted to give some consideration to the other side. However, I could think of few instances where WordPress should always be the deciding factor on front-end design.
From that position, I envision little more than theme authors creating workarounds for what they will see as a broken system. There is nothing wrong with WordPress defining the defaults. However, it should always be from the mindset that developers will want to venture out. The best way to keep them happy is to not get in the way. Build a system that they want to use, not that they must use. And, for those who decide to go a different route, make it easy. Even if we think those rebel designers are creating a broken user experience, that is OK. It is their project to make or break.
What makes WordPress so uniquely WordPress is that the platform has always catered to those who want to extend it in just about any imaginable way. If it starts creating stumbling blocks that need not be there, we have done a poor job as stewards of the software.