Block supports: add fluid typography

[ramonjd]

Resolves #24480

What?

This is an experimental PR that implements fluid typography via opinionated calc/clamp formulae.

It adds new properties to theme.json settings and filters the settings.typography.fontSizes presets in theme.json.

Skip to testing instructions

Motivation

"Fluid typography" describes how a site's font sizes adapt to every change in screen size, for example, growing larger as the viewport width increases, or smaller as it decreases.

Font sizes can smoothly scale between minimum and maximum viewport widths.

2022-07-15.09.32.52.mp4

Contrast that idea with font sizes that respond to specific viewport sizes, such as those defined by media queries, but do nothing in between those sizes.

Theme.json already allows authors to insert their own fluid font size values. This won't change, but this PR offers it to folks who don't want to worry about the implementation details.

Alternatives

This PR is an alternative to #33543

Design

The gist is that, by opting into fluid typography, theme.json authors can generate --wp--preset--font-size--* CSS vars that they can use throughout the theme.json styles.

To opt into fluid typography typography.fluid should be true:

For example:

"styles": {
    ....
    "typography": {
        "fluid": true,
        "fontSizes": [
            {
                "size": "2rem",
                "fluid": {
                    "min": "2rem",
                    "max": "2.5rem"
                },
                "slug": "medium",
                "name": "Medium"
            },
        }
}

/* With no fluid typography */
--wp--preset--font-size--medium: 1.75rem;

/* With fluid typography */
--wp--preset--font-size--medium: clamp(1.3125rem, 1.3125rem + ((1vw - 1rem) * -2.524), 2.625rem);

For now I'm working with px, em and rem units for widths and font sizes to make things 'relatively' easier 😄

❗ Furthermore, it's important to support (and ultimately recommend) the use of relative sizes such as rem to encourage accessibility. The reason being is that we're setting the font size to scale proportionally with whichever base size the browser sets.

Fluid font sizes are constrained by static min and max viewport width sizes 1600px and 768px.

Later we'll add configurable viewport width sizes.

Min and max font size values are first taken from typography.fontSizes. Where either max or min or both are not found, we'll create some dynamically using min and max font sizes factors. Later we'll add configurable factors.

What about custom font-sizes set by the user in the editor?

The current assumption is that when a user sets a font-size, it'll overwrite any theme preset anyway. Plus, that leads us down the path of how and where to generate the styles in the JS.

Drawbacks

• We're introducing new theme.json  properties, which might be hard to rollback/change if we find they're hard to use or understand
• We've used fairly opinionated formulae. We have to be aware of usage across themes and potential backwards compatibility should things ever when things change.
• This PR does not explore editor UI. For example a means to toggle fluid font sizes on or off globally.

Testing Instructions

Empty theme is a good one to test with. Here are some test HTML + theme.json settings.

sample editor code

<!-- wp:paragraph {"fontSize":"colossal"} -->
<p class="has-colossal-font-size">Heading 1 - Colossal</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"fontSize":"gigantic"} -->
<p class="has-gigantic-font-size">Heading 2 - Gigantic</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"fontSize":"huge"} -->
<p class="has-huge-font-size">Heading 3 - Huge</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"fontSize":"x-large"} -->
<p class="has-x-large-font-size">Heading 4 - Extra large</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"fontSize":"large"} -->
<p class="has-large-font-size">Heading 5 - Large</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"fontSize":"medium"} -->
<p class="has-medium-font-size">Heading 6 - Medium</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text Paragraph text </p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><li>List text - small</li><li>List text - small</li><li>List text - small</li><li>List text - small</li><li>List text - small</li></ul>
<!-- /wp:list -->

<!-- wp:cover {"customOverlayColor":"#ff7b00","isDark":false} -->
<div class="wp-block-cover is-light"><span aria-hidden="true" class="wp-block-cover__background has-background-dim-100 has-background-dim" style="background-color:#ff7b00"></span><div class="wp-block-cover__inner-container"><!-- wp:paragraph {"align":"center","placeholder":"Write title…","fontSize":"colossal"} -->
<p class="has-text-align-center has-colossal-font-size">Cover block - Colossal</p>
<!-- /wp:paragraph --></div></div>
<!-- /wp:cover -->

Sample theme.json

