Heading level style variations independent of markup

[getdave]

Currently when adding a Heading Block to a page you can select the appropriate heading level (h1 - h6). Visual styles are applied based on this heading level. However, when building more complex pages it is sometimes a requirement to have a heading whose markup is set to level X but which is styled to look like heading level Y.

For example, my page might begin with a hero section followed by a "main content" block containing a another heading and a paragraph. For visual design reasons I might not want the heading within the hero to be too large. However the heading following the hero (in the main content area) might (for visual reasons) look better a little larger. Currently the only way to achieve this is to use an incorrect heading hierarchy (eg: h2 for the hero heading and h1 for the main content heading) which is bad for a11y and SEO.

In short, by tieing the visual styles of the headings directly to the selected heading level we restrict the flexibility of the Block for more advanced use cases.

Proposed Solution

I propose adding six heading level style variations to the core/heading Block - one for each heading level.

Here is a screen capture of a prototype showing how this could work:

Note how you have 6 heading level styles to choose from. Each marries to its heading level counterpart. In the demo you will see the heading level is a h2 but using the style variation I change it to look like a h5.

This is certainly an "advanced" use case, but I suggest as we introduce more page layout blocks it will become increasinly important as a feature to more advanced users.

Questions/Feedback Required

At this stage, I’m looking for feedback on:

1. a11y implications (good/bad)?
2. UX - is this overcomplicating things (not necessarily, I believe there is a valid use case)
3. UI and Design - do the interactions work? What should the naming conventions be?

[davidakennedy]

Thanks for exploring this concept, @getdave! I like how you're thinking about accessibility impact, but trying to make visual design more flexible for users.

I assume that the block variations that change the size of the heading visually would tie to theme styles or default styles set by Gutenberg?

I wonder if it would be a better experience there to have size equivalents vs. the language around heading levels again? That may be confusing for some people. Maybe wording like: Largest, Large, Medium, Small, Smallest or something like that.

[getdave]

tie to theme styles

Ideally I would like to do this. Not sure how that could work technically. Can Themes register editor css and can we detect whether is has been registered and if not then fall back to default Gutenberg styles?

Maybe wording like: Largest, Large, Medium, Small, Smallest or something like that.

I completely agree. Let's do that!

[strarsis]

@davidakennedy: Though not always the font size follows the heading level.
This may make the user choose the wrong heading level just because the heading looks larger (by theme).

[getdave]

@strarsis Thanks for your input here. Much appreciated. A couple of questions:

Though not always the font size follows the heading level.

I'm not quite following you here. The variations I"m proposing here would need to map exactly to the heading levels. Can you clarify?

This may make the user choose the wrong heading level just because the heading looks larger (by theme).

I'm proposing using the heading levels provided by the Theme (we'll need to document how Themes can write the styles to make them available in the editor) or using those provided by default in the editor.

Would love to understand more about your concerns here. Any examples or use cases would definitely help. Much appreciated.

[getdave]

Please see the Questions/Feedback Required section in the Issue description above which details the specifics of the feedback that would be most helpful at this stage.

[kjellr]

Thanks for the idea, @getdave!

2. UX - is this overcomplicating things (not necessarily, I believe there is a valid use case)
3. UI and Design - do the interactions work? What should the naming conventions be?

I definitely understand that use case behind this, but my gut reaction is that the approach isn't quite right. I think the main issue is the use of block styles: The styles in question are just font size changes, which is something that's usually handled by a dedicated sidebar control. In addition, these block styles introduce six whole new levels of hierarchy for users to think about, which seems like a little too much to handle. Also, I could see this method requiring a bunch of extra style rules for themes to implement.

If we do decide to add font size controls to headings, I'd prefer it be done in the context of #8171, so that we have a cohesive set of font size controls across all text-based blocks. (I originally argued against including font size controls for headers in that ticket, but I understand the use case and the urge to include it).

[getdave]

Closing in favour of #8171