Blocks: States

[SaxonF]

What problem are we solving?

Websites are becoming far more dynamic, motion filled and interactive partly due to the evolution of front-end libraries like React and frameworks like NextJS, and motion libraries like Framer Motion as well as the View Transitions API. To remain competitive, we should start thinking about how to empower Gutenberg users to build similar sorts of experiences without needing to code. The Interactivity API has given us a foundation to build upon.

When you think about motion and interactivity a common concept is transitioning from one state to another. For example, an image on your site going from opacity: 0 to opacitiy: 1. There are other needs that follow similar concepts, such as styling a button before hovering and a button after, or how a section displays on desktop vs mobile. Although the navigation overlay spawned this discussion, the “why” behind this work goes beyond a single need. We are attempting to solve multiple problems at once, which brings us on to the proposal.

What strategy does it align with / why is it worth solving?

This a broad initiative that aligns with attracting designers, developers and low/no-code audiences.

What does the solution look like?

This proposal introduces the idea of “states” or “variants” as they known in other design tools like Figma. The idea is that any block, including synced patterns, can define properties. Combining property values create states. Each state is able to modify its style or contents. To transition between states, you attach a behaviour to either the block itself or one of its children. A behaviour consists of a trigger (e.g. “click block”) and an action (e.g. “set property a to xyz”). When transitioning between states we can optionally smartly animate between them (e.g. via view transitions API).

Animation

https://github.com/WordPress/gutenberg/assets/1072756/c3b75e58-2798-4554-9363-6bc242d2d8e8

The use of states go beyond interactivity though and could also be a mechanism for providing responsive behaviour per block. Consider a group that has an inner Row block. It has a “Viewport” property by default that emulates a behaviour of “when screen size is < 480 set viewport property to mobile” . We change to the “mobile” property and update the Row to a Stack.

Responsive

https://github.com/WordPress/gutenberg/assets/1072756/74c973b2-baae-483b-8049-4063bb4d46b7

Button state styling

https://github.com/WordPress/gutenberg/assets/1072756/8f8dcfd1-4075-451c-8788-2adf29ffe94f

Navigation overlay

https://github.com/WordPress/gutenberg/assets/1072756/7755e14a-0677-4c1e-9925-30043ca112e4

Blocks like the navigation overlay can wrap this experience into something a little more user friendly (or hide properties completely)

Use Cases

This creates a level of flexibility that can be used to solve many needs. A few examples:

• Button styling (interact property with values hover, focus, click etc)
• Navigation overlay (overlay property with values show or hide combed with viewport property to show/hide button)
• Tabs (tab property with values for each tab)
• Sliders (slide property values for each slide)
• Animations (e.g. move div from position a to position b)
• Contact form messages (status property with values of empty or submitted)
• Complex forms (e.g. show certain fields when others have been filled in)

What's the first thing we ship? (if larger than one release)

To begin to establish the idea of “states”, let’s first look at the button block and its hover, focused, pressed etc states. It may not require the interactivity API but we will be introducing the UX of managing states.

We can follow that up responsive controls and transitions between states (interactivity)

Tasks

I’d like to discuss what pieces of the puzzle are required to unlock this idea. For example, we need interactivity API and possibly the idea of behaviours. What else?

Previous discussion

https://github.com/WordPress/gutenberg/discussions/38108 https://github.com/WordPress/gutenberg/pull/44214#issuecomment-1637762117

[fabiankaegy]

Thanks for this exploration!

I'm a big advocate for introducing "States" to the concept of blocks and like the visual direction laid out here.

Something I'm unsure about is how the "viewport specific" styles fit into this from a UI perspective. Yes under the hood the method we use for storing these states may be the same. But I think it would be a better experience to tie the overrides for viewport specific settings to the actual viewport preview setting we already have.

It doesn't seem to make much sense to me to change the spacing of a component for a mobile viewport if the component isn't previewed on mobile.

---

Outside of the responsive pieces here I think it will be important for inner blocks / the block lists in general to also be aware of the state a block is in. For example the experimental form block is looking at failure / success states. The query block has no results found as a state etc. So incorparating that into the states functionailty I think will make a lot of sense

[paaljoachim]

This is very very fascinating and very important! As it can bring along so many new possibilites for creating the layout one wants.

What about adding Properties states as a panel? The contents of a panel is much easier to see compared to a drop down. How can we make it clear which state we are in? Thinking about visual hints for the user. So if one leaves and comes back one can quickly by looking at the screen see which state is currently selected.

