Outline for Block Behaviors

[mtias]

• Part of Block API #41236.

This is a rough overview for exploring how we could connect the active proposal for frontend block interactivity with user configuration within the editor. (Read the proposal for more background on the interactivity API.)

Behaviors are meant to be reusable and composable interactive hooks that can be attached to blocks. The intended outcome is to alleviate the need for extending blocks themselves (or needing to create custom blocks) to provide augmented experiences across block types. It also aims to provide users visibility and control. These behaviors can range from simple things like lightboxes to other more sophisticated effects. The essence of it is that they don't exist in the blocks themselves but can be attached to them, either programatically or by users. It should be possible to define them at a block type level (all image blocks get a lightbox behaviour) and on a per-block instance (this specific image should not get a lightbox behaviour). Other types of behaviors are what we have in the navigation block (open in overlay modal) which should be applicable to other blocks.

What this issue focuses on is on how we could structure and present reusable declaratives (i.e. "behaviors") that can be registered and attached to blocks by a user using the editor UI. Allowing composition of these behaviours is an important consideration of the design.

How behaviors themselves are built is not covered here (that's part of the interactivity API), only the declaration and UI aspects.

---

Overview of implications on the interface:

• Available behaviors should be selectable in a panel on the block inspector (probably under Advanced to start with).
• Behaviors should not trigger on the editor (but they could trigger on preview states, like "browse mode").
• Global styles should be aware of these on its block type specific pool.

Outstanding questions:

• Initially behaviours could just be opaque (no configuration) but we might need to explore configuration aspects.
• It should be clear if a block is inheriting behaviours from its block type.
• Whether specific behaviors should be lifted up in the UI into more prominent block specifics settings (for example, if lightbox is important, that it can be accessed more easily than in an advanced panel). This rests on solving whether behaviors is a more consistent access point for other types of controls.

---

This is still exploratory in nature, with a focus on figuring out how single image lighboxes could work as a stand in use case.

[michalczaplinski]

I have some questions and concerns to help us figure out the right UI for the Behaviors and make sure we’re solving the right problem.

1. What is the problem that Behaviors are trying to solve? What are some use cases?
   We would benefit from a longer list of potential use cases for the Behaviors. The ones that I have seen mentioned so far are:

   1. Lightbox (PR)
   2. “Show in view” behavior
   3. Dynamic time difference

   I would like to have a longer list of use cases so that we can be confident that the Behaviors are the right abstraction and that we’re not building a general solution to only solve narrow use cases.

2. Customizing behaviors

   1. Behaviors should work across block boundaries. As currently specified, a behavior attached to some block A has to be contained to this block A . The following behaviors would not be possible:

      • I want clicking a button to show/hide another block.
      • I want the lightbox behavior to be triggered when clicking an “Enlarge” button in addition to when clicking the image itself.

      The most interesting user interactions are not constrained to a single block but happen when the user “clicks somewhere” and then “something happens elsewhere on the page”.

   2. Customizing the “trigger” of the behavior, e.g:

      • I want to open the lightbox on hover instead of on click.
      • I want to trigger a popup to subscribe to my newsletter after scrolling X% of the page (an annoying but common pattern for sure 😅).
      • The same example as in point 1. above: I want the lightbox behavior to be triggered when clicking some “Enlarge” button in addition to when clicking the image itself.

   3. Configuring/parameterizing the behaviors

      Consider an “analytics” behavior that sends some data to an analytics endpoint whenever a performs an action. At a bare minimum it would require a way to configure that endpoint in the block editor and define on which action to send the event: click/hover/focus, etc.

3. Reusability and composability
   I foresee that there will be ways in which behaviors will be subtly incompatible across different blocks unless they are made to be flexible from the very beginning. For simple interactions restricted to a single block like “lightbox”, there is probably no problem. However, as soon as we’re talking about Behaviors that can work across blocks (which I would argue are the most interesting and useful ones), we need ways to attach them to multiple blocks and define ways in which they’re connected, etc.

4. Other CMSes and no-code builders like Bubble, Webflow and UIflow approach this problem in a different way: using triggers and actions. Is this approach something that was considered?

   (video to show you what I mean with triggers and actions)

Overall, my main concern is that only shipping “single-block”, “single-trigger”, and "predetermined" behaviors is of limited value, and we should think more broadly about the use cases and the capabilities that we want to unlock! I think it should be possible to first ship very restricted “single-block” & “single-trigger” behaviors but then gradually find ways to incorporate custom triggers and parameterize the behaviors.

(thanks @SantosGuillamot for pointing out to me that we can work on the Behaviors in a progressive, gradual way)

[artemiomorales]

Related to #49972

[SantosGuillamot]

I like the idea of differentiating between "Behaviors" and "Triggers" and exploring the possibility of triggering behaviors from different blocks. For example, showing a popup when clicking on a button. Apart from that, it'd be great if behaviors are extensible somehow, and external plugins can easily add a behavior to an image for example.

This seems to be the ideal scenario for me, providing users with a lot of flexibility and power. On the other hand, I feel it should be done cautiously, and it requires a lot of thought, especially in terms of UX and composability.

I believe we can start with just behaviors that have the trigger "hardcoded" in a single-block and look for ways of abstracting it later. We just have to make sure that whatever we do now, doesn't lock these possibilities.

What is the problem that Behaviors are trying to solve? What are some use cases?

Regarding this, some examples that come to my mind, although I haven't thought too much if behaviors is the right mechanism for them:

• Infinite scroll in Query Loop block.
• Typing text effect.
• Instant search in the search block.
• Dynamic progress bar.
• Animations for modals or accordion block.

And I can imagine people being creative with behaviors. That's why I feel that providing mechanisms to let them add behaviors to existing blocks could be powerful.

[michalczaplinski]

I believe we can start with just behaviors that have the trigger "hardcoded" in a single-block and look for ways of abstracting it later. We just have to make sure that whatever we do now, doesn't lock these possibilities.

Agreed :)

