[New Block] Stretchy Text #71017
Draft
[New Block] Stretchy Text #71017
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
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
|
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. |
|
Size Change: +1.41 kB (+0.07%) Total Size: 1.91 MB
ℹ️ View Unchanged
|
scruffian
commented
Aug 1, 2025
| **/ | ||
| function register_block_core_stretchy_text() { | ||
| // TODO - only enqueue the script if the block is used. | ||
| wp_enqueue_script_module( '@wordpress/block-library/stretchy-text/view' ); |
There was a problem hiding this comment.
Is this the best way to add a module? Should we start supporting the viewFile key for core blocks?
scruffian
commented
Aug 1, 2025
| register_block_type_from_metadata( | ||
| __DIR__ . '/stretchy-text', | ||
| array( | ||
| 'style_handles' => 'wp-block-stretchy-text', // TODO - this shouldn't be needed. |
There was a problem hiding this comment.
Without this CSS isn't added but I can't work out why.
|
It's an interesting block, but it seems very niche for inclusion in core, IMO. Maybe something for #58773. |
|
I personally don't believe that this block should be in WordPress core. It is too niche. To me this again is a perfect example of why we should have a separate plugin for these specialty blocks. CC: @Mamaduka as I know you also had responded similar tickets in the past I love the block personally and already saw it in the special projects monorepo. So this isn't about that, it's just about thinking what's a good fit in core since we have to maintain it etc... |
|
@fabiankaegy, I've "blocked" a couple of new block proposals for similar reasons (they're probably cross-linked in #58773). Niche blocks don't fit WordPress' "Clean, lean, and mean" philosophy. |
|
I think not having these blocks in the core library severely limits the expressiveness that theme builders (and users) can depend upon to build great designs and it can fracture the overall experience, forcing people to go for more fully equipped block libraries instead or desist altogether if they plan to release something broadly. One of the promises of blocks is that we can finally make themes interoperable without dulling down expression. A separate plugin for these blocks won't help much if a person needs to release a theme or a pattern in the directory, cannot rely on the presence of the block, or is excluded because it doesn't use core blocks. My opinion is that we should add a lot more blocks and revise a stance that I think harms adoption in this day and age. |
|
@mtias, I thought Block Directory had to mitigate some of those problems. Makes the block easy to discover and install straight from the canvas/inserter. Cons of niche blocks in Core
Pros of canonical blocks in the directory
Most importantly, the project needs clear guidelines for adding new blocks in the core. Something all contributors can refer to when needed. P.S. Sorry that I'm using this PR as an example. I really don't have anything against this block. |
|
@scruffian, I accidentally came across this issue - #56324. I think we can reference it in the description. Is the current work based on https://specialprojects.automattic.com/tools/stretchy-type/? If yes, it's probably worth a mention in the description as well. |
|
Stumbled on this PR while implimenting Roman Komarov's approach (mentioned in the description) in a plugin and looking for a solution that meets Success Criterion 1.4.4: Resize text. In my implementation users cannot zoom reliably to 200%. Does this approach solve that? If so I would just not release the plugin since core would be better equipped to meet accessibility requirements for it over time. |
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?
This PR adds a Stretchy block that makes its text fill all the available width. It uses SVGs to maintain the text ratio and some JavaScript code to update it whenever the text changes.
Features:
Supports:
The supports are based on the paragraph block, but with a few differences:
Props @DAreRodz who did all of the work on this originally in https://specialprojects.automattic.com/tools/stretchy-type/
Why?
This has been a useful block on many sites, so it would be good to have it in core.
How?
The implementation uses the following APIs, listed with the global usage % of browsers that support them:
ResizeObserver (95.37%)
SVG foreignObject (94.9%)
CSS fit-content (94.9%)
The main idea is to use an SVG wrapper with foreingObject around the HTML code of the block content. With the SVG wrapper, we can use the viewBox property to make a scalable SVG that maintains its size ratio.
In addition, it uses ResizeObserver and a span wrapper with width: fit-content to monitor changes in the SVG content. That way, we can react to any changes that modify the text dimensions and update viewBox accordingly. This only happens when the text size ratio changes.
(*) The viewBox property is computed in the editor and persisted in the HTML. This effectively sets an initial value for viewBox without JavaScript, which mitigates the problem of scaling the SVG with code. However, that value is not 100% reliable, as different users could see different fonts with different sizes for the same text.
Alternatives
Window 'resize' event + computed font-size
This approach only reacts to changes in the viewport size, meaning that the size won't be re-computed when the element content changes dynamically or when the parent container dimensions change. Also, the font-size prop should be updated anytime the available width changes per frame.
ResizeObserver (95.37%) + computed font-size
This approach is similar to the above, but it uses a ResizeObserver in the parent container rather than subscribing to resize events on window. It can react to the available width, although it still has to update font-size per frame.
Container Query Units (90.97%) + ResizeObserver + computed var(--ratio)
This one is similar to the SVG approach. The difference is that it uses container query units to set a font-size value relative to the container's width. The text's height/width ratio is re-calculated whenever the text changes and the font-size value updated accordingly.
CSS custom properties (89.97%) + Container Query Units
This only-CSS solution could be based on Roman Komarov's Fit-to-Width Text technique. We tested it in the feature/stretchy-type-paragraph branch. It's reliable in most cases, but some fonts seem to be adjusted incorrectly.
Testing Instructions
Screenshots or screencast
TODO
Questions