Cancel

Justin Tadlock

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!

The front end of a site is the theme author’s domain. Ultimately, they define how things work there. At least, this is how it has always been. Before the advent of the block system, there were cases where WordPress added its own spin to front-end features, such as styles for the gallery shortcode and emoji JavaScript-image replacement. Themes have always had methods for disabling those.

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.

Riad Benguella

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.

Category: ,
Tags:
20

20 responses to “Theme Authors Should Be Able To Opt Out of Any Design Feature”

  1. The front end of a site is the theme author’s domain. Ultimately, they define how things work there.

    I tend to lean towards the thought that the front end of a site is the user’s domain. They ultimately decide what’s what.

    In this new paradigm of Gutenberg and block themes, the theme builds upon the base provided by core, which can then be modified by the user (eventually through Global Styles).

    Create forum topic from comment

    • How can the front end be the user’s domain if core starts to decide which is the “right” way to create web layouts, with no possibility of change? ​

      To me, what this kind of decision seems to imply is that, in reality, the front end is now core’s domain and that anybody can be — or want to be — a theme designer, because all those boring details can be decided beforehand for them, with complete confidence and effectiveness.

      If that’s the case, this actually devalues a lot of the figure of the professional theme designer as we know it and will (possibly) remove a lot of nuance from this activity.

      Create forum topic from comment

  2. Hi Justin,

    Thanks so much for highlighting the discussion that started with the introduction of the global gap setting. To be honest, I’m still not sure what to think about it.

    From my perspective currently, yes a responsive global vertical margin setting can be a good idea for some default blocks, but I can think of so many cases that I don’t want to have this in my designs.

    In my opinion the block Editor brings the possibilities for more advanced individual designs to WordPress, so I see an issue with introductions of very generic settings that might become mandatory to use. That just does not sound great to me.

    I think themers, pattern designers as well as users should have the possibility to adjust any setting, but it should be the design creators choice to opt-in or out of a particular feature in their project.

    At least this is how I hope it will be, since as you said it should be possible to build anything we want with WordPress.

    Create forum topic from comment

  3. One thing to add is that I really think the idea of custom spacing values (as Rich describes here: https://richtabor.com/standardizing-theme-json-spacing/) in theme.json that can be applied flexible to a design system is super smart and helpful in my opinion.

    I think that somehow I still misunderstand the spacing setting in theme.json a bit, since I see the advantage of custom settings for sure, but I have difficulties with general settings applied (which will be opt-out now, as I understand).

    Maybe there should be a more detailed documentation on the settings in the Editor handbook?

    Create forum topic from comment

  4. Are we approaching a time when the “Default Theme” is the only one available for WordPress?

    Themes are built by (mostly) creative people. They offer the user a choice in how they want their website pages and posts to look. Why then would we want to limit what that user can do because a software default two levels up is take it or leave it? Do painting artists have a restriction on how many elements they are allowed on their canvass?

    Having too many unchangeable default settings simply stifles the creativity of the theme developer, and thus, the user. And limiting that creativity may one day cause many websites to have the same “look” – much more than some do today.
    –––

    Create forum topic from comment

  5. Quoting “I guarantee that someone will come along and use CSS grid.” is ironically related to a multi-tweet I did earlier today about the redesigning of my site and that I am getting fed up with flexbox for “columns”, media & text, etc. I discovered breakpoint issues in the core block styling…long story short, I had to override the flex for CSS Grid to give me more control.

    I would have posted a link to that tweet, as it does have a screenshot to show the issue(s), but wasn’t sure if I can do that here.

    Create forum topic from comment

  6. When I am designing a theme for a client I surely hope I am doing more than just bringing “personality and design”, and I sure do spend a lot of time considering the vertical and horizontal alignment within the design. Spacing is fundamental to design.

    I remain excited by the block editor, it’s the reason I stick close to core because I could invasion a theme experience I want to bring to clients that I couldn’t find with meta-fields or page builders. But I do worry that the experience will end up begin one of fighting the system and creating workarounds.

    Each time a new setting is introduced I also tend to think of the decisions, not options moto. It’s been my fear that we end up building out a system that’s a page builder equivalent ( I think there is plenty of space for that and plugin developers have shown they are the ones to do it for those who want it). I think having a base provided by core is a fine idea, but I also think it’s a good idea to be able to remove optional block settings as theme authors see fit. Part of the idea of theme.json that excited me was the potential for more granular control over those options. I run into this with the new margin and padding settings. While I would like a way to present theme users with some options to control spacing that fit within the pattern of the design ( block styles just aren’t up to the task ), I don’t want to present clients with manual spacing controls ).

    Create forum topic from comment

  7. As mentioned in the ticket, the inspiration for this “gap” comes via https://every-layout.dev/layouts/stack/, an iteration on the earlier Lobotomized Owl selector * + *. This approach is a super direction to go and my hope is Gutenberg’s CSS will start reflecting more of this type of thinking! Some nuance is definitely needed to allow for alternate gap values; the current implementation is a bit robotic by presuming all block types to benefit from the same gap value.

    The power of this approach will be diminished unless blocks are allowed to remain “dumb”. Dumb blocks work in harmony within the “stack” layout: a dumb block doesn’t need to know or understand anything about its place in the world, and it should never need to. No matter if there’s 1, 5, or 10 blocks on the page, in any configuration the layout can be automatic and predictable when managed with CSS that targets the context and not the individual block.

    In contrast, every time I see a request for “responsive controls” at the block level, I cringe. Baking in a margin value can make a block a little smarter by optimising it for a specific location and screen size. Rearrange a few of these blocks and a broken layout can easily be the result, requiring each block to have its personal margin be re-optimised.

    Very interested to see how this develops.

    Create forum topic from comment

    • Exactly, you hit the core of the problem and approach. Since we are just rolling out the initial container settings for blocks it will look a little rough until more nuance is added. There will always be escape hatches for more specific control, but we it should be deliberate.

      Create forum topic from comment

  10. To me, this statement from the blog post sums things up perfectly: “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.”

    Create forum topic from comment

  11. I just came to quote what Mr. Lilly just did, though I selected a smaller version: “Build a system that they want to use, not that they must use. ”

    Applies to WordPress, certainly, but so much more as well! Important attitude in so many areas of life.

    Create forum topic from comment

  12. I think a few cables got crossed in the conversation of the ticket! Ultimately, the idea for these container settings is that they absorb a lot of the concerns for laying out blocks, in turn removing a lot of the structural complexity from themes, but they should not remove control. The whole point, in a sense, is to provide more control but in a way that scales better and integrates better — block spacing is something that can act on all blocks, for example, even if you don’t know what blocks are present.

    In the current state it’s not refined enough to allow variations in vertical rhythm (headings are generally a good example) so it should remain opt-in. We might need to introduce a way for declaring different levels of baseline rhythm that blocks can declare and themes can control globally. Once this setup is final the hope is that themes won’t need to opt-in or out but merely configure a default and build upon it as needed. Of course, escape hatches will be necessary since absolute flexibility would be a requirement for multiple sites and setups. Once all is said and done we’ll need to show various examples of how a “normal” theme might be setup compared to a fully locked down one.

    A question of defaults is still relevant, though it might be more for themes showcased in the theme directory, in the sense that drastically different functionalities for users can be confusing when they switch themes and lose access to them, but I digress a bit there.

    For the next few weeks we’ll be establishing the major parts of design tools and global styles. Soon after a proper review needs to be conducted, including tweaking the defaults across all blocks (for example, what typography tools make the most sense to be present by default in a paragraph vs a heading). The iterative nature will mean a few things might need to start opt-in and move towards opt-out once things settle a bit more.

    Create forum topic from comment

  13. Each time a new setting is introduced I also tend to think of the decisions, not options moto. It’s been my fear that we end up building out a system that’s a page builder equivalent ( I think there is plenty of space for that and plugin developers have shown they are the ones to do it for those who want it). I think having a base provided by core is a fine idea, but I also think it’s a good idea to be able to remove optional block settings as theme authors see fit. Part of the idea of theme.json that excited me was the potential for more granular control over those options. I run into this with the new margin and padding settings. While I would like a way to present theme users with some options to control spacing that fit within the pattern of the design

    Create forum topic from comment

  14. I might be misunderstanding the issue, but can’t you already split the built core block styles and then dequeue them individually?

    Using something like: wp_deregister_style( 'wp-block-gallery' );

    Then enqueueing your own styles?

    Create forum topic from comment

    • We’re not specifically talking about a block stylesheet. But, that is actually a good example where core has made it easier to opt out of something, which is very much a good thing. I would like to see that level of granularity with any design-related feature.

      The primary example in this post outputs inline styles for all blocks. It’s a global top margin, and there was no way to remove it. This would force themers into a specificity battle and bloat CSS. Fortunately, they have actually made it an opt-in feature with the goal of eventually turning it on by default but allowing theme authors to opt out.

      But, the crux of the issue is that it was intentionally made to not be overwritable from the outset.

      Create forum topic from comment

  15. From a designer point of view (and by that I mean someone who understands and can handle CSS — not the type of ‘designer’ for example the Elementor marketing team seems to have in mind) I welcome every way and opportunity to disable Gutenberg/Block Editor features that offer design options, be they automatic (like that new gap thingy which is at the core of this thread) or offered by interface, like color options and such in the block options panel. I am very glad that in my themes I can at least by now control the color options (as an example) through the theme JSON file, and I am maybe just to blind to have yet found an option to entirely get rid of it, or any design related interface in the editor (I hope there will be an easy way, eventually). I love Gutenberg aka the Block editor, but I love it for the gift of easily building structure. I prefer to literally entirely control the layout through the style.css. Of course there are tricks, like dequeueing the core style sheets, but it would be so beautiful if there was a universal opt out option for anything design that is delivered through block editore core functions. As for the top margin, to be more on point: it is something, I never ever would do to get spacing above an element. I would always add padding to the element or a wrapper. So, regardless whether that is good or bad practice (I don’t believe, btw., anyone could convince me that it is a bad practice), I should be given the possibility to keep using that approach in designing my themes. Denying designers an opt out seems to me almost an arrogant approach from sides of the WP/Gutenberg dev team. Just my five cents, no offence …

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.