-
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
Fluid typography: custom values should be set as maximum font size #45504
Comments
Thanks for writing all this up!
Good question. I'd be curious to hear what the expectations are from a designer's perspective, but personally I like the idea of the consistency of setting the upper bound for presets, too. If we make the change, existing themes that liked the fact that the preset was set for the middle value can always add a
If picking a font-size sets the upper bound, perhaps when a user selects font-sizes lower than |
Thanks @andrewserong ! This featured in one of the prior commits in #44993. I was quite fond of it at the time 😄 |
I might not be parsing this right, but I would say, if
What do you think? |
I really like where this PR is headed, and it addresses some concerns we have seen surfacing since 6.1 release. Therefore, I have added it to the 6.1.1 board. I completely agree that the set custom size should act as the maximum.
This seems like a solid approach. |
Thanks everyone for the input, and I know there are a lot of variables to look at, so I appreciate the patience. I'll take a stab at simplifying things, and disabling clamp in certain situations, and we can try it out. It might be more accessible to critique the UX when we have something to play with. |
@ndiego I've just taken a look at the planning schedule https://make.wordpress.org/core/2022/11/04/wordpress-6-1-1-planning/ I won't be able to get this done before the due date. Next week is out for me. Sorry! |
Just gather requirements here. Does this sound compatible with everyone's requirements so far? 1. Try to clampify every value if fluid: true.❗ For single values with no set min or max use the value as the max value. When calculating the min value, if it's < 14px, then set it to 2. If a single value with no set min or max (preset or custom) is <= than 14px, don't clampify.Applies to the following presets in theme.json: "fluid": true,
"fontSizes": [
{
"size": "14px",
"slug": "small"
},
{
"size": "12px",
"slug": "smaller"
},
... Also all styles in theme.json, including elements and blocks: "styles": {
"typography": {
"fontSize": "12px"
},
... All including custom values from block supports, so: array(
'style' => array(
'typography' => array(
'fontSize' => '12px',
)
)
) 3. Always clamp for a preset value with both min and max values. Do not apply 14px rule.Applies to the following presets in theme.json: "fluid": true,
"fontSizes": [
{
"size": "14px",
"slug": "small",
"fluid": {
"min": "2px",
"max": "48px"
},
},
{
"size": "13px",
"slug": "small",
"fluid": {
"min": "14px",
"max": "48px"
},
},
... 4. For a preset value with min value only, use "size" as max. Do not apply 14px rule."fluid": true,
"fontSizes": [
{
"size": "14px",
"slug": "small",
"fluid": {
"min": "2px",
},
},
...
5. For a preset value with only max values, then use size * min_factor as the value. Apply 14px rule."fluid": true,
"fontSizes": [
{
"size": "15px",
"slug": "small",
"fluid": {
"max": "200px",
},
},
...
I like the idea of ignoring the 14px min rule for presets where a min value is provided. This way we're giving greater control to theme authors who go to the trouble of specifying min/max. The only question is around 4, that is, what to do when no min value is supplied, but a max is. We can either:
|
I've got something up to test in the meantime: #45536 But probably won't get much time over the next week or so to work on it. |
@WordPress/block-themers if possible, it would be amazing if you could help test this with all that's going on 👆🏼 |
I think this makes sense and would be an improvement. |
There is nothing in the UI to communicate this. Do you think it would be a good follow up? We can add it as a proposed enhancement under #44888
In theory, the change proposed by this issue will mitigate this, but maybe we could add something to the font size picker header hint. |
This is working as I would expect it to now, and the custom size is being used as the max when no explicit max is set. I tested this via both I also agree that this change should mitigate some of the confusion for user-entered font-sizes, but adding the "(Fluid)" text to the label would help in a followup. |
Would "responsive" be a word users are more familiar with? |
I think 'responsive' and 'fluid' are slightly different when reading: Or this post: https://ux.stackexchange.com/a/24408
|
Users as in not developers and designers. |
PHP backport to Core (assuming no further changes to #45536): |
Parent issue:
What problem does this address?
When converting custom font sizes to fluid values, the fluid typography functions calculate the minimum and maximum font sizes either size of the given custom font size.
Depending on the viewport width, the resulting fluid value may have a maximum font size value larger than the original custom value.
This may contradict user expectations.
What is your proposed solution?
In future, all custom values should act as the maximum value in a
clamp()
function.For example, if
8px
is the custom value provided, it would be the maximum as would1000px
.As for the minimum size, the feature already calculates using a default factor of
0.75
. In the case, we should trust that users will know themselves what’s too small for their site and what isn’t.❗ Open questions
< 14px
the clamp() value’s min argument will be corrected upwards. How should we set the minimum value where a maximum custom value is< 14px
?cc @mtias @jasmussen
The text was updated successfully, but these errors were encountered: