Block Support: Add text transform block support using CSS variables

[aaronrobertshaw]

Description

This adds block support for text transform styles and is a continuation from discussion around #25641 around adding font style block support.

Changes Included

• Adds block support for text transforms
• Allows for preset text transform options and uses CSS variables
• Updates heading block to opt-in to text transform support for easier testing

Notes

• The UI for the text transform control will need some design input. It fills the need for testing this now though.
• The buttons within the controls simply use plain text ( e.g 'AB', 'ab', 'Ab' ) at the moment and still need icons.
• The intention is when this and text decoration block support (Block Support: Add text decoration block support using CSS variables #26059) are both merged a quick update will be made to include both sets of controls so they display on a single row within the typography controls.

How has this been tested?

Manually tested using heading block.

Test Instructions

1. Add a heading block to a post and select it.
2. You should see new text transform buttons under the Inspector Controls > Typography section.
3. Toggle the various text transform buttons and confirm the block updates visually as you'd expect.
4. With a text transform toggled on, inspect the heading block in dev tools and confirm that the block includes an inline style using var() and an appropriate CSS variable.
5. Save the post and view on the frontend.
6. The same text transform choice should be reflected on the frontend block's inline styles.

Screenshots

Types of changes

Enhancement

Next Steps

• Update tests in class-block-supported-styles-test.php if needed after approach confirmed.
• Add text transforms to the Global styles Typography panel once UI is refined.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[aaronrobertshaw]

@noahshrader or @ItsJonQ It would be great if we could get a design review for the Text Transform controls UI when you get the chance. My apologies if there is someone else I should have pinged for this, you drew the short straw as you were mentioned on #25641

[apeatling]

This works well. It has the same UI issue as #26059 though:

[aaronrobertshaw]

This works well. It has the same UI issue as #26059 though:

I've tidied up the controls and added the same approach to icons as #26059 for consistency purposes. We'll need icons for capitalize, lowercase and uppercase.

Current Controls:

[aaronrobertshaw]

It was suggested in the PR adding block support for font styles that the current use of a segmented control here (ButtonGroup) is not ideal. It should have a "none" and/or "default" option so there is always at least one option selected.

I'm open to suggestions here as well. Should this be changed to a SelectControl, making it consistent with the font style control? Or, should it have additional options added to this ButtonGroup if appropriate icons can be come up with? Without icons, the width of the button group would also begin to wrap.

[aaronrobertshaw]

After further discussions around the UI for this PR's text transform controls and the text decoration controls from #26059 it is likely they should be displayed on a single row within the Typography panel.

I've updated this PR with a new component that will cater to achieving this layout. The changes also include simple icon-only styling and using plain text to more closely reflect the icons that will eventually be used.

[jasmussen]

Nice work. Here's a snippet of a design that tentatively takes a stab at an organization of related typography tools:

I think it's fine to use that dark toggle, even if at a glance it appears able to toggle multiple at once, you only need to toggle either once to learn how it works, and it comes with an intuitive "untoggle" benefit.

Worth noting, though, that these two controls shown above, should not show up in the typography for the Paragraph panel yet. We need a good system to progressively show such controls in that block, because it's not something you should be using all the time.

But until we have such a progressively unlocking system, I'd recommend adding this only to the Navigation block as an experimental place for it to be a the beginning.

I think we should use icons for both underline, strikethrough and the various capitalizations. Do you need SVGs for those? I can provide.

Also, the toggle should be square. Since it doesn't feel like we should be replacing the entire segmented control with this design (there are still cases where we need the classic segmented control), if you need to change the CSS appearance to accommodate this use case, I wonder if a prop is a good way forward?

[aaronrobertshaw]

Thanks 🙂

I think it's fine to use that dark toggle, even if at a glance it appears able to toggle multiple at once, you only need to toggle either once to learn how it works, and it comes with an intuitive "untoggle" benefit.

I agree.

Worth noting, though, that these two controls shown above, should not show up in the typography for the Paragraph panel yet. We need a good system to progressively show such controls in that block, because it's not something you should be using all the time.

But until we have such a progressively unlocking system, I'd recommend adding this only to the Navigation block as an experimental place for it to be a the beginning.

At this stage, this feature is opt-in only and was only turned on in the heading block for testing purposes. This is easy to change.

I think we should use icons for both underline, strikethrough and the various capitalizations. Do you need SVGs for those? I can provide.

Definitely, icons would be the way to go. If you can provide SVGs for the various capitalizations that would be great! I only used plain text as a placeholder due to not finding SVG icons within packages/icons/src/library/.

Also, the toggle should be square.

When I add the SVG icons, I'll update the CSS to ensure each toggle is square.

Since it doesn't feel like we should be replacing the entire segmented control with this design (there are still cases where we need the classic segmented control), if you need to change the CSS appearance to accommodate this use case, I wonder if a prop is a good way forward?

Just so I'm clear, your suggestion is that I continue to use a ButtonGroup as the container for the icon buttons but add a new prop to that component to be able to tweak the appearance via CSS? Currently, I have these Button components inside a simple div using display: flex.

I appreciate the feedback on this.

[jasmussen]

Awesome, I'll get you SVGs in a moment, feel free to update any existing icons in the package directly, or add new ones for ones that are missing.

Just so I'm clear, your suggestion is that I continue to use a ButtonGroup as the container for the icon buttons but add a new prop to that component to be able to tweak the appearance via CSS? Currently, I have these Button components inside a simple div using display: flex.

I did not dive deep into the component structure here, so I'll defer entirely to you on which components to use. I just want to make sure that for this particular type of "toggle", we use the same toggle in other places going forward.

[jasmussen]

SVGs. UPPERCASE:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M6.1 6.8L2.1 18h1.6l1.1-3h4.3l1.1 3h1.6l-4-11.2H6.1zm-.8 6.8L7 8.9l1.7 4.7H5.3zm15.1-.7c-.4-.5-.9-.8-1.6-1 .4-.2.7-.5.8-.9.2-.4.3-.9.3-1.4 0-.9-.3-1.6-.8-2-.6-.5-1.3-.7-2.4-.7h-3.5V18h4.2c1.1 0 2-.3 2.6-.8.6-.6 1-1.4 1-2.4-.1-.8-.3-1.4-.6-1.9zm-5.7-4.7h1.8c.6 0 1.1.1 1.4.4.3.2.5.7.5 1.3 0 .6-.2 1.1-.5 1.3-.3.2-.8.4-1.4.4h-1.8V8.2zm4 8c-.4.3-.9.5-1.5.5h-2.6v-3.8h2.6c1.4 0 2 .6 2 1.9.1.6-.1 1-.5 1.4z" fill="#1d1d1b"/></svg>

lowercase:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M10.8 16.8c-.1-.1-.2-.3-.3-.5v-2.6c0-.9-.1-1.7-.3-2.2-.2-.5-.5-.9-.9-1.1-.4-.3-.9-.4-1.6-.4-.5 0-1 .1-1.5.2s-.9.3-1.2.6l.3 1.2c.4-.3.7-.4 1.1-.5.3-.1.7-.2 1-.2.6 0 1 .1 1.3.4.3.2.4.7.4 1.4-1.2 0-2.3.2-3.3.7s-1.4 1.1-1.4 2.1c0 .7.2 1.2.7 1.6.4.4 1 .6 1.8.6.9 0 1.7-.4 2.4-1.2.1.3.2.5.4.7.1.2.3.3.6.4.3.1.6.1 1.1.1h.1l.2-1.2h-.1c-.5.1-.7 0-.8-.1zM9.1 16c-.2.3-.5.6-.9.8-.4.1-.7.2-1.1.2-.4 0-.7-.1-.9-.3-.2-.2-.3-.5-.3-.9 0-.6.2-1 .7-1.3.5-.3 1.3-.4 2.5-.5v2zm10.5-3.9c-.3-.6-.7-1.1-1.2-1.5-.5-.4-1.2-.6-1.9-.6-.5 0-.9.1-1.4.3-.4.2-.8.5-1.1.8V6h-1.4v12h1.3l.2-1c.2.4.6.6 1 .8.4.2.9.3 1.4.3.7 0 1.2-.2 1.8-.5.5-.4 1-.9 1.3-1.5.3-.6.5-1.3.5-2.1 0-.6-.2-1.3-.5-1.9zm-1.6 4c-.4.5-.9.8-1.6.8s-1.2-.2-1.7-.7c-.5-.5-.7-1.2-.7-2.1 0-.9.2-1.6.7-2.1.4-.5 1-.7 1.7-.7s1.2.3 1.6.8c.4.5.6 1.2.6 2s-.2 1.4-.6 2z" fill="#1e1e1e"/></svg>

Capitalize:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M7.1 6.8L3.1 18h1.6l1.1-3h4.3l1.1 3h1.6l-4-11.2H7.1zm-.8 6.8L8 8.9l1.7 4.7H6.3zm14.5-1.5c-.3-.6-.7-1.1-1.2-1.5-.6-.4-1.2-.6-1.9-.6-.5 0-.9.1-1.4.3-.4.2-.8.5-1.1.8V6h-1.4v12h1.3l.2-1c.2.4.6.6 1 .8.4.2.9.3 1.4.3.7 0 1.2-.2 1.8-.5.5-.4 1-.9 1.3-1.5.3-.6.5-1.3.5-2.1-.1-.6-.2-1.3-.5-1.9zm-1.7 4c-.4.5-.9.8-1.6.8s-1.2-.2-1.7-.7c-.4-.5-.7-1.2-.7-2.1 0-.9.2-1.6.7-2.1.4-.5 1-.7 1.7-.7s1.2.3 1.6.8c.4.5.6 1.2.6 2 .1.8-.2 1.4-.6 2z" fill="#1e1e1e"/></svg>

[aaronrobertshaw]

Thank you for the icons, looks much better now 👌

I've also removed the opt-in to this feature from the heading block and added it to the navigation block instead.

[aaronrobertshaw]

I've rebased this to pull in the latest changes in approach to registering/applying block support. I think this just needs a review now to move forward.

[apeatling]

This one is working well for me via the navigation block. I think it looks ready to merge and look at further development beyond this PR.

[apeatling]

Failing e2e tests are timeouts and not related to this PR, so moving ahead with merge.

[github-actions]

Congratulations on your first merged pull request, @aaronrobertshaw! We'd like to credit you for your contribution in the post announcing the next WordPress release, but we can't find a WordPress.org profile associated with your GitHub account. When you have a moment, visit the following URL and click "link your GitHub account" under "GitHub Username" to link your accounts:

https://profiles.wordpress.org/me/profile/edit/

And if you don't have a WordPress.org account, you can create one on this page:

https://login.wordpress.org/register

Kudos!

[oandregal]

@aaronrobertshaw @apeatling This PR landed without documentation. I've prepared a fix for it at #26891