{
	"version": 2,
	"settings": {
		"appearanceTools": true,
		"layout": {
			"contentSize": "840px",
			"wideSize": "1100px"
		},
		"typography": {
			"fluid": true,
			"fontSizes": [
				{
					"size": ".9rem",
					"fluid": {
						"min": "0.9rem",
						"max": "1.1"
					},
					"slug": "small",
					"name": "Small"
				},
				{
					"size": "1rem",
					"fluid": {
						"min": "1rem",
						"max": "1.3rem"
					},
					"slug": "medium",
					"name": "Medium"
				},
				{
					"size": "1.75rem",
					"slug": "large",
					"name": "Large"
				},
				{
					"size": "2.25rem",
					"slug": "x-large",
					"name": "Extra large"
				},
				{
					"size": "3.5rem",
					"slug": "huge",
					"name": "Huge"
				},
				{
					"size": "4.25rem",
					"slug": "gigantic",
					"name": "Gigantic"
				},
				{
					"size": "5.75rem",
					"slug": "colossal",
					"name": "Colossal"
				}
			]
		}
	}
}

☑️ Then give a few elements this style either in theme.json or via the editor using the Typography font size control.

☑️ Check out the frontend.

☑️ Change the font size in your browser, and make sure the font sizes that use rem or em scale proportionately.

☑️ Run the unit tests

npm run test-unit-php /var/www/html/wp-content/plugins/gutenberg/phpunit/block-supports/typography-test.php

Adoption Strategy

Initially we'd release this to theme authors via the theme.json interface only.

The intention is to garner feedback on the formulae and API, before we think about any editor UI and, beyond that, introducing fluidity to other properties such as spacing.

Since #34334 classic theme stylesheets contain core presets. I'm not yet sure of the implications, but it's something to keep in mind.

Later editions

Based on feedback we might like to enable configurable settings such as fluid scale rate and viewport size boundaries, e.g.,

	$default_maximum_viewport_width   = '1600px';
	$default_minimum_viewport_width   = '768px';
	$default_minimum_font_size_factor = 0.75;
	$default_maximum_font_size_factor = 1.5;
	$default_scale_factor             = 1;

How do we teach this

A reference alone under Presets would be inadequate.

I think we'd need an explanation and demonstration of the options as well.

Related issues/PRs

• Typography Tools: Tracking #34345
• Fluid Typography Option #24480

[aristath]

Just curious...
Why did we choose to go with a clamp() solution for fluid typography? 🤔 I realise it's a method that was popularised mostly by some css-tricks articles, but in many cases we don't want to clamp it for a maximum font-size...
This is also a valid scenario which works pretty well:

:root { /* Just an example */
  --root-size: 14;
  --fluid-ratio: 0.8;
  font-size: calc(var(--root-size) * 1px + var(--fluid-ratio) * 1vw);
}

In this scenario there is no upper limit, because if the user is on an 80-inch 16K screen, we may not want to limit the font-size to something like 30px... In their case that would be too small. The --root-size would be the minimum for a 0px viewport, on 320px the font-size would be ~16.5px, at 1280px the font-size would be 24px and so on. The --fluid-ratio would define the "curve", of the typography size depending on the device used in this example.

I don't have anything against using clamp(), but we should be aware that it's not the only option.
Having something for fluid typography is definitely better than having nothing, but we should be aware that there are other solutions too - all of them equally valid and good, each for different reasons, so IMO we should not force a single implementation.
At the very least, we could add a filter to allow changing the "clamp({$preset['size']}, $fluid_target_font_size, {$preset['maxSize']})"; to something custom so as not to exclude other implementations.

[jasmussen]

One of the trickiest challenges to solve is to add fluid typography with as little UI as possible, while at the same time accommodating both themes that go edge to edge in the viewport, and themes that have a max-width.

One approach I've explored to this leverages clamp and calc both to accomplish a max-width being built into the single formula that lets it stop scaling up when reaching the max-width value. I use this on my site at the moment, and it's working well:

The key bit here is that the font stops scaling upwards when the site max-width is reached. If it continued scaling to the viewport width, it would break the layout.

[aristath]

If it continued scaling to the viewport width, it would break the layout.

Yeah, it's a challenge.
In the theme where I'm using fluid typography (aristath/q) everything is defined in em units, and the fluid typography is on the root... so basically the whole site scales with the viewport, not just the typography - and there were no layout breakages because of that. It's an old theme, but the concept works 😉

[jasmussen]

It's an old theme, but the concept works 😉

Definitely, but it breaks apart still if you add a max-width for the main column that isn't em-based, right?

[aristath]

it breaks apart still if you add a max-width for the main column that isn't em-based, right?

I had even those defined in relation to the root font-size... (see theme.json). TBH I haven't checked if it still works 'cause it was using an older format for the theme.json file and I haven't updated it in a while. Maybe it does break now, but I don't think it should 🤔

[ramonjd]

Thanks for the ideas and for kicking off the discussion @aristath and @jasmussen 💟

I admit, I hadn't read very widely on this topic before starting this work, so your input is valuable.

⚠️ Please excuse the verbosity of this comment. I had taken notes and think that here is better home for them than a random text file on my desktop that I'll in all probability accidentally delete. I'll try to format it so it's at least skimmable.

