Feature Request: Broad control over typography in Global Styles

What problem does this address?

WordPress currently gives either too much or too little flexibility when selecting fonts. Blockbase looks like it's trying to address this but hasn't yet figured out what it wants to do. I'm proposing an approach for fonts that's similar to what Gutenberg is doing with colors. Let the theme be as opinionated as it wants to be and lock things down tight if it wants to. But if it allows customization of fonts, then have WordPress give the control to the admin to define available font schemes and lock things down for end users.

What is your proposed solution?

Here's my initial proposal for a replacement for the current Typography panel in Global Styles:

The Typography Palette shows the currently available fonts. They may be the limited list provided by the theme, or they may be customized by the admin.

Clicking that palette opens up its details and allows editing (if the theme allows it):

Blockbase currently defines two roles: Body and Headings. There are good reasons to occasionally have more than just those two typefaces playing just those two roles. The Typography Palette would give me a way to define additional typefaces, along with the named roles those typefaces would play. A theme designer could opt to forbid the creation of custom typeface roles if they wanted to constrain the admins.

The Typography Palette editor would work similar to how the Color Palette editor works. If the theme doesn't forbid it, then the theme's roles could be edited to select different typefaces. In addition, if the theme doesn't forbid it, an admin could define custom named roles and assign typefaces to those, much like they can create custom colors in the Color Palette editor.

Blockbase also automatically knows how to import a small subset of Google fonts, but not all of the good ones that an admin might want to use on their site. When assigning a typeface to a named role, an admin can choose from among the easy-to-choose list that the theme makes available, or they could define the necessary details to allow us to import the typeface definition from an external source.

Back to the root Typography panel in Global Styles again:

After the Typography Palette has been filled with a limited number of typefaces (assigned to named roles), those roles can then be used to create Font Schemes. Themes already do this to some degree, but this proposal gives a lot more clarity and control to the site admin in Global Styles.

Clicking on a Font Scheme reveals this editor:

Clicking an element would open up the standard Gutenberg font editor being defined as part of #34345.

If someone defines all these things and then switches themes, their named font schemes would remain. If the admin assigned a theme-provided font to a named role and that font is no longer available in the new theme, then one of the new theme-provided fonts would be selected to replace it.

Finally, when adding blocks to a page or template part, the editor for supported blocks would allow us to select one of the named font schemes, and the content rendered inside that block would use the fonts defined for that font scheme.

@critterverse

Thanks for kicking this off! I do want to mention the larger Global Styles issue #34574 and the following image/design pulled from there as something to consider:

As you can tell, this UI hasn't yet been finalized which is why there's a gap here. For now, flagging for design ahead of this work getting underway and cc'ing a few folks who might be interested @critterverse @kjellr.

@annezazu

Thanks for connecting these issues, @annezazu. I do like the bigger font previews as shown in the overall Global Styles issue. I also look forward to hearing other designers' thinking that hasn't made it into print yet.

A bit of background that colors my perspective... I run a multisite installation with a limited number of available themes. (Ideally, I'd have just one theme that's widely configurable. I believe WordPress is finally getting close to this ideal.) I want to give subsite owners as much flexibility as I can in defining their look to enforce their branding using Global Styles. Because these are subsite owners sharing a single multisite installation, theme.json will not work as a place to declare these design and constraint decisions. I'm also aware that other designers create their own themes, and that's one way they constrain the choices of even the site administrators, so we need both groups of people to have the opportunity to enforce design decisions.

One thing I'm very much in favor of is giving visible names to the various font schemes so that designers (theme creators or site admins) can help authors choose the right fonts for a given block based on the block's contextual purpose and not merely on what look a given author happens to like at the moment.

I'm eager to see how the discussion in January plays out. Thanks so much for considering this proposal.

This is an interesting conversation and whilst there are improvements to the screen with the new typography cards I totally can see how more could be built on.

One thing I'm very much in favor of is giving visible names to the various font schemes so that designers (theme creators or site admins) can help authors choose the right fonts for a given block based on the block's contextual purpose and not merely on what look a given author happens to like at the moment.

Names work if you see or know the names. So, we do need a combination of that. I also think there's something about the card for visually 'seeing' the font. It also gets around the translation of font names/pairings.

I really like this idea, and it seems similar to the idea I had for packages of colors:

Themes should be able to offer "packages" of complementary color options #39028

The full suite of typography options is even more intimidating than colors, and it's not good design practice to use more than a few different values for letter spacing, letter case and line height within the same page, let alone across an entire site.

As a theme author, I usually end up with an approximation of this functionality using block styles registered on paragraph/heading blocks while still leaving room for customization on top of it:

var text_blocks = ["core/heading", "core/paragraph", "core/post-title"];
text_blocks.forEach((block) => {
	wp.blocks.registerBlockStyle(block, [
		{
			name: "subhead",
			label: "Subhead",
		},
	]);
});
wp.blocks.registerBlockStyle("core/paragraph", [
	{
		name: "intro-paragraph",
		label: "Intro Paragraph",
	},
]);

