Fluid Typography Option

[iamtakashi]

It'd be nice to allow to have fluid typography option so that design would look good on all viewports. This would open the door for designers to make a more bold visual expression that's difficult to do with fixed font size.

@mtias told me about clamp https://developer.mozilla.org/en-US/docs/Web/CSS/clamp, and that looks a pretty good solution.

Related #23323

[mtias]

This would be neat to consider — also cc @nosolosw @jorgefilipecosta for global styles and theme.json consideration.

[jorgefilipecosta]

Following the suggestion, I gave in #24250 (comment).

I think the attributes where we reference a fontSize, lineHeights, padding, margins, widths, etc... should all be strings (instead of multiple attributes one for values and other for units as we have now in some cases).
Then in some cases, we can parse the value e.g:"13px" and display a UI control for changing that value. In other cases, we may not be able to parse the value, e.g.: "clamp(1rem, 10vw, 2rem);" for this case, we would show a text input where the user can use a raw mechanism to change the value.
When we think some type of value should have an easier to edit interface, we implement a parser for the value and a UI to manage it. For example, we may then add a mechanism that allows setting and editing clamp values in a specific UI component for "clamp".

If tomorrow CSS allows a new font size computation e.g: "font-size: next-size-computation( 10px, 10rm, ...). Themes would be able to use that mechanism right away without us needing to change any line of code (the value would be shown as a raw value). In a future version, we may then include a UI to edit that type of value if we think it has a big usage of is useful for building themes and patterns.

[aristath]

I think the attributes where we reference a fontSize, lineHeights, padding, margins, widths, etc... should all be strings (instead of multiple attributes one for values and other for units as we have now in some cases).

+1 to that... I started working on a similar approach for column widths (see #24711 (comment))
The context is different, but the implementation is pretty much the same: switched a control to string, allowing users to enter a value of their choosing with validation for the units they enter.
Personally on my themes & sites I like doing something like font-size:calc(14px + 0.25vw) to define the root font-size, and everything else is then in em units.
That calc() however would require a freeform text field in global styles, can't be done without it.

[jasmussen]

There's some conversation on fluid typography in #34641 as well, and this codepen showcases a CSS only solution that could potentially inspire things here.

[bph]

@priethor @jasmussen This was removed from 5.9 project board. Do you think it could make it into 6.0?

[mtias]

It might! #33543 and #39529

[ramonjd]

As mentioned above, I've started looking at a backend option for fluid typography based on existing fontSizes presets in theme.json.

• Block supports: add fluid typography #39529

When fluid typography is "activated" in theme.json, we generate font-size values using clamp().

The resulting font sizes can be applied to any text block in the editor UI, and the preset CSS vars to any root element or block in theme.json.

It's still work in progress as I look at various approaches, and consider the constraints on such functionality for an initial version, taking into consideration future development and (future) backwards compatibility should we change clamp algorithms.

I'll add this note to the tracking issue as well. 👍

[ramonjd]

Hi folks! It'd be great to get some feedback on #39529

It's trying to be everything to all, so there's probably some room for self restraint 😄

[madhusudhand]

Is there a discussion or issue to extend the fluid support to fontSize under any block ?

core/heading -> typography -> fontSize,
core/post-title -> typography -> fontSize etc..

In many themes, the blocks/elements such as headers, post-title also needs fluid typography and defining all those sizes under settings -> typography -> fontSizes is unnecessary.
Also by defining everything under settings has a side effect of seeing the huge list in the editor UI.

[ramonjd]

Is there a discussion or issue to extend the fluid support to fontSize under any block ?

None that I'm aware of. It seems like a reasonable progression. For now, would be it be acceptable to define them in theme.json?

	"settings": {
		"typography": {
			"fluid": true,
			"fontSizes": [
				{
					"size": "1rem",
					"slug": "medium",
					"name": "Medium"
				}
			]
		}
	},
	"styles": {
		"elements": {
			"h1": {
				"typography": {
					"fontSize": "var(--wp--preset--font-size--medium)"
				}
			}
		},
		"blocks": {
			"core/post-title": {
				"typography": {
					"fontSize": "var(--wp--preset--font-size--medium)"
				}
			}
		}
	}

[ramonjd]

Basic fluid font sizing added in #39529

Closing for now.

Feel free to re-open, though I think we could create a new issue for fluid letter spacing and any other fluid typography features that folks think would enhance the functionality.

[madhusudhand]

@ramonjd

For now, would be it be acceptable to define them in theme.json?

Defining all fluid fonts in theme.json settings and using them in blocks definitely works.
My only concern is, if a theme needs many such settings, fonts size dropdown would be overloaded, even though the variable used only once or twice.

In the view of better developer experience, I think it would be worth considering to extend the fluid typography to block level.

[ramonjd]

In the view of better developer experience, I think it would be worth considering to extend the fluid typography to block level.

I see you've filed an enhancement issue. Thank you @madhusudhand !! 🙇