[Heading block] Per-level styling of heading blocks does not work

[scruffian]

What problem does this address?

Moving discussion from https://github.com/WordPress/gutenberg/issues/49070. It should be possible to target different heading elements in the heading block. For example this theme.json:

            "core/heading": {
                "typography": {
                    "fontFamily": "var(--wp--preset--font-family--title-font)",
                    "fontWeight": "700",
                    "lineHeight": "1.2"
                },
                "elements": {
                    "h1": {
                        "typography": {
                            "fontSize": "4.375rem",
                            "textTransform": "uppercase"
                        }
                    },
                    "h2": {
                        "typography": {
                            "fontSize": "2.5rem"
                        }
                    },
                    "h3": {
                        "typography": {
                            "fontFamily": "var(--wp--preset--font-family--content-font)"
                        }
                    }
                }
            },

Does not result in different heading styles for h1, h2 and h3.

I would expect that these different settings would give me control over each heading element.

The reason why this doesn't work is that the elements selector expects that the elements are inside the block, rather than being the block themselves, that is to say it is expecting the heading block markup to be like this:

<div class="wp-block-heading"><h3>heading</h3></div>

rather than

<h3 class="wp-block-heading">heading</h3>

To solve this I think we'll need to add a concept of element selectors and give the block control over the element selectors if it needs it.

[Lovor01]

Thank you for clarifying this. However, exception of regular block syntax is not a justification to not implement this feature if it would be useful. I know that for me it would, since styles.blocks.core/heading styles in theme.json override the ones in styles.elements.[h1 - h6], e.g. if font-family is defined for entire heading range and h3 and h4 have exceptions, then theme.json becomes more verbose, having to set font-family for each styles.element.[h1-h6]. Furher, heading tags inside other blocks (mostly custom blocks, I am do not know there is other core block which uses heading tag) must be re-styled to override styles applies by stles.elements.[h1 - h6].

I can agree that I can live without it, and this is not the first priority, but it would be nice to have. In documentation it should be clearly stated that elements inside core/heading do not work, and better yet, remove elements tag from schema for core/heading if posssible.

[krsdcbl]

Since this is a minor inconvenience in regard of block themes & configurability with the site editor, I'd like to add a specific case where I found this bug to be a blocker: While authoring a classic theme that uses the block editor for content, and provides custom setting pages to allow filtering user defined editor presets into theme json, I ran into the problem of not being able to reuse "heading presets" anywhere else in my sites custom CSS without manually parsing and printing additional css. Allowing to bind these "presets" to the core/heading block class would allow for reusability in non-site-editor styles.

Addendum: Being only able to bind the heading styles to plain h1-h6 HTML elements also carries another, imho quite relevant, implication:

It mandates the use of semantically relevant HTML elements to benefit from the built-in typographic definitions, which further encourages content & theme authors to resort to the already prevalent bad practice of ignoring semantic heading order when wanting to apply a certain "look" to a text element.

Allowing core/heading levels to declare their own typography properties, and maybe even setting explicit classes for these heading elements would allow for a way out of this conundrum without resorting to additional custom-made methods of managing styles (if it doesn't interfere with the specificity of customizations that is)