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

ramonjd commented 2 years ago

Parent issue:

44888

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

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

andrewserong commented 2 years ago

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 commented 2 years ago

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 https://github.com/WordPress/gutenberg/pull/44993. I was quite fond of it at the time 😄

jasmussen commented 2 years ago

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 https://github.com/WordPress/gutenberg/pull/44993#issuecomment-1281787028 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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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:

try to use "size" for min and leave it at that.
calculate min based on a factor of n e.g., size * 0.75 and apply 14px rule (because it's the algorithm that's creating one, not the user). This is the current behaviour in the PR https://github.com/WordPress/gutenberg/pull/45536

ramonjd commented 2 years ago

I've got something up to test in the meantime: https://github.com/WordPress/gutenberg/pull/45536

But probably won't get much time over the next week or so to work on it.

annezazu commented 2 years ago

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

carolinan commented 2 years ago

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 commented 2 years ago

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 https://github.com/WordPress/gutenberg/issues/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.

justintadlock commented 2 years ago

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 commented 2 years ago

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

huubl commented 2 years ago

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 commented 2 years ago

Users as in not developers and designers.

ramonjd commented 2 years ago

PHP backport to Core (assuming no further changes to https://github.com/WordPress/gutenberg/pull/45536):

https://github.com/WordPress/wordpress-develop/pull/3602

WordPress / gutenberg