Allow users to hide blocks based on various contexts

[ndiego]

This discussion explores adding functionality to Gutenberg that allows users to hide block content in different contexts. This idea stems from my Block Visibility plugin. While the plugin offers extensive features that go beyond what should be included in Core, there are specific elements I believe would be valuable additions, including:

• Hide: Hide any block in the Editor causing the block not to render on the front end.
• Screen Size: Hide blocks at specific browser widths (desktop, tablet, mobile). The blocks would still be rendered on the front end, but CSS would control visibility.

Starting with these two settings and making the underlying architecture extensible would provide valuable functionality to Core while also allowing extenders with an official way of adding their own visibility controls.

In my opinion, the first implementation of hiding blocks should be a boolean control similar to Figma and other design applications that allows you to simply show or hide any block. Ideally, visibility could be controlled in the List View, in the block options menu, and with a keyboard shortcut. @richtabor has an open issue for this in #50756.

Mechanically, I imagine visibility settings being an object assigned to a singular block attribute (similar to metadata, or could be part of metadata). If we used the metadata attribute, which is already being used for block bindings, I imagine the structure might look something like this:

<!-- wp:image {
	"metadata":{
		"visibility":{
			"hidden": "true",
			"screenSize":{
				"desktop": "true",
				"tablet": "true",
				"mobile": "false",
			}
		}
	}
} -->

There are plenty of open questions about how this type of functionality should be implemented. Here are a few:

• What will the UI look like for each visibility setting?
• If a block is hidden, what happens in the Editor? While it might make sense to visually hide the block in the Editor for the Hide setting or conditionally based on the Preview mode for the Screen Size settings, how should this work with additional visibility settings?
• Should you be able to configure which blocks have visibility controls? If so, should this be a UI or with a filter?
• How can we make this extensible and allow developers to turn off this functionality?
• Should this functionality even be in Core?

So what do you think? Feedback is welcomed.

[youknowriad]

A couple of thoughts, I like the sound of this.

• I think the "hide" feature from list view specifically is something we can tackle if we answer the following questions:
  • Should we hide the blocks in the "Editor" or add some kind of indicator or "Show them in a special state"?
  • Should the editor behavior be consistent regardless of which "visibility" option/config is used?

For the "breakpoints visibility". This is a cool feature but It has hidden complexities that we need to understand and tackle first. If I'm not wrong, we don't have any support for breakpoints in any of the blocks (frontend). This has a few implications:

• How do you define the breakpoints and are these statically provided? Can they be extended? The current ones are hard-coded and are editor-only, so less likely to require extensibility...
• What should be the format used in the block attributes (metadata or others later, think style)? (Also considering that the breakpoints might be something you define/extend)

[fabiankaegy]

Thanks for opening up this discussion :)

I will share that the hide-on-breakpoints option is going to be problematic for us in the custom development world if we cannot control the breakpoints.

[iansvo]

The breakpoints themselves could be easily filterable, however if they don't conform with the exact preview type then you can't preview them.

I know @richtabor has worked on a dark mode toggle that extends the preview selector so it seems entirely feasible to allow users to extend the preview mechanism to add more breakpoints and/or extend the visibility options to include other breakpoints too.

[ndiego]

Yeah, the hide-on-breakpoints (Screen Size) option is going to be far more complicated to implement and open up a lot of questions.

Perhaps the "Hide" setting is a good first step. We would still need to figure out the questions Riad mentions above, and in the process, we should be able to formalize the underlying architecture for hiding content.

[remkus]

While the plugin offers extensive features that go beyond what should be included in Core

You say this, but I can actually see it being merged and extremely useful in it's entirity.

[iansvo]

+1 here. Having a baseline Block Visibility API that is super flexible and blocks can perhaps opt-in or out of via support or some other mechanism would be super powerful.

