Convert Fit Text from Block Support to Standalone Block #72948
Conversation
jorgefilipecosta
requested review from
ajitbohra,
ellatrix,
fabiankaegy,
spacedmonkey and
tellthemachines
as code owners
|
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. |
jorgefilipecosta
added
[Type] Bug
|
Size Change: +50 B (0%) Total Size: 2.45 MB
ℹ️ View Unchanged
|
|
I think this feels a bit better to me. WDYT? A few things:
|
|
Hi @youknowriad,
I'm not sure both seem to be common, there are "Fit Text" libs in javascript and in some cases we also see Stretchy text. I don't have a big preference if you prefer "Stretchy text" I can change.
Done
It was added.
It was fixed.
Yes it is strange but it does not seems related to fit text, for example on the paragraph block I see the same behaviour. |
|
Would love more feedback here but this is working well. @mcsf @jasmussen |
|
I personally prefer 'Stretchy text' - it has a bit more character. 'Fit text' doesn't read quite right to me grammatically as a noun. I think 'Fit' is being used as a verb in that context. 'Fitted text' might be a little better, but I'm probably not the best person for copy advice. I think the block needs a new icon. At the moment it still shows the paragraph icon after switching it to a heading. Maybe an 'T' with some left/right arrows ( I see the same issue as Riad when testing with padding. This is what I see for a regular paragraph: The new block overflows the right padding: |
|
Just an extra thing - if this PR is merged, it'd be good to also consider the block for bindings and pattern overrides support now that it's not a regular paragraph/heading. I think that might be easy enough to do, but it might be a 7.0 consideration now so late in the 6.9 process. It's a shame as this will be a really cool block in patterns. Curious for thoughts (cc @ockham @cbravobernal). |
|
Honestly I could go both ways on this. I don't think the pro/con lists are really exhaustive or conclusive, have we thought through potential future edgecases? I'm making this up, but imagine we had responsive controls, perhaps I want it to be "fit text" on desktop, but just a paragraph on mobile. That would work better with the supports. But perhaps it ultimately boils down to: "what feels better". I mean that both in the user experience and code-wise. As a longshot, perhaps @beafialho has thoughts: paragraph extension or standalone block? And yes I guess we need a new icon if we go this route. |
|
A fairly strong argument for keeping it a block-support just occured to me. I would like to use fit-text on the site title block, so that I can have the title always span the width of the site. I would have to hardcode the site title into a standalone block, whereas with a block supports, the site title could have it as a property of the typography panel. I try to not have strong opinions, but I feel like this is a pretty solid reason to not convert it back to a block. |
|
Hey folks, a theme designer chimming in on this conversation 👋🏻 As a hard user of this kind of feature, I’d say I’m with @talldan on the naming and with @jasmussen on the format. Despite being minimal, |
|
Hi @jasmussen, @henriqueiamarino thank you for the insights shared, The reason why we went the block supports route was exactly what is being referred allow blocks even dynamic ones like site title or post title to use fit text. It is a more versatile solution. But this is not something standard on the web it is not just some CSS it involves JavaScript with some loops, so I can also understand the argument that at least for now it should be contained in some specific, and we don't want to use widely in things like post title. Maybe there is some middle ground like an experimental block support, and exposing it just in a specific (new block) or a variation of a block? Leaving the path open for future additions to other blocks. I'm fine with either direction we choose and open to change paths if we decide to do so. |
|
Those are valid arguments too. So it really does boil a bit down to compartmentalizing the feature for discoverability, or making it widely available for utility. I'm increasingly in camp utility, and one reason why is because I love this theme, which ships with the feature. It uses the block from a previous iteration, to be clear, not a site title. But it is a testable, demoable, reason for why site title would benefit from the feature. I'm also happy to support either direction. |
|
If the issue is discovery, I'm curious why we don't rethink using variations to make it appear in the block inserter? We had that originally but then removed it in #72408 |
|
I believe we need to decide on a direction for this issue before the RC1 release, so I would like to gather more feedback. @WordPress/gutenberg-core
Personally, I don't consider these to be problems. There are many block supports where the controls are hidden by default. I'm not sure why it's necessary to specifically highlight only the "fit text block support" feature. |
|
I think the UI concern with applying this is valid, and it's a very similar concern with how to apply the drop cap. But that's a fixable UI aspect, and one that we should look at regardless. |
|
Just my two cents, but I'd lean towards the more versatile long-term solution, one that empowers third-party devs i.e. block supports.
I'd also agree with @t-hamano here in that I'm not sold these are major issues. Blocks that benefit from this feature having a higher profile could also display the control by default, increasing discoverability slightly while also reducing friction. Additionally, the majority of the benefits listed for this being a standalone block are also provided by the block variation option. |
luisherranz
left a comment
luisherranz
left a comment
There was a problem hiding this comment.
Reviewing the Interactivity API part.
| "interactivity": { | ||
| "clientNavigation": true | ||
| }, |
There was a problem hiding this comment.
This block is interactive.
| "interactivity": { | |
| "clientNavigation": true | |
| }, | |
| "interactivity": true, |
| } | ||
|
|
||
| // Enqueue the frontend script module. | ||
| wp_enqueue_script_module( '@wordpress/block-library/fit-text/view' ); |
There was a problem hiding this comment.
Replace with viewScriptModule field in block.json, like this.
| if ( ! $processor->get_attribute( 'data-wp-interactive' ) ) { | ||
| $processor->set_attribute( 'data-wp-interactive', true ); | ||
| } | ||
| $processor->set_attribute( 'data-wp-context---core-fit-text', 'core/fit-text::{"fontSize":""}' ); | ||
| $processor->set_attribute( 'data-wp-init---core-fit-text', 'core/fit-text::callbacks.init' ); | ||
| $processor->set_attribute( 'data-wp-style--font-size', 'core/fit-text::context.fontSize' ); |
There was a problem hiding this comment.
You don't need to use namespaces in the directives now, as this is an interactive block, and it's those who extend this block that should use their own namespaces.
| if ( ! $processor->get_attribute( 'data-wp-interactive' ) ) { | |
| $processor->set_attribute( 'data-wp-interactive', true ); | |
| } | |
| $processor->set_attribute( 'data-wp-context---core-fit-text', 'core/fit-text::{"fontSize":""}' ); | |
| $processor->set_attribute( 'data-wp-init---core-fit-text', 'core/fit-text::callbacks.init' ); | |
| $processor->set_attribute( 'data-wp-style--font-size', 'core/fit-text::context.fontSize' ); | |
| $processor->set_attribute( 'data-wp-interactive', 'core/fit-text' ); | |
| $processor->set_attribute( 'data-wp-context', '{"fontSize":""}' ); | |
| $processor->set_attribute( 'data-wp-init', 'callbacks.init' ); | |
| $processor->set_attribute( 'data-wp-style', 'context.fontSize' ); |
| import { optimizeFitText } from './utils'; | ||
|
|
||
| // Initialize via Interactivity API for client-side navigation | ||
| store( 'core/fit-text', { |
|
Would adding a block variation resolve the UX concerns? - i.e. undoing #72408 |
|
I'm in agreement with @jasmussen, @t-hamano, and @aaronrobertshaw - I don't think this should get set as its own block. I also agree with @fabiankaegy and @scruffian that if we want discoverability, exposing the block variation in the inserter by reverting #72408 seems like a better route. |
|
I think my vote right now would be:
|
|
I think a variation is the minimum and probably hiding the block support from all the non variation blocks (to avoid confusion with all the other font related changes you can make). I would love to see an alternative PR with the variations approach to make the right call. |
|
I'm not opposed to adding variations themselves, but with the current inserter logic, variations are added next to the block. In this UI, the stretched variations are far too prominent: 
I think we probably need a new option or logic to lower the priority of variations only.
+1 |
|
I don't think we should leave things as is though. The experience is clunky and doesn't add value to the users. No one is going to find that toggle, people search for things like "stretchy text" or "fit text" in the inserter. |
I looked a bit into the code where we show the inserter items and I think it will add more complexity than it worths it to handle some variations differently and add them later on the list and not next to the block they belong. We shouldn't do it for all variations, because besides this specific use case, it makes sense to show the variations as we do now. |
I wonder how many users will be looking for these blocks at all - maybe we should expect them to find them via patterns and themes... |
I absolutely agree. As an alternative idea, instead of adding block variations, we could publish a dev note. For example, something like this. The fitText block support automatically scales text to fit the available width, making headings and key copy responsive without manual font-size tweaks. Expose ready-to-use “stretchy” presets by registering variations that set fitText: true. These appear in the inserter for one-click insertion. wp.blocks.registerBlockVariation(
'core/heading',
{
name: 'stretchy-heading',
title: 'Stretchy Heading',
attributes: { fitText: true },
}
); |
|
The UX issues found are clear, but converting it into a block contradicts the concept of the feature. Fitting the container is a size property of any text. Making it a block doesn't solve the discoverability issue, unless it's shown at the top of the list. But with this logic in mind, the toggle could be visible below the font size by default as well.
Is this an assumption or do we have research data supporting it? Asking it because searching for a feature does not imply looking for a block. The friction set can be more simple by placing the affordance in the custom font size, or visible by default below the font size. Here is a quick idea. 
On the other hand, and not sure if this already exists, the "unclear differentiation" point can be addressed by replacing the block icon in list view, just like when changing from Group to Row or Stack. Although this distinction contradicts the recognition of whether it's a paragraph or a heading. |
|
A dev note targets developer, this feature targets users. We should make sure users that want stretchy text find the blocks in question. |
Hi @youknowriad, I proposed an alternative approach, following the variation path at #73056. |
github-project-automation
bot
moved this to 🔎 Needs Review
in WordPress 6.9 Editor Tasks
|
Many folks seem to prefer the variation approach rather than the block approach. Let's close this PR and focus on #73056. |
github-project-automation
bot
moved this from 🔎 Needs Review
to ✅ Done
in WordPress 6.9 Editor Tasks
Fixes: #72947
What?
Converts the fit text functionality from a typography block support (used by paragraph and heading blocks) to a dedicated
core/fit-textblock.Why?
Based on UX feedback during the beta stage, the block support approach presented several usability issues:
Problems with Block Support
Benefits of Standalone Block
Testing Instructions
Insert fit text block:
Type content and observe automatic size scaling
Test level switching:
Test alignment changes:
Test content changes:
Test frontend:
Screenshots
Related
Follows similar pattern to Site Title block which also supports level switching.
cc: @mtias, @youknowriad