• 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.