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

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

Button state styling

Navigation overlay

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