Fluid typography: add min and max viewport width configurable options #53081
Conversation
ramonjd
added
[Type] Enhancement
|
This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress. If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged. If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack. Thank you! ❤️ View changed files❔ lib/block-supports/typography.php ❔ phpunit/block-supports/typography-test.php ❔ phpunit/data/themedir1/block-theme-child-with-fluid-typography-config/theme.json |
|
Size Change: +49 B (0%) Total Size: 1.44 MB
ℹ️ View Unchanged
|
- add min and max viewport width to the theme.json schema - supporting min and max viewport widths in PHP typography block supports
ramonjd
force-pushed
the
add/fluid-typography-min-max-viewport-width
branch
from
0592224
to
314ea97
Compare
Max and min viewport values should be taken from $fluid_settings ;-P
ramonjd
requested review from
spacedmonkey,
ellatrix and
ajlende
as code owners
ramonjd
requested review from
andrewserong,
noisysocks,
jasmussen,
apeatling and
tellthemachines
and removed request for
spacedmonkey,
ellatrix and
ajlende
|
Wow, that was super quick! Thanks @ramonjd! I hope this makes it in the next release since I believe that's when the max viewport width change is hitting 🤞 I (and our clients) really appreciate your work! |
lib/block-supports/typography.php
Outdated
| $default_minimum_viewport_width = '320px'; | ||
| $default_maximum_viewport_width = isset( $layout_settings['wideSize'] ) ? $layout_settings['wideSize'] : '1600px'; | ||
| if ( isset( $fluid_settings['maxViewportWidth'] ) ) { | ||
| $default_maximum_viewport_width = $fluid_settings['maxViewportWidth']; |
There was a problem hiding this comment.
nit: does it still make sense to call this variable default_maximum_viewport_width now that its value is customisable?
I just noticed that, too! It seemed quite delightful to me 😀 |
Thanks for raising that. I was actually agonizing over this for the min/max font size values in the fluid presets as well and decided to not guard against user input in theme.json. My reasoning was that there are a bazillion ways to break a site using weird theme.json values, and getting min and max definitions mixed up was the least of our worries. Having said this, I don't expect it to be very hard to return early if we detect a min value that is greater than max (and vice versa) if you think it's worth it. Very happy to update this PR to that effect. |
I'd gently vote for leaving the behaviour as-is without guarding against whether one value is bigger/smaller than the other. I don't feel strongly about it, though 🙂 |
Thanks for the thoughts @porg At the moment the fluid calculations require numbers to generate the scale factors, but another thing that we could consider is porting over the See: https://github.com/WordPress/gutenberg/blob/trunk/schemas/json/theme.json#L33 The gist of it is that we could specify a path in the theme json to arrive another value in the JSON tree. Example: "settings": {
"appearanceTools": true,
"layout": {
"contentSize": "840px",
"wideSize": "1100px"
},
"typography": {
"fluid": {
"maxViewportWidth": {
"ref": "settings.layout.contentSize"
},
"minViewportWidth": "600px"
}
}
},Edit: I've added this idea to the tracking issue |
|
That's a fair summary.
I'm the only one actively working on fluid typography, which is good and bad. Good that I can understand issues (maybe) more quickly, but bad in that it's a competing demand on my time. If it's on the tracking issue, it won't be forgotten. Once I get time to address it then a standalone issue/PR will be pushed to cover it. |
ramonjd
removed
Needs PHP backport
|
Created standalone issue (for tracking!) Which please should be added to section "Wishlist" at: Thanks! |
There was a problem hiding this comment.
Edited: whoops, added a comment to the wrong PR! 😅 (I meant to add a review to #53551)
|
Hey Everyone! I'm not sure if this is the right place to ask this question. I see that this PR has been merged into trunk (thank you again @ramonjd!), but did not make it into the WP 6.3 release. Is there any chance that this change could be included in a minor release in the next couple weeks? We have several sites developed under the previous paradigm (1600px If this PR cannot be deployed in a minor release, we're faced with the prospect of upgrading to 6.3 and having to check many hundreds of pages at every viewport width to confirm if text sizes need to be changed, or waiting several months for another major release before updating WP. Both are daunting propositions. I'm not really sure who makes the decisions about what gets included in minor releases, but if you can point me in their direction I will throw myself on their mercy in hopes of getting this update included 😬 |
|
Thanks @eric-michel At this stage, because it's a new feature and not a major bug fix, I'm not sure that this PR's changes will arrive in the next minor release. 6.4 is a couple of months away I believe. Could you install the Gutenberg plugin perhaps to get the functionality you need? |
|
@ramonjd I was afraid of that, sadly. Is there anyone I can make my case to who makes the decisions about what gets folded into minor releases? This is more of a backwards compatibility issue for us than a new feature. If not, we'll just let our clients know that we'll need to wait for 6.4 before updating. Not ideal, but not the end of the world. I'm tempted to try the Gutenberg plugin as you suggested, but I'm wary of adding a bunch of other features that may have unintended effects. I appreciate the suggestion though! |
I'd defer to @tellthemachines or @ndiego but given the tight timeline I'm not sure sure it'll make 6.3.1. In upcoming work, there's a case for a filter to short-circuit typography values. This might provide options for developers in the future between the staggered introduction of new features.
I'm happy to help as much as I can if you run into issues. There have been quite a few new features introduced and it might not be as stable as core, depending on your setup. |
I'm just catching up here. This is a new feature, right? |
Technically, yes so I think we could aim for 6.4? There's a core backport patch ready |
|
Yeah, my gut is saying 6.4. Unless there are extenuating circumstances, and all leads would need to agree, there really shouldn't be any new features in minor releases. Just major bugs as you mentioned. |
✍🏻 Dev noteFluid typography: configurable minimum and maximum viewport valuesWordPress 6.4 introduces configurable minimum and maximum viewport width values to fluid typography settings in theme.json. Theme developers can now define their own default viewport "boundaries" for calculating fluid font sizes. These boundaries determine the browser viewport widths at which any font size clamp values will stop being "fluid". For example, given the following theme.json settings: "settings": {
"typography": {
"fluid": {
"maxViewportWidth": "800px",
"minViewportWidth": "600px"
},
}
}Between the browser widths of Due to the way the Block Editor calculates fluid font size values, In the case of unsupported values, including CSS variables, fallback |
|
I was hoping this might take place of using a fluid type mixin in my sass so I only have to set the theme font sizes in one location but I cannot figure out how is this calculation done using The example values of 600px and 800px, scaling happens between 475px and 675px. It doesn't make any sense. I am running WP 6.4.1 |
|
Hi @mhennessie Thanks for the feedback. I'm interested to learn about your setup, and how you're testing it, including theme.json settings and the blocks HTML. I've been testing with a basic theme and no plugins. Here's the theme.json I'm using "settings": {
"appearanceTools": true,
"layout": {
"contentSize": "840px",
"wideSize": "1100px"
},
"typography": {
"fluid": {
"maxViewportWidth": "768px",
"minViewportWidth": "1440px"
}
}
},And the block HTML<!-- wp:group {"style":{"spacing":{"blockGap":"var:preset|spacing|60","padding":{"left":"var:preset|spacing|50","right":"var:preset|spacing|60","top":"var:preset|spacing|70","bottom":"var:preset|spacing|80"},"margin":{"top":"186px","bottom":"199px"}},"border":{"width":"40px"}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group" style="border-width:40px;margin-top:186px;margin-bottom:199px;padding-top:var(--wp--preset--spacing--70);padding-right:var(--wp--preset--spacing--60);padding-bottom:var(--wp--preset--spacing--80);padding-left:var(--wp--preset--spacing--50)"><!-- wp:paragraph {"style":{"typography":{"fontSize":"104px"},"color":{"background":"#f8700e"}}} -->
<p class="has-background" style="background-color:#f8700e;font-size:104px">test</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->Checkout the computed font-size down at the bottom right. 2023-11-22.10.03.01.mp4The boundaries appear to work as intended. The "test" paragraph has a max font-size of 104px, which is reached once the window size reaches |
|
Here is what I have... the H1 should be 40px when the viewport is less than 576px and 48px when the viewport is more than 1200px. This is a custom theme but only ACF is installed and I have disabled the fluid type mixin for the H1. The block I am testing is just the core/heading block. The block html is a simple H1 heading block: <h1 class="wp-block-heading">This is an H1 heading</h1>Generated css var --wp--preset--font-size--h-1: clamp(40px, 2.5rem + ((1vw - 5.76px) * 1.282), 48px);The theme.json looks like this (truncated): "settings": {
"layout": {
"contentSize": "100%",
"wideSize": "1440px"
},
"typography": {
"fluid": {
"minViewportWidth": "576px",
"maxViewportWidth": "1200px"
},
"fontSizes": [
{
"size": "48px",
"fluid": {
"min": "40px",
"max": "48px"
},
"slug": "h1",
"name": "H1"
}
]
}
},
"styles": {
"elements": {
"h1": {
"spacing": {},
"typography": {
"fontFamily": "p22-mackinac-pro",
"fontSize": "var(--wp--preset--font-size--h-1)",
"lineHeight": "1.2"
}
}
}
}wp-fluid-type.mov |
|
Thanks for providing extra details.
On your screencast I'm seeing that the H1 goes down to around 42ish px at the minimum width, but it respects the 48px maximum. I tried again using your theme.json settings. WordPress 6.4.1, no plugins and very bare-bones block theme, and I can't reproduce: 2023-11-23.11.57.16.mp4Same with Gutenberg activated. Are there any surrounding HTML elements whose styles might be affecting things here?
Is that a sass mixin? |
|
Ok, I figured it out. My root font-size was 18px in my css which completely throws it off. Changing it to 16px, it works perfectly. Thank you for helping me troubleshoot this! |
Good stuff. Happy to help. |
What?
Welcome to this PR!
Please test its exciting features. Wow!
We're adding configurable min and max viewport width values to the
typography.fluidtheme.json schema, to allow theme developers to configure their own default min and max viewport widths for calculating fluid font sizes."What do the min and max viewport widths do?" you ask? Good question.
They define the boundaries, in terms of viewport widths, at which font size clamp values will stop being "fluid". For example, consider the following theme.json settings:
Between the browser widths of
600pxand800pxa font size will be fluid. If the browser width is narrower or wider, the font size will no longer shrink or grow.See this fascinating screencast that demonstrates the above claim now! Witness how the computed
font-sizechanges as the browser moves between800pxand600px, but remains static higher or lower than those values. Unbelievable!2023-08-04.11.15.13.mp4
Why?
wideSizevalue (introduced in Fluid typography: use layout.wideSize as max viewport width #49815). Here is the background behind this motivation:TODO
maxViewPortWidthtomaxViewportWidthin the JS to be more consistent with the PHP property and also recognize that viewport is one word 😄 Fluid typography: rename viewport variables #53082How?
By accepting
maxViewportWidthandminViewportWidthvalues from theme.json settings in the editor and frontend.Testing Instructions
maxViewportWidthandminViewportWidthfont-sizevalues of the elements as you vary the width of the viewport.maxViewportWidthtakes precedence over anysettings.layout.wideSizevalueExample theme.json
{ "version": 2, "settings": { "appearanceTools": true, "layout": { "contentSize": "1000px", "wideSize": "1100px" }, "typography": { "fluid": { "maxViewportWidth": "800px", "minViewportWidth": "600px" } } } }Example block HTML