Explore adding line height to paragraph and heading blocks

[karmatosed]

As the work deepens on global styles and block patterns, having extra styling tools at hand makes all the difference. As suggested in #20331 by @mtias, let's explore what adding line-height to the paragraph and headings blocks could look like.

It's worth stating these explorations are based on the interface today, as areas are iterated that can change here too. For now, it's good to show what could be within the existing panels.

But why?

There are a few reasons why this is good to add:

• Adds more styling options and personalisation to create just what is in your mind for that layout.
• As fonts vary you might want to change the line-height, this will happen even more as global styles come in.
• Personal preference of the author: this is one stands whether or not global styles is there, it's a thing most expect to be able to do.

Paragraph block

There are 2 versions here, showing possible reset button positions. I am not sure a reset is needed for each section here, or even as we move into using undo/redo if we need reset here, however, this pattern exists today. For now, I have gone with a single input box that can go up or down. We could choose to fix this to a range so to avoid some interesting variations, or we could adapt to have it be a custom input.

Heading block

This is fairly simple just based on what we have today:

Feedback

I am looking for overall feedback and input on this, but here are some starting points:

• What control do you think works for this?
• Would line-height need reset?

[gziolo]

What kind of unit is going to be used for the line height property? It’s a bit unclear in the current proposal.

[karmatosed]

@ItsJonQ and @jasmussen I'm going to loop you in for a recommendation here. I want to be sure to align this with G2 work and the system styles.

[jasmussen]

Thanks so much for this, I can't wait for this to land because the "why" feels so screamingly obvious to me. Line-height is such an important part of creating typographical refinement, that even beyond just the basic use-case of polishing the global site line-height for readibility, even doing it on a per-paragraph basis inside a Cover block will let you create delightful little sections:

For some fonts and font sizes and appearances, adjusting the line-height makes a world of a difference.

As for how the control should work, here's what Figma does:

Here's what Illustrator does:

We don't necessarily want to take too much inspiration from those apps, as they are very complex desktop layouting apps, and ideally we find a structure that is more user-friendly than that. But it's also a balance, as line-height is an aspect that is great when you need it but you can live a good life without it.

It would be good to see given a G2 (#18667) treatment. One pattern that's emerging from that is to let each sidebar section "fill out a square", rather than default to being a left-aligned sequence of form controls. In that vein already putting the Reset button on the 2nd line makes it more of a "unit". Doing so helps it give visual division without the need for an explicit border separator.

What kind of unit is going to be used for the line height property? It’s a bit unclear in the current proposal.

This seems important to decide upfront.

It just so happens that a very good unit to use in CSS, is no unit. So we could simply default to that. I.e. type in 1, and you have a line-height of 1, type in 2 and you have double line-height.

Could we also just keep this field agnostic? I.e. if a user types in 200% or 2em or 18pt that works as well?

[mtias]

That's a lovely quote.

[karmatosed]

@jasmussen I explored a bit and would love some more clarification on the square shape. Here is where I got:

I then took it a bit further into the new iterations:

[jasmussen]

I can't wait for the G2 sidebar explorations to mature so I can unleash your full creativity with the ingredients, Tammie! :) — nice, I think it's ready to move to the PR stage.

[karmatosed]

@jasmussen I am very excited to get cooking with the awesome ingredients ❤️

[ZebulanStanphill]

Noting that a lot of interesting discussion happened in #20775, which probably should have happened here. Sorry!

Anyway, responding to this comment by @mtias:

But in the end, that style variation will be just a class applied to a block. There's no need to add a line height attribute to any block.

@ZebulanStanphill this is not necessarily the case. The actual appearance attributes need to make it to the block as attributes, otherwise we cannot ensure true WYSIWYG. Also mobile apps don't understand class names with arbitrary CSS attached, they will need to consume agreed upon attributes.

Thanks for pointing out the mobile limitations. I wasn't aware of those. If more block attributes are indeed necessary to implement global styles, then go for it.

We also need to see how all of these should eventually be grouped in a style panel on the block, including ways to make changes the default (or save style variations) but all these layers require we build the tools, otherwise we are chasing ghosts.

Thumbs up on the idea of separating the standard styling controls (e.g. text color) from content controls (e.g. image alt text). Divi Builder already does something similar.

Site builders will be able to retain full control by not enabling / disabling certain appearance attributes. Once it's all properly codified, that should be an easy configuration set globally and cascading properly to blocks because they understand what to do with the attributes. This is also true if we want global styles to transpire to third-party blocks.

It's important to separate the fact getting the controls in place doesn't mean that everything will be exposed to end users. Most of the design tools, including global styles, theme editor, etc, are likely going to be admin level to begin with. The reality remains that global styles cannot work without also building the tools, and starting on individual blocks is more ergonomic than trying to solve everything at once at the global level. It also happens that patterns need more fine grained control over these attributes.

On the subject of restricting style controls based on user permissions, I think it might be a good idea to make it possible for admins to toggle whether custom color/font/etc. options are visible or not. It's a bit limiting to only have themes able to control this, considering a lot of themes were designed before Gutenberg, and so by default, everyone has access to all fully custom controls; the only way around this right now is to use a child theme that disables the controls.

[mtias]

Thanks for pointing out the mobile limitations. I wasn't aware of those. If more block attributes are indeed necessary to implement global styles, then go for it.

No worries! A lot of this has too many corners to wrap the mind around. The important part is that making the attributes visible to the block doesn't have to imply making the controls visible to the block.

It's a bit limiting to only have themes able to control this

Yes, I agree. It might be something to get sooner rather than later in the FSE + global styles setup. Even an overview of all the things that are relevant and toggle-able since they are too many already.

With the idea of being able to configure the default color palette from there, we should also allow configuring the default font sizes, whether to show the "custom" property and so on.

[CalumChilds]

I think it would be better if we have a slider and a measurement dropdown – line height can only go so far!

[minhruhr]

Please add an option to disable this via add_theme_support()

[mariohamann]

Please add an option to disable this via add_theme_support()

Need this one too.

[ItsJonQ]

Re: add_theme_support()

The custom line-height should be able to be disabled with:

add_theme_support( 'disable-custom-line-height' );

Hope this helps! 🙏

[mariohamann]

@ItsJonQ Thank you, it worked!

Unfortunately the "Typography" area is still shown although there is not content inside. (I already deregistered custom font size.)

[ItsJonQ]

@mariohamann Ah! Thank you so much for that. I'll take a look into this now

[mariohamann]

@ItsJonQ Thank you! By the way: There is still no possibility to disable Drop cap, isn't it?

[ItsJonQ]

@mariohamann Happy to help!

Dropcap is something I'm not too sure of (unfortunately) 😊

I took a quick look. There appears to be something that may be able to do it:
https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/paragraph/edit.js#L60

Although, I'm sure how that one works (cc'ing @gziolo 🙏 )

[gziolo]

Thank you! By the way: There is still no possibility to disable Drop cap, isn't it?

It's a completely independent feature from this issue. We are working on a general approach that would allow controlling all design tools used with core blocks, see #22291 to watch the progress. The idea is that you could customize it on the block level or theme level and WordPress core would provide sensible defaults.

[mariohamann]

Sounds great. Thank you for the link and answer!

[oandregal]

I'm consolidating a tracking issue to keep record of the work regarding block style attributes at #22700 It looks like we've already merged line-height controls for paragraph & heading, so closing this.