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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jameskoster <[email protected]>
Co-authored-by: ciampo <[email protected]>
Co-authored-by: aduth <[email protected]>

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

Size Change: 0 B

Total Size: 6.89 MB

_{compressed-size-action}

The general approach looks good, although I thought we discussed splitting Text (defaults to span) from Heading (defaults to h2), and split the variants accordingly.

Hm, my initial reaction would be that this is exactly what render prop is meant to support as far as controlling the element, though I think the argument is more compelling in how it affects what variants are available, even allowing the option to remove the prefixes.

So rather than...

<Text variant="body-md" />;
<Text render={ <h2 /> } variant="heading-2xl" />;

We could have:

<Text variant="md" />;
<Heading variant="2xl" />;

But a couple problems:

• Is h2 a good default for <Heading />, or could that end up being a foot-gun that people choose the wrong heading level, or we risk having to make render a required prop? With the Text example, the fact that you need to override to use a heading element forces you to make the heading level choice explicitly.
• Do we want the ability to mix-and-match variants, like the option to use heading styles for non-heading elements, etc. I suppose that's still possible with something like <Heading render={ <span /> } variant="md" />. It could be a problem if we wanted to add additional groupings, or if we're concerned about Text defaulting to "body" variants.

@aduth you make good points. Maybe we could continue to adopt a "lazy" approach, starting with a unified Text and only splitting if/when we see a need for it?

@aduth you make good points. Maybe we could continue to adopt a "lazy" approach, starting with a unified Text and only splitting if/when we see a need for it?

Sounds good to me 👍

@jameskoster we have consensus re. keeping only Text with all body / heading variants for now. Feel free to address the rest of the feedback, and I'm confident we'll be able to merge this soon 🎉

Let's also think about follow-ups:

• sort out typography settings (renaming / regrouping them, consider adding letter spacing, switching line-height to be unitless?)
• refactor existinng @wordpress/ui components to use Text internally

I had the same conversation about a dedicated Heading component when planning with my agent haha. Glad we arrived at the same place (for now)!

I'll address the remaining feedback shortly.

@aduth I updated Notice to consume Text. Happy to revert if you'd prefer to handle that separately.

Flaky tests detected in 6f04d4f.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/22867237462
📝 Reported issues:

• [Flaky Test] Custom Completer: should insert option between two other words #48566 in /test/e2e/specs/editor/various/autocomplete-and-mentions.spec.js
• [Flaky Test] User Mention: should insert two subsequent mentions #48569 in /test/e2e/specs/editor/various/autocomplete-and-mentions.spec.js
• [Flaky Test] should undo bold #48558 in /test/e2e/specs/editor/various/undo.spec.js