Block Bindings: Allow blocks to declare attributes as bindable

[Bernhard Reiter]

There's currently a hard-wired list of blocks and attributes that can be used with Block Bindings (i.e. bound to a Block Bindings source). That list is defined ​here for the server side, and ​here for the client side.

There is currently no way for a third-party block to have itself and any of its attributes added to that list. It's even impossible for additional Core blocks -- developed inside the Gutenberg plugin -- to add themselves to that list on the server side, as there's no extensibility mechanism. Instead, if a Core block wants to mark one of its attributes as bindable, it has to provide a fallback mechanism to manually set the attribute to the value provided by the Block Bindings source, as seen e.g. ​here.

This impedes development and adoption of Block Bindings-compatible blocks. To solve this problem, there should be an extensibility mechanism that allows to add block attributes to the aforementioned list(s). One obvious solution would be to make the list filterable. However, it's arguable that it should be possible that a block simply declares any number of its attributes as bindable upon block registration; after all, it should be up to the block to decide.

This could be done at block.json level, inside the block attributes definition. One option would be to add a boolean property (e.g. bindable) to each attribute (with a false default); or, as was pointed out to me by @santosguillamot and @cbravobernal, by using the existing role property: If its value is content, then assume that the attribute is bindable.

[Bernhard Reiter]

One problem with the "role": "content"-based approach is that there are a lot more Core block attributes with that property set than are supported by Block Bindings, so this would be blocked by making them all compatible with Block Bindings first. As an intermediate step, it might be worth considering introducing a filter after all.

[cbravobernal]

That filter you mentioned was proposed a year ago: https://core.trac.wordpress.org/ticket/62090

At the beginning, we considered that it was better to try first to make the API powerful enough to be applied to any block rather than going case by case. But we would need to have at least:

• CSS selectors in HTML API or a markup definition for placeholders (could be bits).
• HTML API set_inner and set_outer html functions.

[Bernhard Reiter]

Thank you, @cbravobernal. Looks like this ticket is pretty much a duplicate of #62090. I'll close it as such.