.is-style-subhead {
	font-family: var(--font-family-body);
	font-weight: 600;

	&:not(.has-text-color) {
		color: var(--gray-600);
	}
	&:not([class*="-font-size"]) {
		font-size: 1.25rem;
		font-size: clamp(1.2rem, 1.15rem + 1vw, 1.5rem);
	}
}

.is-style-intro-paragraph {
	font-weight: 500;
	line-height: 1.4;

	&:not(.has-text-color) {
		color: var(--gray-800);
	}

	&:not([class*="-font-size"]) {
		font-size: 1.125em;
		font-size: clamp(1.1em, 1.05em + 1vw, 1.3em);
	}
}

I like very much where this conversation is going. In my opinion, the current styles feel very heavy-handed, in that one button has control over spacing, typography and color.

It would feel much more powerful if I was able to mix a colorscheme with a typography or a spacing.

it's not just that I want the freedom to save my own presets, I want to be able to choose from a theme designers presets. This is the first issue that seems to match what I am most looking for as a user. I hope that it can be looked at alongside #39028 and think about what a UI should look like that is consistent between Typography, Colors and Layout.

Trying to understand this issue. Is the idea being able to bundle "spacing typography and color" together? How is that different from "style variations"?

The original proposal came before Global Styles had much font support. But here's the key difference in intent between this proposal and what style variations already offers.

Style Variations allows someone to choose a collection of font attributes to apply to the entire site, and exactly one of those collections can be active for the whole site. The proposal here was to allow the admin to create a collection of named styles that would all be available in the post editor to apply at the block level. The goal is to allow a site designer to use Global Styles to define the expected appearance for the kinds of content that tend to show up on that specific site, and then let the content creators assign a named style to specific blocks that hold specialty types of content. The benefits would include a) less effort and less error in applying the specific font, size, appearance, etc. at post creation time, and b) the ability for the site designer to change the global appearance of a particular type of content without having to revisit each page.

The proposal here was to allow the admin to create a collection of named styles that would all be available in the post editor to apply at the block level.

I think this is already possible with the register_block_style (or using a theme.json like file within the style folder of the theme), you can provide a theme.json like structure to that function and assign it to a "group" block and apply that variation everywhere.

More details here https://make.wordpress.org/core/2024/06/24/section-styles/

So it seems this issue is now fixed.

@youknowriad

@youknowriad

Instead of "this issue is now fixed" would it be appropriate to say, this has been made available to theme developers that are creating style variations with theme.json, with the default theme Twenty Twenty-Five being an exemplar.

Additional work is still required to allow site owners to create style variations from the site editor.

You can already edit these style variations in the UI, but you're right that you can't register them in the UI at the moment, you can do so from themes or from a php API. I didn't know you were talking about user.

For that part, I think it's tracked here #45371 as well.

It's a good issue, and as Riad has previously noted, a lot of progress has already been made on the overall motivations of this.

I'm trying to figure out what the next most actionable step we can take is, to ultimately address this issue (if it isn't already). In addition to #45371 as is already mentioned, I wonder if #81645 can play a role, since it surfaces a lot of missing elements as now editable in global styles. "Type styles" appear related in that sense, perhaps partially absorbed by the "block styles" mentioned, and certainly this is how Twenty Twenty-Five is already using those styles, pick a type style from the Style buttons and they are effectively controlled from elsewhere at that point—theme.json for now, but from Global Styles once we address 45371:

Combined with improvements in #40331, I wonder if that helps address this issue?

Named typography styles that site designers define once and authors apply per block are now available as block style variations ("section styles", https://make.wordpress.org/core/2024/06/24/section-styles/). Themes can register them with register_block_style() and style_data or with styles/*.json files, and they can be edited in Styles > Blocks > Style variations. Twenty Twenty-Five uses them for its type styles. The remaining piece, creating new variations directly from the Styles UI, is tracked in #49602, so I'm closing this one in favour of that.

Navigation Menu

Repository navigation

Feature Request: Broad control over typography in Global Styles #37635

What problem does this address?

What is your proposed solution?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature Request: Broad control over typography in Global Styles #37635

Description

What problem does this address?

What is your proposed solution?

Activity

annezazu commented on Dec 28, 2021

sdwire commented on Dec 28, 2021

karmatosed commented on Jan 7, 2022

cbirdsong commented on Jun 20, 2022

beckej13820 commented on Jun 21, 2022

youknowriad commented on Oct 25, 2024

sdwire commented on Oct 25, 2024

youknowriad commented on Oct 25, 2024

beckej13820 commented on Oct 25, 2024

youknowriad commented on Oct 25, 2024

jasmussen commented on Aug 20, 2026

youknowriad commented on Oct 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions