Responsive style states for blocks - 7.2 tasks

@gigitux

This succeeds the 7.1 iteration #77817

Public API for 3rd party blocks with custom controls ✅

The following functions from block-editor package would be useful:
useBlockStyleState( clientId?)
getStyleForState( style, styleState ) and setStyleForState( style, styleState, nextStyle ) isDefaultBlockStyleState( styleState )
hasViewportBlockStyleState( styleState ) and hasPseudoBlockStyleState( styleState )

Also getViewportMediaQueries( viewportSettings? ) from global-styles-engine would be handy.

On the PHP side, we might need a public wrapper for get_viewport_media_queries, given that the theme json class isn’t supposed to be used by extenders. (Props @gigitux for raising this question)

#82003 added a group="viewport" InspectorControls slot which can be used for custom controls, so that should be documented.

Counterpart block toolbar slot also needed: #82633

Add support for additional controls

From the lists below, I think Position and Custom CSS should be prioritised as being most useful to set per viewport.

Style controls yet to be supported

Settings that can be converted to style controls

Gallery

Columns (related: Gallery Block: Allow the number of columns to be maintained on mobile devices)
Crop to fit
Aspect ratio (draft PR: Enable viewport state values for Gallery aspect ratio #82233)

Cover

Fixed/repeated background and focal point

Media text

Media width
Stack on mobile (probably not relevant for breakpoint-specific controls)
Crop to fill/focal point

Social icons

Icon size

Avatar

Image size

Embed

Media settings: resize for smaller devices (probably not relevant for breakpoint-specific controls)

Advanced controls

Advanced > Custom CSS (Support for Responsive control for Custom CSS section Support for Responsive control for Custom Css section #80333)
Advanced > styles apply globally

Plus, the following are slated to be moved onto the Width block support (see #76525), which will make them per-viewport-editable by default:

Spacer

Height/Width (replaced with flex child controls if in flex container)

Search

Width

Site logo

Image width Site Logo: add width unit support (percentage, viewport units, etc) #49281

Other todoes

Replace hardcoded breakpoints in front-end CSS with more modular CSS #35848
Reintroduce block supports (removed in Update state support to use config instead of block supports #78088) - allow blocks to opt in/out of global and instance styles. Consider any theme.json support for enabling/disabling style states.
Responsive Styling – UX improvements - in particular, making clear which viewport is being edited seems the most needed change.

Adding some feedback from recent testing I ran on the current state of Responsive styling:

I was able to switch between the different responsive breakpoints from Global Styles.
However, I feel users have to navigate through quite a few options to access the responsive views. It would be great if this were easier to find and more intuitive.
Also, when switching between breakpoints, it would be helpful if the editor preview updated to match the selected breakpoint. At the moment, it continues to display only the desktop view.

Since we already display the current state name (for example, Mobile or Tablet) when switching between viewports, I think it would be clearer to always show the current state by default to the left of the three dot menu. This would make it more obvious that we’re editing the block’s styling for a specific viewport, and would encourage users to click the three dots button to explore what it does.

The state name also includes an (i) icon. I expected this to display a tooltip explaining what it means, but nothing appeared when I hovered over it. If the current state is shown by default, it would be helpful if hovering over the (i) icon displayed a tooltip explaining that the user is currently editing the block’s styling for a specific viewport.

When Responsive Editing is enabled, there is no persistent on-screen indicator. The only way to confirm it’s active is by reopening the dropdown. A small notice appears in the Block tab, but it lacks context that edits apply only to the active viewport. A persistent indicator in the grey border area (dismissable, reappearing when the setting is toggled) would help users stay aware of the mode.

@jordesign

Thanks @jordesign, I think some of these have been addressed to some degree, but might still be areas to iterate on.

I was able to switch between the different responsive breakpoints from Global Styles.
However, I feel users have to navigate through quite a few options to access the responsive views. It would be great if this were easier to find and more intuitive.

For global styles, there are some changes when using the in-editor sidebar (the one that's accessible via the 'styles' icon button next to the 'save' button). That now uses the editor's viewport dropdown control to toggle on responsive editing (Responsive styles: Use viewport dropdown to control states for in-editor global styles sidebar).

The global styles that's accessible via site editor's main menu doesn't change the viewport. It might be something to investigate.

The state name also includes an (i) icon. I expected this to display a tooltip explaining what it means, but nothing appeared when I hovered over it.

This is now implemented (Responsive editing: Add a Tooltip to the viewport / states badge).

When Responsive Editing is enabled, there is no persistent on-screen indicator.

The icon does now change color (Device preview dropdown: use active color for device icon when responsive styles are active). This is still quite subtle, so it's possible more can be done.

To respond to some other points:

I think it would be clearer to always show the current state by default to the left of the three dot menu.

Agree there is a disconnect with the positioning. The UI has to account for long translations, and some blocks support multiple states being active, for example users can style the hover state on mobile:

I don't think there's enough space next to the dropdown to adequately show the badges. Perhaps a simple solution is to hide the block description text whenever a state is active (a user probably doesn't need to read that all the time) and move the badges above the 'Show state on canvas' toggle.

I removed the Columns custom control from the list because Row/Stack/Grid blocks can be used to replicate Columns layouts and make them responsive. I also removed Column width because it should at some point be migrated to actual width support.

Some feedback on the public API section, from building a plugin on top of the 7.1 viewport states (Spacery, disclosure: I wrote it. It adds per-breakpoint padding and margin for sites that need more than two tiers).

+1 for a public PHP wrapper around get_viewport_media_queries. I'd add that extenders need the resolved viewport widths too, not only the query strings. On 7.1 with a theme that doesn't declare settings.viewport (Twenty Twenty-Five, for example), the defaults don't appear in wp_get_global_settings(), get_merged_data() or core's theme.json, so I couldn't find a public way to read them and ended up hardcoding 480px and 782px. If those defaults ever change, every plugin that copied them drifts without noticing.

Same story on the JS side. I rebuilt the (480px < width <= 782px) range shape by hand in both PHP and TS so my bands stay disjoint with core's. A public getViewportMediaQueries() plus the PHP wrapper would remove both copies.

On the positive side, useStyleOverride was enough to preview per-viewport styles in the canvas, and the override lands after core's block-support style, so ordering worked without tricks.

One question: is letting a plugin register additional viewports in scope for this API, or should settings.viewport stay the only source? It decides whether a plugin like mine should read core's list or keep its own next to it.

@moustakalis

Thanks for the feedback @moustakalis! The first iteration of the API work just merged in #82741. Currently we're focusing on allowing custom block controls to work with the existing viewports so it's still a minimal toolset.

One question: is letting a plugin register additional viewports in scope for this API

Not currently, but there has been discussion around allowing themes to configure additional breakpoints (that was why we started prefixing the viewport names with symbols in #79210).

Update

Public API for custom controls has mostly shipped; there's just a small change to the inspector slot name in review in #83539.

We've added support for new controls:

Position
Gallery custom controls: columns, crop to fit and aspect ratio
custom CSS is in progress in Enable style state-specific custom CSS #83539.

Progress on improving the UX/UI for responsive style states:

Style states: Improve block inspector UI #82649 has been merged.

What's still todo?

Further progress on the UX/UI problems, particularly in clearer flagging of when responsive editing is enabled.

We might tick off a couple more items from the list of style/settings controls still to support, but don't expect to finish the whole list for 7.2. Feedback appreciated on any items from that list that would be particularly desirable, so we can prioritise!

Further progress on the UX/UI problems, particularly in clearer flagging of when responsive editing is enabled.

For any design assistance or input you might need, please continue to ping @WordPress/gutenberg-design on anything. Thank you!

With 7.2 Beta 1 just released, I'll go ahead and close this. Further iterations will be tracked in #85243. Thanks everyone!

Great work all around for this 7.2 cycle 🚀

Navigation Menu

Repository navigation

Responsive style states for blocks - 7.2 tasks #80388

Public API for 3rd party blocks with custom controls ✅