Custom block supports and WordPress 7.1 responsive styles mode

[MichaelCampanella]

Hi Gutenberg team,

I’m working on a WordPress block plugin with several custom gallery blocks, and I’m testing the new responsive styles mode introduced around WordPress 7.1.

First, thank you for the work on responsive styles. I am really excited to see this, which feels like one of the last puzzle pieces in Gutenberg start to come into place.

I’m trying to understand the intended path for third-party/custom block settings that are responsive, but are not currently represented by core block supports.

For example, our blocks have existing custom responsive attributes such as:

• gap
• tabletGap
• mobileGap
• columns
• tabletColumns
• mobileColumns
• rowHeight
• tabletRowHeight
• mobileRowHeight

These are controlled through our own responsive inspector components and output as CSS custom properties/media-query behavior. In the new responsive styles mode, when switching to Tablet or Mobile, all of our custom inspector controls are hidden, while core-supported controls like Background and Dimensions remain visible.

I understand that the current responsive styles mode works primarily through the core style/block supports system. My question is:

Is there, or will there be, a public API for third-party/custom block supports to participate in responsive styles mode?

More specifically:

• Can a plugin-defined custom block support register responsive style properties that are recognized by the editor’s responsive styles mode?
• Is there a supported way for custom inspector controls to declare that they are responsive/device-specific, so they remain visible when the editor is in Tablet or Mobile responsive styles mode?
• Should plugins with existing custom responsive attributes migrate toward core style storage where possible, or is there a planned extension point for mapping custom attributes into the responsive styles UI/state?
• For settings that do not map cleanly to current core supports, such as gallery column count, preferred justified row height, or gallery-specific gap behavior, what integration pattern would you recommend?

I also wanted to share one concern from a third-party block developer perspective: hiding custom block controls by default when entering Responsive Styles mode may be confusing for users.

I can understand why this behavior works for core blocks, where the editor knows exactly which controls participate in responsive styles. However, many third-party blocks have shipped their own responsive control systems for a long time. If those controls disappear when users switch to Tablet or Mobile, it can make it look like the block does not support responsive editing, even when it does.

Would there be room for an API that allows third-party controls or custom block supports to opt into visibility during Responsive Styles mode?

@annezazu I’m tagging you because I heard you discussing this feature on a podcast. I know you’ve been closely involved in shaping and testing it, and since I’m newer to this community, I’d appreciate any help routing this to the right people or existing discussion.

[annezazu]

Hey @MichaelCampanella! Thanks so much for listening to the podcast and for taking the time to so kindly share your feedback. I really appreciate when folks go through the effort and time to create the necessary accounts, gather their thoughts, and risk sharing them with the world.

In terms of your questions, right now there is no public API for third-party blocks to opt into style states cc @talldan and @tellthemachines as they are the drivers behind this work and can help potentially incorporate it into future plans. You'll see on the prior link that there's this item:

Reintroduce block supports (removed in #78088) - allow blocks to opt in/out of global and instance styles. Consider any theme.json support for enabling/disabling style states.

Rest assured this is a known area but not one that's addressed for 7.1 in order to scope the feature enough that it could be shipped.

[tellthemachines]

@MichaelCampanella there will indeed be a public API for custom block tools to make use of responsive style states. Currently it's still taking shape, so it's still private and won't be available to extenders in 7.1.

If you'd like to see what it looks like currently, you can check Cover and Image blocks, which have a few custom dimensions controls where we're trying out some custom responsive support. We're planning to try this out on a few more core custom controls before making the API public, hopefully for 7.2. Also, any thoughts you have on the current private APIs and how well they might work for your use case are very welcome!