Block Support: Add text decoration block support using CSS variables

[aaronrobertshaw]

Description

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

Changes Included

• Adds block support for text decoration
• Allows for preset text decoration options and uses CSS variables
• Adds new icon for "underline"
• Updates navigation block to opt-in to text decoration support for easier testing

Notes

• The intention is when this and text transform block support (Block Support: Add text transform block support using CSS variables #26060 ) 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 navigation block to a post and select it.
2. You should see new text decoration buttons under the Inspector Controls > Typography section.
3. Toggle the various decoration buttons and confirm the block updates visually as you'd expect.
4. With a text decoration toggled on, inspect the navigation 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 decoration 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.

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 Decoration 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]

I think we'll want to match icons up here, but will defer to others on thoughts. @aaronrobertshaw I did notice if another setting like line-height is present it bumps up against this:

[apeatling]

@nosolosw Pinging you on this (plus #26050 and #26060) to see what we'd need to do to move these forward?

[aaronrobertshaw]

I think we'll want to match icons up here, but will defer to others on thoughts. @aaronrobertshaw I did notice if another setting like line-height is present it bumps up against this:

I've tidied up the controls and switched the buttons to use icons which avoids i18n of the preset names.

Current Controls:

[oandregal]

Pinging you on this (plus #26050 and #26060) to see what we'd need to do to move these forward?

The direction seems good and I can help review/move this forward today. I'd like a confirmation from folks @mtias @youknowriad as if we want this for 5.6 (merge before Monday) or can land after.

[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?

cc @ItsJonQ

[aaronrobertshaw]

@jasmussen Would you have a few moments to share any design thoughts on this one and #26060 ?

[jasmussen]

Thanks for the ping.

High level, we need a good design and pattern for such controls. I think icons in a segmented control is a good general approach, both for text decoration and text transform. It also needs to default to being unset, and for there to be an easy way to unset it.

I would note that I see both text decoration and text transform controls as primarily global styles, and while you should be able to override them on a per paragraph basis, you should not see them by default. I'd love to get you a design that accomplishes this, but unless this can be limited to just global styles, I'd think it won't be a good experience to ship in 5.6.

[aaronrobertshaw]

As part of discussions around the UI for this PR's text decoration controls and the text transform controls from #26060 it is likely they both will be displayed on a single row within the Typography panel.

I've updated this PR with a new component that will cater to achieving such a layout. The changes also include simple icon only styling.

[jasmussen]

Awesome. Can you update the underline icon to use this SVG?

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M7 18v1h10v-1H7zm5-2c1.5 0 2.6-.4 3.4-1.2.8-.8 1.1-2 1.1-3.5V5H15v5.8c0 1.2-.2 2.1-.6 2.8-.4.7-1.2 1-2.4 1s-2-.3-2.4-1c-.4-.7-.6-1.6-.6-2.8V5H7.5v6.2c0 1.5.4 2.7 1.1 3.5.8.9 1.9 1.3 3.4 1.3z"/></svg>

[mtias]

Looking good! Let's make sure we only enable these new tools in dynamic blocks at first (navigation, site title, etc) and not on headings and paragraphs just yet.

[aaronrobertshaw]

Thanks for the continued feedback.

• New underline icon has been added
• Removed the opt-in to this feature from the heading block
• Updated the navigation block to opt-in to this and tweaked its CSS to allow the text decoration selection to be inherited.

[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]

Confirmed working well for me on the navigation block. I think it's good to merge and we can follow up on any further development in new PRs.

[aaronrobertshaw]

I've rebased and resolved conflicts for this after merge of text transform support #26060

[oandregal]

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