It seems that it’s too early for the discussion about adding “triggers” and “targets”. 🙂 For now, we can just move ahead with the implementation that is needed to ship the Lightbox (#49621). Working on it in #49972.

• Infinite scroll in Query Loop block.
• Typing text effect.
• Instant search in the search block.
• Dynamic progress bar.
• Animations for modals or accordion block.

Nice, thank you for this!

[michalczaplinski]

It looks like there is a general consensus that we should first go ahead with a very minimal implementation of behaviors that is only scoped to the core/image block. The initial implementation should be (broadly speaking) only concerned with:

• Integration with theme.json & block.json. Whether the UI for enabling behaviors should be present can be defined in the theme.json and is inherited but overridable in the block.json.
• Basic UI to add/remove the behavior from the element. For the moment, there is only one behavior, "lightbox" that can only be added to the Image block.

Below are details provided earlier by @SantosGuillamot in a private discussion so that we can continue discussing them here in public:

---

Behaviors UI (excluding the Global Styles UI)

• Setting: Themes can turn on or off support for the behavior UI in the theme.json under settings.blocks.core/image.behavior.lightbox.

  • By default it is turned on in the core theme.json file.
  • It can be overwritten by a theme's theme.json.

• Behavior: Themes can add or remove the behavior functionality by default to all the image blocks under behaviors.blocks.core/image.lightbox.

  • By default it’s added in the core theme.json file.
  • It can be overwritten by a theme's theme.json.

• Users can add or remove the behavior from a single image block.

  • Add the attribute to the block.json.
  • Save it in the block attributes: <!-- wp:image { “behaviors”: { “lightbox”: true } } -->

Read the blocks.core/image.behavior.lightbox setting with useSetting() hook. If enabled, add the UI in “Advanced” panel: dropdown with the list of behaviors (user could also select “none”).

• Documentation:
  • User - Explain how to activate the behavior and what it does.
  • Theme.json - Explain how to activate the UI or not, and how to set a default value.

It's difficult to explain the difference between the setting that controls whether a site can use the behavior or not, and the default value of the behavior, so we tried using a drawing. We are not super happy with the outcome, but here it is:

Global Styles UI (not required at the beginning)

These are preliminary instructions based on how the Effects panel works, but it’s not exhaustive research of what needs to be done. This may not work for our use case, so you may need to do additional research and do some things differently.

Also, the Effects panel is enabled using block supports (shadow: true), but we won’t use block supports yet. So we have to figure out how to integrate that.

• Add Behaviors panel to the block-editor package

  • Inside components/global-styles, create a behaviors-panel.js file (like the effects panel).
    • It reads and updates the settings.
    • It creates the layout to change the settings.
    • It exports the component.
    • It exports a useHasBehaviorPanel hook.
  • Export it in the index.js file (like in the effects file)

• Add the Behaviors panel to the edit-site package

  • Inside components/global-styles, create another behaviors-panel.js file (like the effects file)
  • Import the other component and use it.
    Add styles in the style.scss file.
  • Create a ScreenBehaviors component (like the screen-effects component).
  • Add the ScreenBehaviors into the global-styles UI file.
  • Add it to the global styles context menu.

[cbravobernal]

Also, the Effects panel is enabled using block supports (shadow: true), but we won’t use block supports yet. So we have to figure out how to integrate that.

Is there any reason that I could be missing of why not using block supports?
My first impression is that it would fit like colors, shadows, etc, allowing us to enable all behaviors or individual ones by block easily while maintaining coherence with the rest of features. Also, I think in that case, we may also not need a global option to enable or disable all of them at once.

[gziolo]

Also, the Effects panel is enabled using block supports (shadow: true), but we won’t use block supports yet. So we have to figure out how to integrate that.

Is there any reason that I could be missing of why not using block supports? My first impression is that it would fit like colors, shadows, etc, allowing us to enable all behaviors or individual ones by block easily while maintaining coherence with the rest of features. Also, I think in that case, we may also not need a global option to enable or disable all of them at once.

The challenge here is that for design elements, there is everything in place to dynamically modify the block so the color, shadow, margin works out of the box. You would need to figure out how to modify the block externally so the lightbox seamlessly integrates.

[hanneslsm]

I just tried to get my head around this topic. I'm not a technical expert, so excuse the stupid questions.
But if I'm understanding it right, plainly said, the Block API basically gives the possibility to program stuff, right?

As a designer I'm thinking about how a good UI and UX for that could be created. What instantly comes in my mind is something like Scratch. This is a clean interface and we could also work with triggers and behaviours, but in a much more scalable and in a intuitive way than inserting this all in the editor like in Webflow. I'm not talking about the specific UI, but the way of thinking. Is this something that was considered? (And does this even make sense? lol)

[michalczaplinski]

I've recorded a short video to clarify how I see the implementation going forward and how its mechanics are similar to the current dropCap feature of the Paragraph block.

[gziolo]

Great summary, @michalczaplinski. It looks like a reasonable approach to start with as it covers both the aspect of controlling the UI and changing the default behavior by the theme/site. It would be also cool to be able to offer a UI control for users to optionally change the default behavior in the Site Editor in the Styles tab for all blocks or individual blocks. That would give maximum control and full flexibility.

[michalczaplinski]

The PR introducing the Behaviors UI has been merged.

Here are some outstanding tasks (other than Removing Interactivity API experimental flag):

• Improve the e2e tests according to Kevin’s comments. (Done on in Fix flaky Behaviors UI e2e tests #50954)
• Move “No behaviors” to be the first item in the list of behaviors and not order them alphabetically (Move "No Behaviors" to be the first option in the list of behaviors. #50979)
• Check if we really need the behaviors attribute in the block.json of core/image. See this discussion.
• Add a "reset" button for the behaviors. It should remove the "behaviors" attribute and thus reset the value for behaviors to the default from the theme.json. Image block: Add animation toggle to lightbox behavior #51357
• Make sure that the filter that adds the behaviors has an appropriate priority as commented here.
• Make Behaviors UI work in the site editor.
• Add the behaviors to the schemas for block.json & theme.json. Behaviors - Lightbox: Update theme.json schema #51156
• (nice to have) Add support for behaviors.lightbox in the theme.json (global switch).
• (nice to have) Explore adding support for behaviors in Global Styles (as outlined in this comment)

[michalczaplinski]

I've updated the task list. We are not currently pursuing the "nice-to-haves" from that list.

The tasks that are necessary to complete the MVP of Behaviors are tracked in #52292