Context
Block Fields are an experimental feature in Gutenberg that was introduced as part of content-only editing. It adds controls for each content-like block attribute to a new “Content” tab in the block inspector.
Block Bindings, on the other hand, allow connecting (“binding”) a block attribute to a data source, meaning that the attribute value will be provided by that data source, rather than set manually. This is currently done via the “Attributes” panel in the block inspector’s “Settings” tab:
Note that block attributes need to opt in for Block Bindings support, as blocks typically require some changes to their code and UI in order to support connecting an attribute to a Block Bindings source. As a result, only a select number of block attributes currently support Block Bindings.
Problem
While Block Fields do reflect bound attribute values, there’s no visual indication that an attribute is bound. To find out, users need to switch between the Content and Settings tabs.
The Block Bindings UI is rather austere compared with the Block Fields UI. The latter is implemented via DataForms, which means that different controls exist for different block attribute types (e.g. text input, number), among them some “aggregate” ones (media control for id and url attributes; link control for url, rel, etc. — see the screenshot at the top of this issue).
Proposed Solution
I’d like to propose adding a visual indicator to Block Fields for attributes that support Block Bindings, with the eventual goal of removing the “Attributes” panel altogether. (The latter is a declared goal in #73845, see the "Bindings" section.)
@jarekmorawski previously explored some designs for this use case and kindly shared them with me.
At a minimum, this would include a little “connection” icon next to each field header, which could:
- either turn to purple (as seen in the visual on the right) if an attribute is connected,
- or alternate between a “connected” (plugged-in) and “disconnected” (unplugged) icon.
I believe that we should solve this problem before attempting to add block bindings support for any "composite" data types (e.g. the Cover block). Our prior explorations (e.g. #74109 and #74610) have surfaced a class of issues that I believe can be avoided if Block Bindings are integrated into Block Fields.
Context
Block Fields are an experimental feature in Gutenberg that was introduced as part of content-only editing. It adds controls for each content-like block attribute to a new “Content” tab in the block inspector.
Block Bindings, on the other hand, allow connecting (“binding”) a block attribute to a data source, meaning that the attribute value will be provided by that data source, rather than set manually. This is currently done via the “Attributes” panel in the block inspector’s “Settings” tab:
Note that block attributes need to opt in for Block Bindings support, as blocks typically require some changes to their code and UI in order to support connecting an attribute to a Block Bindings source. As a result, only a select number of block attributes currently support Block Bindings.
Problem
While Block Fields do reflect bound attribute values, there’s no visual indication that an attribute is bound. To find out, users need to switch between the Content and Settings tabs.
The Block Bindings UI is rather austere compared with the Block Fields UI. The latter is implemented via DataForms, which means that different controls exist for different block attribute types (e.g. text input, number), among them some “aggregate” ones (media control for
idandurlattributes; link control forurl,rel, etc. — see the screenshot at the top of this issue).Proposed Solution
I’d like to propose adding a visual indicator to Block Fields for attributes that support Block Bindings, with the eventual goal of removing the “Attributes” panel altogether. (The latter is a declared goal in #73845, see the "Bindings" section.)
@jarekmorawski previously explored some designs for this use case and kindly shared them with me.
At a minimum, this would include a little “connection” icon next to each field header, which could:
I believe that we should solve this problem before attempting to add block bindings support for any "composite" data types (e.g. the Cover block). Our prior explorations (e.g. #74109 and #74610) have surfaced a class of issues that I believe can be avoided if Block Bindings are integrated into Block Fields.