I hope it elucidates some of the reasoning that got me this far. I'm not wedded to any particular point.

---

Why did we choose to go with a clamp() solution for fluid typography? 🤔

This is an experiment and therefore doesn't attempt to dictate a direction. The variables I was considering were:

• providing a way for theme authors to activate fluid typography without worrying about the implementation details.
• introducing as few new theme.json properties as possible and making those properties easy to understand.
• discovering whether we could open up fluid typography for existing blocks themes, assuming no theme.json changes at all.
• how to apply fluid typography to specific typographical entities such as elements or blocks (basically how theme.json allows us to apply CSS vars)
• allowing flexibility in terms of font size units (px/rem and to an extent em | %)
• balancing such flexibility with future usage and potential backwards compatibility should we ever change/update the algorithm (the hardest, and something I'm still mulling over)

The reason I chose to experiment with clamp() in this PR (at least in the current version) were:

• to experiment with clamp() as an approach 😄
• as @jasmussen alludes to, to offer the opportunity for theme authors to say, "I want the font size for X to be no smaller than x and no bigger than y given a viewport width range"
• since I was exploiting the fontSizes array items, to make the current font size values mean something regardless of whether fluid typography is activated or not.

To expand on the last point, currently size is the preferred font size. I assume the intention when declaring a value is that "I want fonts using this rule to always have a font-size of x, the viewport width notwithstanding".

If fluid typography is enabled however, size becomes the preferred minimum, thus preserving some of the default intention. That is, "I want fonts using this rule to never have a font-size smaller than x". It's my preferred base.

I tried a couple of clamp approaches already (1, 2).

The current version has the advantage of working (mostly) well with varying units, allows specific font sizes to opt-out of fluidness, and doesn't introduce any esoteric theme.json properties, though the last point is debatable.

---

The --root-size would be the minimum for a 0px viewport, on 320px the font-size would be ~16.5px, at 1280px the font-size would be 24px and so on. The --fluid-ratio would define the "curve", of the typography size depending on the device used in this example

Thanks for this example, it's one I hadn't considered.

To be honest, I'm all for something simpler.

A real challenge has been to make it generic enough to tweak, but not specific enough so that, if we ever make changes to the algorithm it will break sites.

❓ Would you expect designers to want to have a fixed fluid ratio across all font variations?

---

I realise it’s a method that was popularised mostly by some css-tricks articles, but in many cases we don’t want to clamp it for a maximum font-size…

Are there any other cases aside from the one you mentioned we should be taking into account?

CSS clamp, at least in my recent reading, has become popular since CSS Tricks https://css-tricks.com/simplified-fluid-typography/ wrote about it in 2019 and there are consequently quite of lot implementations, for example https://fluid-typography.netlify.app/, https://fluidtypography.com/ and https://www.fluid-type-scale.com/.

Each come with their own constraints and assumptions, e.g., some assume rem as the unit for all inputs.

Given the complexity of some of the formulas, I'm still skeptical about whether we should commit to one over the other.

Testing over various themes and layouts will hopefully yield the answer!

---

I don't have anything against using clamp(), but we should be aware that it's not the only option.
Having something for fluid typography is definitely better than having nothing, but we should be aware that there are other solutions too - all of them equally valid and good, each for different reasons, so IMO we should not force a single implementation.

If we offer fluid typography as an activation option, with Gutenberg taking care of the implementation, there's nothing preventing theme authors from keeping it disabled and defining whichever fluid typography values they desire in theme.json.

I'm not defending clamp() as the perfect or even correct approach - at this stage we are right to question how Gutenberg implements fluid typography now and later.

I'm open to ideas and advice about how we can offer a scalable and easy-to-use responsive typography to theme authors, especially since, whatever we decide now, may affect any future editor implementations such as #33543.

Before I even started this PR, and with nary a foggy clue about how to implement it, I had envisaged a scalable path to maturity, whereby we initially exposed a single theme.json property that theme authors could toggle e.g., typography.fluid = true. All variables being derived to some extent, for example the min could be size * 0.75, or the fluid factor/ratio could be (100vw - n).

After some testing I dismissed this idea mainly due to the fact that it created too many system constraints: I had to tweak my font sizes to accommodate a hidden formula, and as soon as the system changed, whether via disabling fluid type or changing the algorithm, they became invalid.

That's still true of clamp() to some extent: if we change the fluid formula we'd break designs.

---

At the very least, we could add a filter to allow changing the "clamp({$preset['size']}, $fluid_target_font_size, {$preset['maxSize']})"; to something custom so as not to exclude other implementations.

I like this idea.

Having a way to bypass the built-in fluid formula is a great suggestion, and one I think might mitigate my concerns about system constraints above.

❓ What would be a neat way to represent this option?

{
    "size": "3.125rem",
    "maxSize": "5rem",
    "fluidSize": "3.464vw + 2.229rem",
    "slug": "walloping",
    "name": "Walloping"
},

[aristath]

Thank you @ramonjd for expanding on your thinking! Posts like these are definitely helpful and will help us find an optimal solution to these issues ❤️

❓ What would be a neat way to represent this option?

{
    "size": "3.125rem",
    "maxSize": "5rem",
    "fluidSize": "3.464vw + 2.229rem",
    "slug": "walloping",
    "name": "Walloping"
},

I think adding a formula item (or something similar) to that array might work... The default can be clamp(var(--the-small-size), var(--the-large-size)), and users can tweak it when they wish to implement something different.
That would allow maximum versatility I think, and we won't need PHP filters etc like I suggested in my previous comment. It should also simplify the implementation a bit in the gutenberg_get_typography_font_size_value function 🤔

[jasmussen]

Regardless of the implementation (and absolutely, the simpler that works, the better!) it seems a useful constraint to consider is to start with the least user interface we can. As we develop and explore, it will become clearer what has to be surfaced, whereas it's always harder to move in the other direction.

[apeatling]

start with the least user interface we can

+100

[ramonjd]

it seems a useful constraint to consider is to start with the least user interface we can.

I concur!

I was running with the premise that, at first, there would be no user-facing controls at all, with fluid typography being enabled via theme.json properties.

The rationale would be that we could test our API choices first, then let any lessons guide how we express fluid typography in the UI.

This is particularly important because we'd have to create a JS implementation for the editor, so my hope is that it'd create less work.

It might be an on/off representation of the existing theme.json "toggle":

It's also one of the reasons why I thought targeting settings.typography.fontSizes was our best bet, since, if a theme enables fluid typography, it's available in the editor immediately via the font size list.

I think adding a formula item (or something similar) to that array might work... The default can be clamp(var(--the-small-size), var(--the-large-size)), and users can tweak it when they wish to implement something different.
That would allow maximum versatility I think, and we won't need PHP filters etc like I suggested in my previous comment. It should also simplify the implementation a bit in the gutenberg_get_typography_font_size_value function

Good one. I'll definitely play around with that. 🍺

There's nothing preventing theme authors from entering any type of fluid font size values for any element or block right now.

The advantage I see of extending the typography theme.json API is that we would allow themes to define font-size values for when fluid typography is enabled or disabled (eventually) in the UI.

So even something like this would work:

{
    "size": "3.125rem",
    "fluidSize": "clamp(3.125rem,  calc(7 / 80 * 100vw),  7rem )",
    "slug": "walloping",
    "name": "Walloping"
},

When fluid font sizes is enabled we'd use fluidSize to output the CSS var values, otherwise the value of size.

Or we could look at a more deterministic model [ $min, $fluid_formula, $max ] or { "minSize" : "", "fluidFormula: "", maxSize:"" }

{
    "size": "3.125rem",
    "fluidSizes": [ "3.125rem",  "calc(7 / 80 * 100vw)",  "7rem" ],
    "slug": "walloping",
    "name": "Walloping"
},

Such an approach would offer full control over clamp() values and would leave open the possibility of performing calculations based on provided viewport width ranges.

// $minSize
// $maxSize 
// $fluidFormula 

// $fluidFormula could be something like calc(var(--root-size) * 1px + var(--fluid-ratio) * 1vw)
if ( $fluidFormula && $! maxSize && ! $minSize ) {
    return "$fluidFormula;"
}

if ( $minSize && $fluidFormula && $maxSize  )  {
    return "clamp($minSize, $fluidFormula, $maxSize)";
}

// Next iteration...
if ( $minViewportWidth && $maxViewportWidth ) {
    // Return a clamp with a formula that constrains fluid between min and max.
}

// We could even play around with returning `min()` and `max()` depending on the combination of available parameters
// 🤷 YOLO
if ( $maxViewportWidth && $maxSize && ! $minSize && ! $minViewportWidth ) {
      return "min(maxViewportWidth, maxSize);"
}

[ramonjd]

Just dropping a link to some related discussion: #34641 (comment)

[apeatling]

@ramonjd What's the next steps on this one?

[ramonjd]

What's the next steps on this one?

I think the direction needs some input in general.

Given that it's an extension, albeit an experimental one, of the theme.json there might be more canonical way of introducing this feature.

At this stage we've swung the pendulum both ways: I've catered for maximum flexibility (ability to input any fluid formula) and an internal implementation based on clamp.

The latter allows theme authors to input mix and max values and have Gutenberg take care of the implementation.

It serves all tastes, but maybe it goes too far in one direction?

[apeatling]

Is it worth taking this out of draft to get more exposure and feedback? Also get some theme folks involved, I've pinged a few.