-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
WP 6.1: cherry pick #44993 (Fluid typography: add font size constraints) #45133
WP 6.1: cherry pick #44993 (Fluid typography: add font size constraints) #45133
Conversation
* Initial commit: - Adds default minimum font size limits so that text does not become smaller than 14px/0.875rem/0.875em. The consequence will be that all fluid font sizes will be no smaller than 14px/0.875rem/0.875em in any viewport width. - Users may define font-sizes that are smaller than 14px/0.875rem/0.875em. In this case the user-defined font size becomes the minimum. For example if a user defines 9px for a block, then the minimum font size for that block will be 9px. - Min font size should not be greater than max font size. - Round to 3 decimal places (JS) - Rounding computed min and max values * Rounding parsed min and max values * Updating JS rounding function so that values are rounded * Removing type coercion * Updating failing test * Remove reference to preset in favour of "fontSize" * Ensure that rem units are used when calculating min and max boundaries in em This is to keep it consistent with the original formula and ensure the fluid argument in clamp is working off a size relative to :root Fixing formatting and grammar Rolling back renaming $preset to $font_size in preference to a follow up. Do not clamp value if there is no min size and the font size is less than 14px * Oh Linter! You persistent crank. * For font sizes of < 14px that have no defined minimum sizes, use the font size to set the floor of the clamp() value. * Removing max < min check. It wasn't there before. It can be a follow up if required as it requires extra logic. * Checking for a zero-based linear factor. If we find one, default to `1` * Refer to correct JS var in JS file
Open in CodeSandbox Web Editor | VS Code | VS Code Insiders |
Size Change: +119 B (0%) Total Size: 1.26 MB
ℹ️ View Unchanged
|
No explanation for why the performance test is failing. There is nothing in the code that changes any selectors or editor nodes.
|
That's a known issue on the |
Thank you for the PR @ramonjd! Strictly speaking, adding the "Backport to WP Beta/RC" label to the originating PR (#44993) (plus manually backporting the PHP changes as you've done in WordPress/wordpress-develop#3489) should be enough: During our triage sessions on Monday, we go through all merged Gutenberg PRs with that label, and if they qualify as bugfixes, we cherry-pick them to the (There are only few exceptions when we deviate from that workflow, e.g. #45163, where the relevant code had diverged significantly in In order to avoid collisions, I'll have to either remove the label from both #44993 and this PR, or to close this PR. In order to fit in better with our workflow, I'm leaning towards the latter; unless there was something specific to these changes that made cherry-picking problematic? |
Closing for the aforementioned reasons. I've also verified that this PR's commit 3173e47 and #44993 's 963d836 are identical:
gives
|
Oh, thanks for the explanation. You are a gentleman! I was just hoping to make your lives a bit easier, but made it less so. Sorry!
That's perfect, thanks @ockham 🙇 |
What?
Cherry picks 963d836 merged into trunk from #44993
Why?
The Core patch with the PHP files has been backported to the 6.1 branch. See: WordPress/wordpress-develop#3489 (comment)
Testing Instructions
See: #44993