Font size abbreviations in FontSizePicker are misleading when the theme declares multiple "small" sizes.

[ZebulanStanphill]

Description

The FontSizePicker control currently applies abbreviated "t-shirt" labels for the options based solely on their order. This means that the control assumes that the font sizes will start with "small", followed by "medium", "large", "very large", and so on.

The problem is that in practice, a theme may actually have two (or perhaps even three" sizes smaller than the default. I actually ran into this recently while trying to create a custom block theme for someone. When using the controls, the option labeled "M" is actually the "small" size, while "S" is the "extra small" size.

Obviously, this is quite confusing.

In prior versions of the editor, the abbreviated labels were merely sequential numbers. So in some sense, the latest versions have introduced a regression here.

Step-by-step reproduction instructions

1. Use a block theme with a theme.json that has appearanceTools set to true and the following settings.typography.fontSizes set similar to this:

"fontSizes": [
	{
		"fluid": false,
		"name": "Extra small",
		"size": "0.75rem",
		"slug": "x-small"
	},
	{
		"fluid": false,
		"size": "0.875rem",
		"slug": "small"
	},
	{
		"fluid": false,
		"size": "1rem",
		"slug": "medium"
	},
	{
		"fluid": {
			"min": "1.125rem",
			"max": "1.25rem"
		},
		"size": "1.125rem",
		"slug": "large"
	},
	{
		"size": "1.5rem",
		"slug": "x-large"
	}
]

2. Open Global Styles and hover over the font size presets in Typography -> Text.

Screenshots, screen recording, code snippet

Environment info

• WordPress 6.0.2
• Gutenberg 14.1

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[ZebulanStanphill]

Copy-pasting a little conversation from #44247 (comment):

jasmussen:

@ZebulanStanphill for typography my personal opinion of the segmented control is that it is a curation tool. It's limited to 5 at most, and by applying the user-convenient labels it's an easy tool to use. The 5+ dropdown then becomes a more advanced tool for themes that have more specific needs than a typescale of 5. More importantly, by encouraging such a typescale, the CSS classes that get applied (such as has-small-font-size) are more likely to transfer when you switch to another theme. So long as the dropdown (which I as noted could use its own set of improvements) exists as an option for total customizability, I still lean towards the t-shirt sizes workin decently for font sizes.

ZebulanStanphill:

@jasmussen Is there a way to opt into always using the dropdown, even when there's only a few options? It's just really confusing to have a type scale of "extra small -> small -> medium -> large" and have that be presented as "S -> M -> L -> XL".

If standardizing the scale is desirable for most themes, why even allow customizing the slugs/classes for that use case? It seems like the only cases that would need custom slugs/class-names are the ones that should also always use a dropdown. In other words, defining any non-standard fontSize slugs in your theme.json should automatically enable the dropdown UI, since doing so is an indication that your theme does things differently.

As it is, the current implicit yet entirely unspoken and only half-enforced standardization is confusing. I don't think an theme developer would expect the current behavior of their font size option with the slug "small" being labeled as "M" in the UI.

Alternatively (or perhaps simultaneously), it would be nice if the t-shirt labels could at least adapt when there are 2 small sizes instead of 2 large sizes. Perhaps detect the usage of an x-small slug in the first option, and use "XS -> S -> M -> ..." in that case.

[jasmussen]

I don't know of a way. I wouldn't personally mind a way, so long as it isn't the default.

[t-hamano]

@ZebulanStanphill

I also opened another #45268 on this issue. As I mentioned in that issue, here are my two suggestions:

Option to force selectbox

If there are more than 6 font size variations, the select box will be displayed and the t-shirt size will not be displayed. Therefore, I believe it would be useful to have an option to force a select box without having to add the necessary variations to make it a select box.

Option to change button text

In addition to size, slug, and name, add properties to change the button text. For example, shortName.

{
	"size": "1.5rem",
	"slug": "md",
	"name": "Medium",
	"shortName": "M"
}

shortName seems to be customarily used in the Classic theme, as seen in these issues (I'm not sure when this property appeared, and it doesn't appear to be considered in the latest WordPress/Gutenberg.

[ddryo]

I am also having trouble with this issue.

[fabiankaegy]

@t-hamano I quite like both of your solutions. The current system looks pretty in the perfect case when a theme provides only perfect TShirt size font sizes. But is really inflexible and the confusion causes when the labels don't match the values is quite large.

Being able to either disable the TShirt sizes altogether and always force the SelectControl would be one solution. Ideally I would love the second option that was outlined where each font size can specify it's own shortName

[wwdes]

I cannot fathom why this was decided to be the default behavior of the size picker. Of course there should be a property enabling us to prefer the drop-down menu. Of course there should be a property that enables us to set the labels our selves for each size. Of course the default size should have a button and be preselected (highlighted) for every new text block.

Enlighten me how any of these suggestions would not be ideal for the end user or the developer.

ZebulanStanphill:

If standardizing the scale is desirable for most themes, why even allow customizing the slugs/classes for that use case? It seems like the only cases that would need custom slugs/class-names are the ones that should also always use a dropdown. In other words, defining any non-standard fontSize slugs in your theme.json should automatically enable the dropdown UI, since doing so is an indication that your theme does things differently.

This is logical and makes a lot more sense than current behaviour.

[maddisondesigns]

Having the same issues. You used to be able to to specify the "ShortName" for the font size but now it now longer works and the labels in the Font Size Control don't match up with what has been set.

If you can no longer specify the ShortName, how is it not common sense to simply use the first character of the Name instead when you're generating this control!

This following code used to work fine, and now everything is completely messed up!

add_theme_support( 'editor-font-sizes', array(
	array(
		'name' => __( 'Small', 'ephemeris' ),
		'shortName' => __( 'S', 'ephemeris' ),
		'size' => 13,
		'slug' => 'small'
	),
	array(
		'name' => __( 'Normal', 'ephemeris' ),
		'shortName' => __( 'N', 'ephemeris' ),
		'size' => 16,
		'slug' => 'normal'
	),
	array(
		'name' => __( 'Medium', 'ephemeris' ),
		'shortName' => __( 'M', 'ephemeris' ),
		'size' => 24,
		'slug' => 'medium'
	),
	array(
		'name' => __( 'Large', 'ephemeris' ),
		'shortName' => __( 'L', 'ephemeris' ),
		'size' => 36,
		'slug' => 'large'
	),
	array(
		'name' => __( 'Huge', 'ephemeris' ),
		'shortName' => __( 'H', 'ephemeris' ),
		'size' => 48,
		'slug' => 'huge'
	)
) );

I don't know how you expect us to build client sites using this editor when something breaks with every single major WP version. Almost 5 years since being in core and it's still not stable enough to give to clients.

[koendewilde]

I agree with @maddisondesigns. These labels are really fundamental stuff.

And a +1 for a more intuitive reset option (clicking toggles on/off).

[LucaLorenz]

Same problem.
I found this temporary fix via css.

Add this to functions.php

function fix_gutenberg_typography_labels() {
  echo '<style>
  button[aria-label="Extra Small"] div {
    display: none;
  }
  button[aria-label="Extra Small"]:after {
      content: "XS";
  }

  button[aria-label="Small"] div {
    display: none;
  }
  button[aria-label="Small"]:after {
      content: "S";
  }

  button[aria-label="Medium"] div {
    display: none;
  }
  button[aria-label="Medium"]:after {
      content: "M";
  }

  button[aria-label="Large"] div {
    display: none;
  }
  button[aria-label="Large"]:after {
      content: "L";
  }

  button[aria-label="Extra Large"] div {
    display: none;
  }
  button[aria-label="Extra Large"]:after {
      content: "XL";
  }
  </style>';
}

add_action('admin_head', 'fix_gutenberg_typography_labels');

RESULT:

Inspecting the editor code, it appears that the aria-label tag matches the name given within the theme.json

Really crude solution, hope it will be useful to someone.
Let's hope they fix it.

[hanneslsm]

Maybe I am missing something here, but why is not a slider with steps the default, as we know it from the dimension controls? The t-shirt sizes are obviously too opinionated, so why not taking a component that is more flexible?

[Matekk]

This issue, still...

[jhallbachner]

Okay, so I just want to verify the situation with this issue.

At least two possible solutions, either of which would completely resolve the problem on its own andwhich could both be implemented without conflict, were identified.

A working PR which resolved this issue using one of those solutions (manually setting label values) was opened:

Five months later, that PR was closed in favor of another solution which would, as described, implement the second option (a prop that forces the dropdown control for <= 5 sizes) but which did not have a PR, branch, or other code specified that would implement this, or a new issue number for discussing it.

A third workable solution distinct from the others was proposed here.

A PR was accepted for this component that completely rewrote the internal logic regarding the toggle vs. dropdown, but did not while doing so add an override for the toggle/dropdown logic that would've essentially been the second solution referred to above.

There is currently no open PR for this issue.

There's at least one other open issue that is essentially a duplicate. (That one has had more recent discussion, but this was previously designated to be the primary issue for this topic which is why I'm posting here.)

Is there any feasible path to getting this issue addressed?

[walton-alex]

I'd really like to see this resolved too, +1