This has been discussed in https://core.trac.wordpress.org/ticket/62090.

Alternatives considered include:

1. A dedicated property to denote a block attribute as bindable in block.json, e.g.

"attributes": {
	"datetime": {
		"type": "string",
		"bindable": true
	},
}

2. Inferring that an attribute is bindable if it has "role": "content" set:

"attributes": {
	"datetime": {
		"type": "string",
		"role": "content"
	},
}

I agree that the latter is probably a good idea in the long run. However, there are currently 83 block attributes with "role": "content" in Gutenberg, and it's not a trivial feat to make all of them bindable. (There are some complications, e.g. attributes such as an image block's caption which is only rendered conditionally.)

In the meantime, the absence of an extensibility mechanism for the list of supported block attributes means that each block has to manually invoke block bindings to ensure backwards compatibility, as seen e.g. here for the Date block. This is required so the block doesn't erroneously receive the fallback value for the bound attribute if the GB plugin is run on a WP version that doesn't have that block attribute added to $supported_block_attributes in WP_Block::process_block_bindings(). On a WP version that does support the block attribute, it means that the relevant code is needlessly run twice.

This is suboptimal. It also puts undue burden on block developers to include the back-compat code in their blocks, instead of being able to mark their bindable block attributes as such; it thus can hamper adoption of Block Bindings, as it makes it much more difficult to update a block to make some of its attributes bindable.

Note that this solution isn't meant to be mutually exclusive with the long-term perspective of having "role": "content" determine if a block attribute is bindable or not, as the initial value of $supported_block_attributes could be computed by iterating over blocks and including all attributes with that criterion in the list.

Closes #7404.

Trac ticket: https://core.trac.wordpress.org/ticket/62090

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.