Block API: explore aligning block attributes, block supports, and theme.json shape

[oandregal]

A block declaration is made of a few things, including attributes, usesContext, and supports.

Take the following as a potential example:

{
    "name": "my/custom-block",
    "attributes": {
        "align": {
            "type": "string"
        },
        "dropCap": {
            "type": "boolean",
            "default": false
        },
        "backgroundColor": {
            "type": "string"
        },
        "foregroundColor": {
            "type": "string"
        },
        "style": {
            "type": 'object',
            "default": {
                "color": {
                    "background": "value",
                    "gradient": "value",
                    "text": "default value"
                }
            }
        }
    },
    "usesContext": [
        "backgroundColor",
        "foregroundColor"
    ],
    "supports": {
        "align": [ "wide", "full" ],
        "anchor": true,
        "html": false,
        "inserter": true,
        "color": {
                "__experimentalSkipSerialization": true,
                "gradients": true,
                "linkColor": true,
        },
        "fontSize": true,
        "__experimentalFontStyle": true,
        "__experimentalFontWeight": true,
        "__experimentalTextTransform": true,
        "__experimentalFontFamily": true,
        "__experimentalTextDecoration": true
        "__experimentalSelector": {
	    "my/custom-block/1": {
	        "selector": "h1",
	        "title": "h1",
	        "attributes": {
	            "level": 1
	        }
	    },
	    "my/custom-block/2": {
	        "selector": "h2",
	        "title": "h2",
	        "attributes": {
	            "level": 2
	        }
	    },
    }
}

See that the block:

• Some features need to be registered in different places: align need to be set on both attributes and supports.
• Defaults can't be provided via the block supports. Even for the attributes that are implicit (created by declaring support keys for them such as color, font size, etc), the block author needs to declare the "style" attribute to set defaults.
• It's worth looking at the current shape of theme.json (docs) to see if some properties can be consolidated. For example, grouping all font settings under a "typography" key, like in theme.json
• Some attributes will take their value from the context, which is something the block itself will have to manage (backgroundColor and foregroundColor). See example Social Links Block: Add icon and background color options #25372

[gziolo]

The fun part is we often have entries in supports like align or customClassName declared also as an attribute to make it possible to process them in render_callback on the server. In other places, they aren't explicitly declared in attributes but magically injected with filters on the front-end :)

[oandregal]

Updated the issue with an example of attributes & context from #25372 This use case highlights a limitation of the current hook system: that we're only able to attach styles to the block that declares support for them (ex: __experimentalFontSize in the example affects my/custom-block). Sometimes, though, we want a parent block to absorb the UI for its inner blocks (ex: let the social links block to set the color of its inner social link blocks) or have a more complex markup (ex: the pullquote block may want to attach a color to the cite tag, which is not the top-level tag).

[gziolo]

Some features need to be registered in different places: align and dropCap need to be set on both attributes and supports.

Just to reiterate my previous comment. It feels like those attributes could be auto-filled on the server when features like align or dropCap get enabled.

[oandregal]

#28913 is related to this in that it addresses the use case of targeting inner elements.

I've also updated a bit the issue description to make it current.