EDIT. Check out this associated issue: Responsive previewing and device-specific editing https://github.com/WordPress/gutenberg/issues/19909

[landwire]

I personally would start with shipping Responsive Controls. That feature adds much more value to the editor than button states.

[sethrubenstein]

I was just going to mention how important this is and how clearly this could solve a huge foundational solution for #19909 but @paaljoachim beat me to it.

This concept along with work being done on inspector panel customization #33891, and the already available wp-on-window resize event handlers in the interactivity API, could solve the long running and very publicly discussed (negatively) lack of responsive controls.

Seconded with @fabiankaegy that a way to filter the viewport sizes available to core/editor.setDeviceType and getDeviceType are also necessary for a seamless editor experience.

[sethrubenstein]

Also, let me add, I agree, approaching buttons first IS the right call. core/button will obviously be a foundational block when using blocks with the interactivity api as a components-like system (it is for us). The states concept makes most sense to develop on form type blocks first, then responsive controls as the knowns are known for what states a <button> has.

[wnolfm]

@mtias Can we have your buy in on this issue? This seems to be foundational for major design tools and could impact the collaboration phase as well.

[bluebee-team]

Throwing our voice in with the group saying that core/button is crying out for states. I'd also add that for responsive UI we shouldn't ignore container queries. Viewport/media queries should definitely be implemented, but I wonder whether container queries should come first? They seem the more powerful feature to me.

[davidperezgar]

Why don't you make the context with the actual view? If you select mobile view, the values would be changed and keep them for mobile devices, like font size, margins, columns, etc. That's more intuitive and it does not create more interface that it wouldn't be needed.

[paaljoachim]

@davidperezgar David

It seems like an easy approach to use the correct device views to also become device editable states. It was the first thing a client asked me when she saw the different views. I had to tell her that currently it is only for viewing and one can not yet edit in these views, but I mentioned for her that I hope that would change.

[davidperezgar]

Yes, it's the easiest way. I'd add to add the device in the context so the user could see that is for a device layout.

[jasmussen]

That is more or less what is outlined in #19909, and it tries even to mitigate some of the challenges that come with that, such as forgetting that a particular block has has an override at a particular breakpoint, which is easy to forget. This is still an option, but a big UI challenge that's not as simple as it might seem.

The benefit of using states is that it's block-first vs. breakpoint-first, which would work really well with container queries. That would not only allow us to free from the three preset mobile/tablet/desktop breakpoints and allow any custom container widths presets you could specify, but it would solve the issue where if you insert a pattern that comes with preset queries, it would smartly adapt to any context in which it's inserted.

I.e. if you have a pattern meant to be shown in a full width column, which has viewport based media queries applied to it, and then insert that pattern in a 200px wide column, it's going to go splat. Whereas if that was container query based, it would work as intended.

[paaljoachim]

Continuing my line of thought... Along with device specific views there can also be a setting in the Group block to where the specific block is to be visible. Default it would show for all views, but then one could also select for Desktop - Tablet or mobile views with a specific icon seen in the Group block toolbar giving a signal as to where it is seen.

[tomtev]

@jasmussen is states (without UI changes) something that could be added to WordPress soon? This would allow developers to build and extend blocks with it, or experiment with UI ideas. It would also be beneficial if core blocks used CSS variables more extensively, so states could simply set CSS variables to override styles.

States really seems like the way to go for responsive explorations etc.

[jasmussen]

I do think it can be a good UI affordance for things like animation and even container queries, yes. Whether near term or not is hard to say, sometimes issues that seem simple at a glance turn into rabbit holes when all the edge cases present themselves. I'd tend to think the way this issue can be furthered is to outline, perhaps in Figma prototypes, the most basic of all use cases we can think of, and then get some input from a developer.

[carstingaxion]

This is very nice, to see some progress on this important issue!

I’d like to mention that @mikemcalister made some great and similar suggestions including some cool visuals. He is also using the existing device preview controls as a starting-point for handling state. This was in May 2023.

Before I found this issue, I thought about how and where to start with something like state and I came to the same conclusion:

The button block with its native states like :active, :focus, :hover or disabled, is the best block to start!

[carstingaxion]

For future iterations I would love to see state being usable to handle many things from containers-queries to user-preferences.

Additionally I can think of state as kind of conditional for the post-template block as well. I would like to be able to define different sets of inner-blocks depending on a taxonomy or the post type of the currently queried object. This could also help to bring back post-formats, I hope.

[jasmussen]

Related to hover/focus/current-menu item states, there's a new mockup here that's directly based on the work here.