Also, I think something like Block Visibility makes sense to be handled as a core, editor feature. The options for exactly what conditions make a block visible make sense as a plugin/add-on/extension but I think having a solid Visibility convention for all blocks would be a boon to developers and people extending the editor.

[mtias]

I agree! And if the entire visibility module is then itself easy to extend and add conditions to extenders would have a consistent interface to leverage.

[senadir]

Having this shipped as a UI primitive is super interesting as we're exploring this in WooCommerce as well. We have several blocks in our Checkout block that are conditionally rendered, but it makes it very hard to communicate that in the editor. Us, or developer, would choose to always render them in the editor, or never render them. Figuring our how a hidden block should be communicated, and also, a conditionally hidden block.

On a code level, we're looking to allow developer to show/hide fields in the Checkout conditionally (right now via writing a JSON schema), and would love to see how this matures to the editor. I'd expect that developers should be able to write the same "syntax" that the editor UI would output.

[TheJeffr0]

Thank you for starting the conversation on this. In the Block Editor, there are often a handful of ways to accomplish a specific look or layout. If I'm in the List View and want to compare solutions or see what a group or pattern looks like without a block, it requires me to remove the blocks altogether, removing any of the customizations along with them. Being able to Show or Hide blocks in the List View by clicking an Eye icon similar to Photoshop with layers is all I'm looking for.

[ndiego]

Yeah, thanks for sharing. This is my primary use for Block Visibility as well.

[bacoords]

There's obviously a lot of us who just say "merge it all" and if not, then "make canonical plugins a real thing" so advanced users can quickly enable settings like these without leaving the editor.

But I understand that's a pipe dream and probably not a realistic solution anyway.

It's currently a plugin and it works very well!

So my question for @ndiego is: what would merging this plugin into core mean for it's functionality? What can you currently not accomplish because this is a plugin and not a core feature of Gutenberg? That might change what parts get merged and what parts don't or are first built as distinct, extensible API components.

[ndiego]

So my question for @ndiego is: what would merging this plugin into core mean for it's functionality? What can you currently not accomplish because this is a plugin and not a core feature of Gutenberg? That might change what parts get merged and what parts don't or are first built as distinct, extensible API components.

Mainly two things:

• A more wholistic integration with the Editor, such as the hide icon in the List view
• An official way to handle hidden/conditional content in the Editor (rather than just throwing a border around it). This is something I have basically given up on solving in Block Visibility.

I appreciate the sentiment of those saying the whole thing should be included, but I believe the majority of the functionality in Block Visibility is plugin territory. But I do think there are elements that can and should be handled natively in Core, a simple Hide setting being the biggest one. If we do ever start exploring responsive controls, though, hiding blocks based on screen size seems like a natural inclusion as well.

[bacoords]

I think some of the features (i.e. hiding based on cookies, referrals, date/time, woo, etc) are definitely plugin territory, especially if an underlying API exists.

However, I would argue that the three core features are definitely basic visibility, responsive visibility, and almost anything you can do with a current conditional is_X() in WordPress, such as checking post/user meta values, current post type, taxonomies, and so on.

These are the conditionals that make WordPress a powerful templating engine, and I believe maintaining that specific goal in core is pretty critical.

In other words I think this could essentially be the framework for some sort of extensible Conditional Visibility API that mirrors what we can do with classic themes.

[ndiego]

In other words I think this could essentially be the framework for some sort of extensible Conditional Visibility API that mirrors what we can do with classic themes.

Yeah, this would be very powerful.

[jessedyck]

I would echo @bacoords that a lot of the is_X-style functions are great candidates. They go hand in hand with the site editor in my opinion, making it easier to create single, re-usable templates. For example, maybe we need to display a "CEO" label when the CEO posts an article, but otherwise the template is the same for every other author. Or we want to display a warning on pages that are tagged as 'archived'. These are all things we can do in classic themes easily but can't yet do (with Core) in block themes.

