Skip to content
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

Closed
ramonjd opened this issue Nov 3, 2022 · 16 comments · Fixed by #45536
Closed

Fluid typography: custom values should be set as maximum font size #45504

ramonjd opened this issue Nov 3, 2022 · 16 comments · Fixed by #45536
Assignees
Labels
[Feature] Typography Font and typography-related issues and PRs [Type] Enhancement A suggestion for improvement.

Comments

@ramonjd
Copy link
Member

ramonjd commented Nov 3, 2022

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.

Screen Shot 2022-11-03 at 1 21 30 pm

Screen Shot 2022-11-03 at 1 21 43 pm

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 would 1000px.

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

  1. Currently, 1) font values under “styles’ and 2) font size presets without individual min and max sizes, will use the single value as the mid-point, much like we currently do with custom values. Should they also be converted to behave as the upper bound regardless of whether they are greater or smaller than 14px?
  2. Is there any need to revisit or expand the 14px-as-a-minimum rule for presets? The rule is: wherever a supplied min value (that is, a min value from a preset’s fluid.min or computed internally by the function) is < 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

@ramonjd ramonjd added [Type] Enhancement A suggestion for improvement. [Feature] Typography Font and typography-related issues and PRs labels Nov 3, 2022
@andrewserong
Copy link
Contributor

Thanks for writing all this up!

Should they also be converted to behave as the upper bound regardless of whether they are greater or smaller than 14px?

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 min or max to their presets in theme.json if they need to?

How should we set the minimum value where a maximum custom value is < 14px?

If picking a font-size sets the upper bound, perhaps when a user selects font-sizes lower than 14px, it disables outputting the clamp() rule?

@ramonjd
Copy link
Member Author

ramonjd commented Nov 3, 2022

If picking a font-size sets the upper bound, perhaps when a user selects font-sizes lower than 14px, it disables outputting the clamp() rule?

Thanks @andrewserong !

This featured in one of the prior commits in #44993. I was quite fond of it at the time 😄

@jasmussen
Copy link
Contributor

Currently, 1) font values under “styles’ and 2) font size presets without individual min and max sizes, will use the single value as the mid-point, much like we currently do with custom values. Should they also be converted to behave as the upper bound regardless of whether they are greater or smaller than 14px?

Is there any need to revisit or expand the #44993 (comment) for presets? The rule is: wherever a supplied min value (that is, a min value from a preset’s fluid.min or computed internally by the function) is < 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?

I might not be parsing this right, but I would say, if fluid: true:

  • If a font size preset is set to 16px, it clamps between 14 and 16
  • If a font size preset is set to 14, it's 14, not fluid
  • If a font size preset is set to 12, it's 12, not fluid

What do you think?

@ndiego
Copy link
Member

ndiego commented Nov 3, 2022

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.

If picking a font-size sets the upper bound, perhaps when a user selects font-sizes lower than 14px, it disables outputting the clamp() rule?

This seems like a solid approach.

@ramonjd
Copy link
Member Author

ramonjd commented Nov 3, 2022

If picking a font-size sets the upper bound, perhaps when a user selects font-sizes lower than 14px, it disables outputting the clamp() rule?

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.

@ramonjd
Copy link
Member Author

ramonjd commented Nov 4, 2022

Therefore, I have added it to the 6.1.1 board

@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!

@ramonjd
Copy link
Member Author

ramonjd commented Nov 4, 2022

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 14px

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",
	        },
	},
...
  • If "size" is smaller than "fluid.min", don't do anything. We assume proper usage.

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",
	        },
	},
...
  • If we use "size" for the min, what if "size" is larger than fluid.max? Do we care?

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:

@ramonjd
Copy link
Member Author

ramonjd commented Nov 4, 2022

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.

@annezazu
Copy link
Contributor

annezazu commented Nov 7, 2022

@WordPress/block-themers if possible, it would be amazing if you could help test this with all that's going on 👆🏼

@carolinan
Copy link
Contributor

carolinan commented Nov 9, 2022

I think this makes sense and would be an improvement.
How is the user informed when their custom size is fluid and not exact?
Because I think any size that doesn't mach the actually entered size can be confusing, not only larger sizes.

@ramonjd
Copy link
Member Author

ramonjd commented Nov 9, 2022

How is the user informed when their custom size is fluid and not exact?

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

Because I think any size that doesn't mach the actually entered size can be confusing, not only larger sizes.

In theory, the change proposed by this issue will mitigate this, but maybe we could add something to the font size picker header hint.

Screen Shot 2022-11-10 at 3 50 38 am

@justintadlock
Copy link
Contributor

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 theme.json and the interface. I have also tested against both px and rem units.

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.

@carolinan
Copy link
Contributor

Would "responsive" be a word users are more familiar with?

@huubl
Copy link
Contributor

huubl commented Nov 10, 2022

Would "responsive" be a word users are more familiar with?

I think 'responsive' and 'fluid' are slightly different when reading:
https://learn.onemonth.com/responsive-vs-adaptive-vs-fluid-design/

Or this post: https://ux.stackexchange.com/a/24408

The main difference is that Fluid Layouts (also called Liquid Layouts) are based on proportionally laying out your website so elements take up the same percent of space on different screen sizes, while Responsive Design uses CSS Media Queries to present different layouts based on screen sizes/type of screen.

@carolinan
Copy link
Contributor

Users as in not developers and designers.

@ramonjd
Copy link
Member Author

ramonjd commented Nov 10, 2022

PHP backport to Core (assuming no further changes to #45536):

@priethor priethor removed the [Status] In Progress Tracking issues with work in progress label Nov 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Typography Font and typography-related issues and PRs [Type] Enhancement A suggestion for improvement.
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

9 participants