Design notes: I originally had "Custom" at the top of the dropdown, but moved it to the bottom. Truthfully I'm split on which is better (top or bottom). Luckily it's easy to change if desired :)

I think as a path forward for slug matching, the component will need to be updated to expect a slug OR an entire font size object as its value, e.g. here:

Then we can assume a direct numeric value is a custom value and stop trying to automatically map numbers to the pre-defined sizes.

(Also I know the tests need to be updated… working on that next)

Removing review requests as I encountered some issues I need to work on…

• Realised that updating to map via slug is pretty much a pre-requisite for merging this
• It may be beneficial to provide a default size when "custom" is selected
• Rather than a dedicated button it might be worth updating the fontSizes array to include a "custom" option, store it/handle it the same way as other font sizes, and additionally save a separate customFontSize

I still think there's room for design feedback though — it's just underlying API issues that need to be resolved.

I like this change! I agree that determining whether or not to use a class vs. inline styles should not depend on the value, but whether you set the font using the preset options or you chose Custom.

Considering accessibility, putting Custom at the start of the list seems like it would make more sense than down at the bottom?

I made some changes so we're now matching font sizes in attributes to the pre-defined font sizes via slug instead of value.

This fully decouples the custom and pre-defined fonts. The size values provided in the add_theme_support( 'editor-font-sizes' ); array are now exclusively used for setting the visible size in the dropdown interface, and have no other meaning. (A follow up improvement may be to rename that attribute "previewSize".)

Previously, if you entered a value in the custom size input/range slider that matched one of the pre-defined size values, the Dropdown would update to that option. This was problematic because the CSS for the class may be relative, use different units, etc., leading to a disconnect between the numeric size and the actual output.

Note that the actual serialisation behavior has not changed (we still set class names or inline styles in the same way we did before), we just expose the settings differently in the user interface.

This solves and simplifies the interface, but does expose an issue which is that when "resetting" a font size (aka setting font size to "undefined" and removing the CSS class/block attribute setting), we expect a font size to be defined with the slug "normal", so if you define an editor-font-sizes array without a font size with the "normal" slug, it creates problems.

One basic idea would be to always inject the "Normal" size into the fontSizes array, no matter what the user sets inside editor-font-sizes.

I'd love technical feedback on that before continuing!

Another refactor in progress to try to make the component a little dumber, and put some of the editor-specific logic into the editor package. Nothing to see here…

I still need to update the failing tests and some documentation but this is in a better place.

I think the only lingering question is about how to handle the concept of the "default" size.

I moved hard-coded references to the normal default into the editor package so at least the component itself is isolated from any specific sizes and thus easier to re-use. However we could still look at appending a "Normal" font size if one isn't provided in the editor package when we pull in the font sizes via wp.data.select.

Finally got the tests to pass! Would love a review on this! ❤️

This seems like something which would need to be included in a UI freeze. Milestoning as such for 4.1.

(Small bug in the test but I know why — the test needs to be updated in this case. Will fix when back at my laptop)

Let's move it to 4.2 milestone as it still has some failing tests. We want to do 4.1-RC release really soon and this one is more of an enhancement 😄

I've got it back in action! Tests are passing! Review me plz! <3

I'd like to step back a little and think about the flow here. Whilst I see a need to guide to a 'custom' font size being possible, I have to say having it appear at the bottom seems a little lost and confusing as an experience. I know it's fixing potentially a bug of not saving sizes when you do edit, but is this the only option? @jasmussen for some insights into this as know likely you have thoughts on inputs like this.

@karmatosed I should have updated the screenshot as I moved Custom to the top :)

My main concern is de-emphasising the relationship between pixel values and the font size values. We show pixel sizes in UI no matter what — even if the font size CSS itself uses an em or rem. This is misleading to users who may expect a certain size to be applied when the theme itself does not actually apply that size.

I should have updated the screenshot as I moved Custom to the top :)

I think at the top this is even more distracting possibly as a UI. It's the word outside of those that to me feels not as fitting. I'd be super interested if others feel the same. Are there any other UIs you can show where they have this?

Here's an updated screen capture, just for reference:

Are there any other UIs you can show where they have this?

I think the challenge here is that typically you'd have only named font sizes, or only numeric font sizes. We're trying to do both with this UI, which is — as far as I know — new territory.

That said I'm totally open to new UI ideas — I don't mind too much how it's solved. I am slightly afraid that UI exploration now will mean this misses the 4.2 milestone, and we end up with a misleading solution in core, but hopefully we can get something in place even if it has to be iterated on in Phase 2.

@chrisvanpatten I'm fairly certain I have seen dropdowns with presets and a "Custom" option in other places before. Unfortunately, I can't remember where. 😛

I found something pretty similar in Beaver Builder, though:

Selecting "Custom" makes a number input appear below the dropdown selection, allowing you to set your custom font size.

@ZebulanStanphill to the rescue, filling in for my lack of page builder UI knowledge 😂💖

Thanks for the example. That sort of confirms to me we have maybe a few issues here:

• Default and custom make sense as binary options, we have multiples.
• Combining both types of UI into one is somewhat confusing.

What other options do we have?

Thanks for your ongoing work here. I have to support with @karmatosed, the addition of the "custom" text to the dropdown feels a little bit awkward because it's not sized like the other labels.

I hate to be blunt, so please read the following knowing that I deeply appreciate your work and your desire to fix these issues. I kind of feel like master works both better than this branch, and okay on its own:

• When text isn't customized, there's a checkmark next to "Normal"
• When you type in a number, the collapsed dropdown says "Custom". It's not an option in the dropdown, but no items in there have checkmarks either.

I understand that the problem this is trying to solve is the disconnect between the "Custom" label on the button, and the lack of that "custom" in the dropdown itself. But this feels to me like it's comparable to an "unknown state" of a checkbox. For example when you have a treeview with checkboxes, and you have one child checkbox unchecked, another one checked — the parent checkbox then shows sort of a grayed/filled state. In this case, simply making the "Custom" label on the button italic, seems like it could be sufficient to imply that it's a third state.

For now, I am going to remove the milestone on this. That's not at all to say something can't be worked on and a milestone added back in. I would encourage you @chrisvanpatten to explore this milestone or not. Working out with space what the problem being solved is will more likely come up with a robust solution. Thanks for all the work done, please don't stop as it's great to explore new possibilities and iterations.

Thanks everyone for the feedback. In the interest of time I'm going to close this and hopefully revisit in the next phase.

For my future self, and for future historians, here's a small random brain dump:

• The current font picker implies a link between a numeric size (rendered in pixels, even though the UI never mentions pixels) that might not exist because the theme could provide different sizing in their classes (either with different units, or with different numeric values entirely)
• Trying to automatically map numbers to named font sizes is especially problematic in this case because it means that the numbers linked to named font sizes are effectively unavailable for "custom" sizing, even though we can't guarantee that the number you enter is actually going to be the result.
• Allowing users to provide units in their editor-font-sizes is one option but in my opinion isn't viable because it doesn't account for a responsive world where font sizes change and scale based on various conditions.

I definitely appreciate there are challenges here in the UI, and I'm sad this won't make it in because I do feel it's better in separating "custom" and "named" sizes (which, in master, interact and connect in weird, unique-to-Gutenberg ways), but addressing this problem has become my personal crusade and I plan to continue exploring in Phase 2 🤺