RichText: Begin to support hiding richtext controls while having keyboard shortcuts available #73181
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
…oard shortcuts available
andrewserong added [Type] Enhancement andrewserong requested review from aaronrobertshaw, ramonjd, talldan and tellthemachines 
| Size Change: +52 B (0%) Total Size: 2.42 MB
ℹ️ View Unchanged
|
ramonjd approved these changes Nov 12, 2025
| <EditFunction | ||
| key={ name } | ||
| isActive={ isActive } | ||
| isVisible={ isVisible } |
Member
There was a problem hiding this comment.
Just to confirm this is web only for now. Only mentioning since there's an index.native.js as well.
Contributor
There was a problem hiding this comment.
Is the native code still being maintained at all? There doesn't seem to be much recent movement on those files.
Contributor Author
There was a problem hiding this comment.
Good questions. I suppose it can't hurt to update the native code's format-edit.js file, too?
Member
There was a problem hiding this comment.
Actually, I might have been hallucinating. index.native.js doesn't even use format-edit' so probably not worth it.
Sorry for the red herring!
Contributor Author
There was a problem hiding this comment.
No worries, thanks for looking! I'll let this PR simmer for a bit to see what folks think.
| 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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Member
| Interesting idea, but it might be hard to make connection with Maybe we should use a prop name that's more format-specific, or do you expect |
Contributor Author
Good question. Right now the main ideas I have in mind is that we have a use case emerging of a generalised richtext control (I've just written up an issue in #73180) that would be useful for things like media fields (#72612), and that's being explored within the context of editable fields in the inspector sidebar (#71730 — still an experimental WIP, but it sparked the idea for this PR). I imagine if we're attempting to build out a rich text DataForm field/control (as explored in #71730), we'd probably want it configurable at the I'll admit it can be hard to settle on naming, though! My instinct is that because some of these other PRs are a little large and sprawling, that it'd be good to carve off the feature in smaller pieces. But sometimes the problem with going too small is that you can't quite see the whole just yet 😄 Happy to explore any ideas and/or put this PR on pause while we explore the shape of a RichTextControl, of course. |
Member
| I think it's was a good idea to to split into smaller PRs. Regarding naming, perhaps we should use a private prop until we're sure how this feature will work. This would prevent it from accidentally leaking as a public API. Adding todo comment with linked follow-up issue would also work. I'll be sure to trust your decision here. |
Contributor Author
| Oh, neat idea! I'll take a look at this again tomorrow with fresh eyes. Thanks for the thoughts and input! 😊 |
Contributor Author
| Update: after looking over this with fresh eyes, I think it's okay to land. The change to I'll merge this in now, but happy to revert / follow-up if anyone has any concerns! |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
What?
Part of: #73180 and split out from: #71730
In the block editor's rich text
FormatEditcomponent, and in some of the format library, allow support for settingisVisibletofalseto hide rich text controls while still allowing keyboard shortcuts to be available. Note: this PR doesn't quite expose this as an API forRichTextjust yet, it's just one step in this direction.This PR just looks at doing this for bold, italic, and link for now, but could be expanded in follow-ups to include other formats. Note that these formats are chosen for now as they're the prominent ones that appear in the block toolbar.
Why?
As described in #73180 and being explored in #71730 there is a need for editable fields where rich text is previewed and editable while not actually showing toolbar items. Common cases are bold, italic, and creating links.
How?
FormatEditcomponent to support passing down anisVisibleprop to the edit components for formatsisVisibleprop that defaults totrue. When this is falsy, the toolbar control will be hidden, but keyboard shortcuts will still workNote: this PR intentionally only addresses that above formats. In most cases, if folks want to hide formats they can simply exclude those formats. Whereas for bold, italic, and link, there is a common use case of wanting to allow keyboard shortcuts while hiding the visual controls.
Testing Instructions
With this PR, everything should behave exactly as on trunk. However to test this, you can pass
isVisible={ false }inRichTexthere:Then load up the post editor and go to edit a paragraph. You should be able to use keyboard shortcuts to set bold, italic, and links, but the buttons will not be displayed in the toolbar.
Screenshots or screencast
This is how it should look normally
If you apply the above diff to hide controls
You should be able to select text and use keyboard shortcuts to apply formats: