[WIP] Stabilize experimental Typography block support features within the block type class

[andrewserong]

Trac ticket: https://core.trac.wordpress.org/ticket/61728

🚧 🚧 🚧 WIP: This is currently a work in progress and is not yet ready for review as the Gutenberg PR has not been merged yet. 🚧 🚧 🚧

This PR syncs the PHP changes from https://github.com/WordPress/gutenberg/pull/63401, however uses a slightly different approach for applying the transformations so that we do not depend on filters. The overall goal is the following:

Stabilize the following typography block supports by no longer requiring the __experimental prefix in supports.typography in block.json and when registering block types:

1. __experimentalFontFamily → fontFamily
2. __experimentalFontStyle → fontStyle
3. __experimentalFontWeight → fontWeight
4. __experimentalLetterSpacing → letterSpacing
5. __experimentalTextDecoration → textDecoration
6. __experimentalTextTransform → textTransform

The proposal here is to transform the __experimental form of the typography supports marks for stabilization when props are set on a block type instance. This occurs during registration or when a WP_Block_Type object is instantiated. There was some discussion in an earlier Gutenberg PR about potentially performing this transformation in the block registry instead — however I couldn't find a good precedent for it, and it seems slightly more encapsulated to me to keep the transformation close to where the supports key is stored.

I'm very happy for feedback on this, though!

For full testing instructions, please see the original Gutenberg PR: https://github.com/WordPress/gutenberg/pull/63401

The short version is that all the typography block supports for static blocks such as Group or dynamic blocks such as Post Title should work just the same with this PR applied as without. Then, in follow-up work we can look at updating core blocks to use the non __experimental syntax.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions[bot]]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance, it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[andrewserong]

Based on discussion over in https://github.com/WordPress/gutenberg/pull/63401#issuecomment-2249588880, I've updated this to move the stabilization to after the filter is run. This ensures that any opt-outs, etc, performed by plugins are appropriately stabilized before the props are set.

I've also moved the logic into a private method so that set_props is easier to read.

[github-actions[bot]]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props aaronrobertshaw, andrewserong, ramonopoly.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[aaronrobertshaw]

The latest plan is to backport all the block support stabilization updates in a single PR. This will include stabilizing border block supports and shared experimental flags such as __experimentalDefaultControls and __experimentalSkipSerialization.

More details can be found in https://github.com/WordPress/gutenberg/pull/66918#issuecomment-2472374805.

In the near future, I'll pick up this backport and update it accordingly, while @andrewserong is away.

[aaronrobertshaw]

I've pushed some updates to this PR bringing in the broader stabilization of other block supports e.g. __experimentalBorder, __experimentalSkipSerialization etc.

The trac ticket and PR description have been updated with the latest info.

[ramonjd]

So far I've tested this PR against https://github.com/WordPress/gutenberg/pull/63401 (Typography)

✅ ~~Typography controls work as expected with and without __experimental*~~ ✅ ~~Everything renders correctly in the site editor and frontend~~ ✅ ~~Disabling supports, e.g., __experimentalFontFamily disables controls in the UI~~

Actually, I made a mistake here. I had the plugin installed. 🤦🏻

I'm not sure what I should be seeing in the editor. I understand the packages eventually need to be updated, but I expected no regressions in the UI.

Here's what I'm seeing for paragraph blocks

Trunk	This PR

How have you been testing this @aaronrobertshaw ?

[ramonjd]

Same for border supports.

Here's what I'm seeing for the group block:

Trunk	This PR

Am I doing something wrong? I would have assumed, even without the package update, that the controls work with the current __experimental flags.

[aaronrobertshaw]

Thanks for testing @ramonjd and apologies for the confusion. I should have updated the test instructions on this PR further.

I'm not sure what I should be seeing in the editor. I understand the packages eventually need to be updated, but I expected no regressions in the UI.

The TL;DR is we need the JS package updates.

I've added the longer version to the PR test instructions but the PHP changes here stabilize the block supports in the block type. My understanding is the stabilized block type data is passed to the editor but the JS block support hooks etc will still be checking the __experimental prefixed block support keys. They don't exist after stabilization hence the "missing" UI elements as the editor believes the blocks don't have support.

How have you been testing this @aaronrobertshaw ?

I'd primarily tested using the unit tests and by creating blocks with global and block support styles applied on trunk, then switching to this branch and checking they were still applied correctly on the frontend. I'm definitely open to better testing approaches but my brain broke trying to come up with one.

The PR test instructions have been updated to something more useful. I'll re-test it all myself tomorrow as I'm out of time this evening.

[ramonjd]

To test I used the Gutenberg plugin, but disabled the gutenberg_stabilize_experimental_block_supports hook and prevented Gutenberg from registering typography and border block supports.

So far, with the exception of border, the support and common flags appear stable and work as expected.

I'll do another test tomorrow.

[ramonjd]

Thanks for pulling across https://github.com/WordPress/gutenberg/pull/67552!!

This is testing well for me in all scenarios so far.

✅ typgography.__experimental* and their stable counterparts work as expected ✅ __experimentalBorder and border the same ✅ blocks with skipSerialization e.g., image, appear as expected ✅ changes to __experimentalDefaultControls and defaultControls have effect in the UI

[aaronrobertshaw]

Quick update:

There's an alternate approach being explored as part of https://github.com/WordPress/gutenberg/pull/67729. I'll hold off on committing this PR until that plays out.

[aaronrobertshaw]

It's on the cards that the approach within this PR might be reverted in Gutenberg (see https://github.com/WordPress/gutenberg/pull/68163) and the stabilization of block supports punted for 6.8.

[ramonjd]

Closing this PR for now as the Gutenberg code has been reverted.

• https://github.com/WordPress/gutenberg/pull/68163

See https://github.com/WordPress/gutenberg/pull/67729#issuecomment-2553200639 for context behind the decision to revert.