I would also suggest that we consider conditionals based on post meta. This becomes powerful to say "Display this heading block only when post meta X has a value", effectively making the heading block a label for a paragraph displaying a meta field using Block Bindings. Again, super powerful when building site editor templates that are reusable. I can't find it right now, but there is an open issue requesting the ability to add a prefix/postfix content to blocks using the Block Bindings API. I think this would be a better solution. The Meta Block Field does this via pre/post text fields, but its quite limiting in formatting and overall control rather than doing this via blocks.

I would also agree that leaving a lot to plugins makes sense. Any underlying API could allow, for example, ACF to add their own conditions based on their values. Similar to the Block Bindings API.

Not mentioned here yet: I also use Block Visibility to hide draft sections of published pages.

Should you be able to configure which blocks have visibility controls? If so, should this be a UI or with a filter?

Perhaps it should be opt-in via Block Supports? It should be possible to disable it via filters too, if it's not needed for a specific project or post type.

How this plays with the Block Locking API might need consideration, too. (I'm not sure if this is handled already in Block Visibility?) If a block is locked to prevent removal, that should probably also prevent hiding. That would be useful to disable hiding within a pattern, say if it has a custom class on the pattern's group block that (for better or worse) is expecting a certain number, or specific, child blocks.

[bacoords]

Not mentioned here yet: I also use Block Visibility to hide draft sections of published pages.

Same - this is a big part of my editorial workflow these days.

[mikemcalister]

However, I would argue that the three core features are definitely basic visibility, responsive visibility, and almost anything you can do with a current conditional is_X() in WordPress, such as checking post/user meta values, current post type, taxonomies, and so on.

I interface with a lot of FSE builders and end users. Not just users who are building simple personal sites or blogs, but also builders who are several levels deeper, trying to go full-scale FSE with client sites. This is one of the biggest missing pieces for them, especially the conditional checking of posts, users, post type, etc.

I recommend Block Visibility (and the Icon Block) alongside Ollie and users fall in love with the ease of use baked into this plugin, especially around checking against post/user, post type, etc. So many folks have said this would be a godsend for FSE adoption.

As @bacoords put it, these template conditional are historically what make WP theming so powerful. They make sense as a baseline experience if we move forward with this in core.

[youknowriad]

I was thinking about this proposal a bit more and I came to the realization that these two use-cases are actually different features:

1- Hide block entirely
2- Hide block depending on the viewport.

The first one can be used for privacy reasons, things not ready... So the block should never be visible in the frontend. So the processing should be done in the server.

The latter is a "style", the block should appear as you resize your screen or move your phone. So the block is actually always there and it's just CSS. You shouldn't have to reload the page to see the block.

Technically for me this means that the former makes more sense in block.attributes.metadata.isHidden while the latter is more a style and should be the style attribute and how we define responsive/breakpoint styles per block.

[senadir]

plenty of other constraints can (and should be done) server side. I think viewport is unique (instead of printing or not printing a block, it augments its classname or print down css).

[ndiego]

Yeah, viewport/screen size is a very different thing since it relies on styles. All other conditions can be handled on the server.

[bacoords]

It might make sense to hold viewport visibility until more attention is paid to responsive in core and there's a UI convention there that can be built on (even smaller things like centering text on mobile). All of that is going to require generating more CSS and potentially filterable breakpoints - two things that need to be done cautiously.

But hiding blocks (whether directly or based on templating conditionals like 'is_X()') can all be done server-side and would be a game-changer, as highlighted in the comments below.

[ndiego]

It might make sense to hold viewport visibility until more attention is paid to responsive in core and there's a UI convention there that can be built on (even smaller things like centering text on mobile). All of that is going to require generating more CSS and potentially filterable breakpoints - two things that need to be done cautiously.

Yeah, there are a lot more questions about how to implement this.

[sethrubenstein]

I wonder what, if any overlap, this work could have with also laying the foundation for Block States. Visibility, like focus, like hover, like a number of other conditions is really just "state" #57719 ?