-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Font size: Allow for custom font size handling #58422
Font size: Allow for custom font size handling #58422
Conversation
Allow for custom font size handling in font size useBlockProps
Size Change: +245 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
Flaky tests detected in b3e2eb4. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7706633717
|
It's pretty weird. Here's the output: /* Rendered in the browser in editor JS */
font-size: clamp(31.152px, 1.947rem + 2.484vw - 7.9488px, 55px); /* True value generated by Gutenberg */
font-size: clamp(31.152px, 1.947rem + ((1vw - 3.2px) * 2.484), 55px); I've logged the output right up to the point of the edit function in the paragraph block and I'm seeing the "true" value. Maybe the browser (Chrome, FF and Safari) are doing some pre-render calculation/optimization 🤷🏻 I'm not sure it makes a difference visually 2024-01-30.16.20.09.mp4 |
Interesting! Could it be React or other processing doing any magic here? I notice the internal brackets have been removed so it feels like those calculations have been performed before the CSS string has been output, perhaps 🤔 For my own interest, I double-checked the MDN docs for clamp and it says that the current form of the clamp values we're using are valid:
So long as the computed value is the same either way, I don't think it matters personally, but it would be good to know what is causing the calculated to be flattened. Very strange! |
🤦🏻 I think we're good 😄 Looks like the browser (or React) is optimizing the calculation, which is written in long hand: (1vw - 3.2px) * 2.484 === 2.484vw - 7.9488px |
Thanks for checking @andrewserong Yeah it could be. It seems to have the math right, so I don't think there's a problem. 🤞🏻 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work @ramonjd, and thanks for adding the test coverage here so that we can be confident in the output! 🎉
This is testing nicely for me:
✅ In a theme with fluid
set to false
, the fluid output is bypassed
✅ In a theme with fluid
set to true
, the fluid rules are correctly output for custom font-sizes
✅ Preset font-sizes are output correctly, and this PR fixes a subtle bug with that. On trunk
I see the string for the preset was being output, but with this PR the real font size value is used. On trunk
I doubt we ever really saw the issue as the font-size from the classname winds up taking effect, but it's still a good bit of tidying:
Trunk | This PR |
---|---|
LGTM! ✨
Abstract addFilter
What?
Allow for custom font size handling in font size useBlockProps
TODO
Why?
To fix a regression. See: #56912 (review)
How?
Checking for the presence of a custom font size. If one exists, run it through
getTypographyFontSizeValue()
, which will return either the custom value orclamp()
value if the theme supports fluid typography.Testing Instructions