Tag: typography

Adding Fluid Typography Support to WordPress Block Themes

Fluid typography is a fancy way of “describing font properties, such as size or line height, that scale fluidly according to the size of the viewport”. It’s also known by other names, like responsive typography, flexible type, fluid type, viewport sized typography, fluid typography, and even responsive display text.

Here is an example of fluid typography that you can play live (courtesy of MDN documentation). CSS-Tricks has covered fluid typography extensively as well. But the point here is not to introduce you to fluid typography, but how to use it. More specifically, I want to show you how to implement fluid typography in WordPress 6.1 which recently introduced a fluid type feature directly in the WordPress Block Editor.

Open up your style.css file, slap in a style rule with fancy clamp()-ing on the font-size property, and good to go, right? Sure, that’ll give you fluid text, but to get Block Editor controls that make it possible to apply fluid type anywhere on your WordPress site? That requires a different approach in these block-ified days.

Fluid typography support in Gutenberg

Some WordPress theme developers have been using the clamp() function to define a fluid font-size, in their WordPress themes, even in newer “block” themes such as Twenty Twenty-Two, Twenty Twenty-Three, and others.

But the Gutenberg plugin — the one that contains experimental development for WordPress Block and Site Editor features — introduced support for fluid typography starting in version 13.8. That opened the door for implementing at a theme level so that fluid type can be applied to specific elements and blocks directly in the Block Editor. CSS-Tricks was even given a shout-out in the Pull Request that merged the feature.

That work became part of WordPress Core in WordPress 6.1. Rich Tabor, one of the earlier advocates of fluid typography in the Block Editor says:

[Fluid typography] is also a part of making WordPress more powerful, while not more complicated (which we all know is quite the challenge). […] Fluid typography just works. Actually, I think it works great.

This Make WordPress post highlights the approach taken to support the feature at the block level so that a fluid font size is applied to blocks dynamically by default. There are some benefits to this, of course:

  • It provides a way for theme authors to activate fluid typography without worrying about implementing it in code.
  • It applies fluid typography to specific typographical entities, such as elements or blocks in a maintainable and reusable way.
  • It allows flexibility in terms of font size units (e.g. px, rem, em, and %).

Now that this new feature is available in the WordPress Block Editor by default, theme authors can apply uniform fluid typography without writing additional code.

Blocks that support typography and spacing settings

Gutenberg 14.1 released on September 16, 2022, and introduced typographic settings on a bunch of blocks. That means the text settings for those blocks were set in CSS before and had to be changed in CSS as well. But those blocks now provide font and spacing controls in the Block Editor interface.

Illustrated list of WordPress blocks that received font and spacing controls in the Gutenberg plugin. There are 31 total blocks.

That work is currently slated to be added to WordPress 6.1, as detailed in this Make WordPress blog post. And with it is an expanded number of blocks that with typography support.

Illustrated list of 60 WordPress blocks gaining typography and font size support in WordPress 6.1.
WordPress blocks that will support typography settings in the upcoming WordPress 6.1 release.

Declaring fluid type in a WordPress block theme

So, how do we put this new fluid typography to use in WordPress? The answer is in theme.json, a new-ish file specific to block themes that contains a bunch of theme configurations in key:value pairs.

Let’s look at a rule for a large font in theme.json where contentSize: 768px and we’re working with a widesize: 1600px layout. This is how we can specify a CSS font-size using the clamp() function:

"settings": {   "appearanceTools": true,   "layout": {     "contentSize": "768px",     "wideSize": "1600px"   },   "typography": {     "fontSizes": [        {         "name": "Large",         "size": "clamp(2.25rem, 6vw, 3rem)",         "slug": "large"       }     ]   } }

As of WordPress 6.1, only rem, em and px units are supported.

That’s great and works, but with the new fluid type feature we would actually use a different approach. First, we opt into fluid typography on settings.typography, which has a new fluid property:

"settings": {   "typography": {     "fluid": true   } }

Then we specify our settings.fontSizes like before, but with a new fluidSize property where we can set the min and max size values for our fluid type range.

"settings": {   "appearanceTools": true,   "layout": {     "contentSize": "768px",     "wideSize": "1600px"   },   "typography": {     "fontSizes": [        {         "size": "2.25rem",         "fluidSize": {           "min": "2.25rem",           "max": "3rem"         },         "slug": "large",         "name": "Large"       }     ]   } }

That’s really it. We just added fluid type to a font size called “Large” with a range that starts at 2.25rem and scales up to 3rem. Now, we can apply the “Large” font to any block with font settings.

How does this works under the hood? Rich Tabor offers a nice explanation, as does this Pull Request in GitHub. In short, WordPress converts the theme.json properties into the following CSS rule:

.has-large-font-size {   font-size: clamp(36px, calc(2.25rem + ((1vw - 7.68px) * 1.4423)), 48px); }

…which is applied to the element, say a Paragraph Block:

<p class="has-large-font-size">...</p>

Initially, I found it hard to understand and wrap around in my mind the concept of the CSS clamp() function without also learning about the min(), max(), and calc() functions. This calculator tool helped me quite a bit, especially for determining which values to use in my own theme projects.

For demonstration purposes, let’s use the calculator to define our font-size range so that the size is 36px at a 768px viewport width and 48px at a 1600px viewport width.

Entering values into the online calculator for fluid typography.

The calculator automatically generates the following CSS:

/* 36px @ 768px increasing to 48px @ 1600px */ font-size: clamp(36px, calc(2.25rem + ((1vw - 7.68px) * 1.4423)), 48px);

The calculator provide options to select input units as px, rem, and em. If we select rem unit, the calculator generates the following clamp() value:

/* 2.25rem @ 48rem increasing to 3rem @ 100rem */ font-size: clamp(2.25rem, calc(2.25rem + ((1vw - 0.48rem) * 1.4423)), 3rem);

So, those minimum and maximum values correspond to the the fluidSize.min and fluidSize.max values in theme.json. The min value is applied at viewports that are 768px wide and below. Then the font-size scales up as the viewport width grows. If the viewport is wider than 1600px, the max is applied and the font-size is capped there.

Examples

There are detailed testing instructions in the merged Pull Request that introduced the feature. There are even more testing instructions from Justin Tadlock’s pre-prelease post on Make WordPress.

Example 1: Setting a new fluid font setting

Let’s start with Justin’s set of instructions. I used in a modified version of the default Twenty Twenty-Three theme that is currently under development.

First, let’s make sure we’re running the Gutenberg plugin (13.8 and up) or WordPress 6.1, then opt into fluid type on the settings.typography.fluid property in the theme.json file:

{   "version": 2,   "settings": {     "appearanceTools": true,     "layout": {       "contentSize": "768px",       "wideSize": "1600px"     },     "typography": {       "fluid": true     }   } }

Now, let’s drop the settings.typography.fontSizes examples in there:

{   "version": 2,   "settings": {     "appearanceTools": true,     "layout": {       "contentSize": "768px",       "wideSize": "1600px"     },     "typography": {       "fluid": true       "fontSizes": [         {           "name": "Normal",           "size": "1.125rem",           "fluid": {             "min": "1rem",             "max": "1.5rem"           },           "slug": "normal"         }       ]     }   } }

If everything is working correctly, we can now head into the WordPress Block Editor and apply the “Normal” font setting to our block:

The WordPress Block Editor interface showing a paragraph block and the fluid typography settings for it.

Nice! And if we save and inspect that element on the front end, this is the markup:

Inspecting the WordPress Paragraph block in DevTools.

Very good. Now let’s make sure the CSS is actually there:

DevTools showing the font-size custom property for the WordPress Paragraph block's fluid typography.

Good, good. Let’s expose that CSS custom property to see if it’s really clampin’ things:

Revealing the custom property value in DevTools, showing a CSS clamp function.

Looks like everything is working just as we want it! Let’s look at another example…

Example 2: Excluding a font setting from fluid type

This time, let’s follow the instructions from the merged Pull Request with a nod to this example by Carolina Nymark that shows how we can disable fluid type on a specific font setting.

I used the empty theme as advised in the instructions and opened up the theme.json file for testing. First, we opt into fluid type exactly as we did before:

{   "version": 2,   "settings": {     "appearanceTools": true,     "layout": {       "contentSize": "768px",       "wideSize": "1000px"     },     "typography": {       "fluid": true     }   } }

This time, we’re working with smaller wideSize value of 1000px instead of 1600px. This should allow us to see fluid type working in an exact range.

OK, on to defining some custom font sizes under settings.typography.fontSizes:

{   "version": 2,   "settings": {     "typography": {       "fluid": true,       "fontSizes": [         {           "size": ".875rem",           "fluid": {             "min": "0.875rem",             "max": "1rem"         },           "slug": "small",           "name": "Small"         },         {           "size": "1rem",           "fluid": {             "min": "1rem",             "max": "1.5rem"           },           "slug": "normal",           "name": "Normal"         },         {           "size": "1.5rem",           "fluid": {             "min": "1.5rem",             "max": "2rem"           },           "slug": "large",           "name": "Large"         },         {           "size": "2.25rem",           "fluid": false,           "slug": "x-large",           "name": "Extra large"         }       ]     }   } }

Notice that we’ve applied the fluid type feature only on the “Normal”, “Medium”, and “Large” font settings. “Extra Large” is the odd one out where the fluid object is set to false.

the WordPress Block Editor interface with four Paragraph blocks, each at a different font size setting.

What WordPress does from here — via the Gutenberg style engine — is apply the properties we set into CSS clamp() functions for each font size setting that has opted into fluid type and a single size value for the Extra Large setting:

--wp--preset--font-size--small: clamp(0.875rem, 0.875rem + ((1vw - 0.48rem) * 0.24), 1rem); --wp--preset--font-size--medium: clamp(1rem, 1rem + ((1vw - 0.48rem) * 0.962), 1.5rem); --wp--preset--font-size--large: clamp(1.5rem, 1.5rem + ((1vw - 0.48rem) * 0.962), 2rem); --wp--preset--font-size--x-large: 2.25rem;

Let’s check the markup on the front end:

Inspecting the WordPress Paragraph blocks in DevTools.

Good start! Let’s confirm that the .has-x-large-font-size class is excluded from fluid type:

Showing the font-size custom property for the Extra Large font setting in DevTools.

If we expose the --wp--preset--font-size--x-large variable, we’ll see it’s set to 2.25rem.

Revealing the Extra Large font size custom property value, showing 2.25rem.

That’s exactly what we want!

Block themes that support fluid typography

Many WordPress themes already make use of the clamp() function for fluid type in both block and classic themes. A good example of fluid typography use is the recently released Twenty Twenty-Three default theme.

I’ve reviewed all the block themes from WordPress Block Theme directory, examining theme.json file of each theme and to see just how many block themes currently support fluid typography — not the new feature since it’s still in the Gutenberg plugin as of this writing — using the CSS clamp() function. Of the 146 themes I reviewed, the majority of them used a clamp() function to define spacing. A little more than half of them used clamp() to define font sizes. The Alara theme is the only one to use clamp() for defining the layout container sizes.

Understandably, only a few recently released themes contain the new fluid typography feature. But here are the ones I found that define it in theme.json:

And if you read my previous post here on CSS-Tricks, the TT2 Gopher Blocks theme I used for the demo has also been updated to support the fluid typography feature.

Selected reactions to the WordPress fluid typography features

Having fluid typography in WordPress at the settings level is super exciting! I thought I’d share some thoughts from folks in the WordPress developer community who have commented on it.

Matias Ventura, the lead architect of the Gutenberg project:

Rich Tabor:

As one of the bigger efforts towards making publishing beautifully rich pages in WordPress, fluid typography is a pretty big experience win for both the folks building with WordPress — and those consuming the content.

Automattic developer Ramon Dodd commented in the Pull Request:

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.

Nick Croft, author of GenesisWP:

Brian Garner, designer and principal developer advocate at WPEngine:

A few developers think some features should be an opt-in. Jason Crist of Automattic says:

I love the power of fluid typography, however I also don’t believe that it should just be enabled by default. It’s usage (and the details of it) are important design decisions that should be made carefully.

You can also find a bunch more comments in the official testing instructions for the feature.

Wrapping up

The fluid typography feature in WordPress is still in active development at the time of this writing. So, right now, theme authors should proceed to use it, but with caution and expect some possible changes before it is officially released. Justin cautions theme authors using this feature and suggests to keep eye on the following two GitHub issues:

There is also still lots of ongoing work on typography and other design-related WordPress tools. If you’re interested, watch this typography tracking GitHub ticket and design tools related GitHub issues.

Resources

I used the following articles when researching fluid type and how WordPress is implementing it as a feature.

Tutorials and opinions

CSS-Tricks


Adding Fluid Typography Support to WordPress Block Themes originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

CSS-Tricks

, , , , , ,

COLRv1 and CSS font-palette: Web Typography Gets Colorful

According to Toshi Omagari, the author of Arcade Game Typography, the world’s first multi-colored digital font was created in 1982 for a never-released video game called Insector. Multi-colored fonts, sometimes called chromatic type, are still relatively rare on the web, even though the COLR font format has had full cross-browser support since 2018 (even in Internet Explorer!).

The technology opens up an entirely new vein of typographic creativity. While some of the color fonts I’ve seen have been lurid, at best, chromatic fonts are fun, innovative and attention-grabbing. With both the addition of a new CSS features — including the font-palette property and @font-palette-values rule — for controlling the color palette of color fonts and the evolution of the COLR font format, it’s a great time to dive in and experiment with with what modern web typography can do.

Hello in a cursive rainbow color font.

COLR support

I last wrote about color fonts in 2018. At the time, there were four different standards for multicolored typefaces: OpenType-SVG, COLR, SBIX, and CBDT/CBLC. You can use ChromaCheck to see what color font formats your own browser supports.

Google Chrome has marked OpenType-SVG as “wontfix” meaning that format will never be supported by Chrome or Edge. SBIX and CBDT/CBLC can mostly be ignored for use on the web as they’re both based on raster images and become blurry at larger font sizes. The large file size of bitmap-based fonts also makes them a bad choice for the web.

Ulrike Rausch is the creator of LiebeHeide, a bitmap color font which uncannily replicates the look of a ballpoint pen. “My biggest goal was always to reproduce handwritten text as authentically as possible,” she told me. “For LiebeHeide, I was finally able to simulate these handmade attributes with a font. The downside? All the PNG images in the font file add up and result in an enormous OTF file size. This might not be a problem for desktop applications, like Adobe InDesign, but for use on the web the font is hardly applicable.”

All browsers support COLR fonts (now generally referred to as COLRv0). Version 98 of Chrome (and Edge), released in February, added support for COLRv1, an evolution of the format.

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

Chrome Firefox IE Edge Safari
71 32 9 12 11

Mobile / Tablet

Android Chrome Android Firefox Android iOS Safari
101 100 101 11.0-11.2

COLRv0 and COLRv1

Screenshot of font.
Plakato from Underware foundry

COLRv1 is part of the OpenType 1.9 standard. While the initial COLRv0 lacked many of the creative possibilities of OpenType-SVG, COLRv1 matches those possibilities while avoiding certain drawbacks. COLRv0, for example, could only do solid colors whereas COLRv1 can do linear, radial, and conic gradients. The format also adds compositing and blending and allows for shape reuse to save on file size.

Typography expert Roel Nieskins explains: “I used to say the OpenType-SVG format was the best format as it offered the most versatility — until I realized this is just too complex for a low-level job like text rendering. It implements a basic subset of SVG on the font rendering level. But it doesn’t work well with other font tech (hinting, variable axes, etc.), and it’s a pain to implement. So, I switched sides to COLR. COLR basically re-uses everything that OpenType fonts already have. It ‘only’ adds layering, and the possibility to change the color of each layer. Simple, but effective.”

COLRv1 is entirely compatible with variable font axes, and there are already examples of variable COLR fonts like Merit Badge, Plakato Color and Rocher Color.

Here’s a striking example from Ulrike Rausch of what’s possible with the format, a (currently unreleased) typeface which digitally recreates the look of a neon sign:

Screenshot of COLR font in bright pink against light and dark backgrounds.

Akiem Helmling of the type foundry Underware is enamored with COLRv1, telling me that “[t]he COLRv1 format can potentially have a similar (or even bigger) impact on type design than variable fonts had in recent years.” For Akiem, it’s undoubtedly the superior format. “All former color formats have been bad hacks to add colors to glyphs. While OpenType-SVG is regarded by some people as a good solution, it is, from my point of view, not at all. From a pragmatic point of view, SVG is a ‘locked room’ within the open structure of OpenType. There is no way to re-use or link data or to create a connection between other font tables and the SVG table. And because of this, we can not make a variable font with variable SVG data.”

It’s still early days for the format. Mozilla hasn’t yet shipped COLRv1 but has taken a positive position on the format, stating that it has “the potential to supersede OpenType-SVG fonts in web use.” Apple is reluctant to implement it in Safari.

COLRv1 fonts will still show up and be readable in these browsers but all the letter’s will be a single solid color (which you can set with the CSS color property, just like with a normal font). We’re yet to see many type foundries release COLRv1 typefaces, and some popular design tools like Figma don’t even support COLRv0, but I’m hopeful and believe it will be the future of color typography on the web. In the short time COLRv1 has been around there have already been some beautiful examples of what the technology can do, such as Reem Kufi and Bradley Initials.

COLR fonts in Figma

COLR fonts in Sketch.

COLR and CSS

If you’re using a color font, you probably want to be able to control its colors. Until now, that was impossible to do with CSS. The font-palette property brings the power to override the default color scheme of a typeface and apply your own. This property works on COLRv0 and COLRv1 typefaces. (Apple’s Myles Maxfield explains that SVG fonts can opt-in to using palettes, whereas all the colors of a COLR typeface are automatically overridden by CSS.)

Coming up with a decent color palette is a fine art. Some type designers have done the hard work for us and include alternative palettes inside the font. You can select from these different color schemes using base-palette in CSS.

How do you find out if a font offers an alternate palette? The site for the font might tell you. If not, there’s a handy tool called Wakamai Fondue that will list all the available color schemes (shown in the image below). For this example, I’ll use Rocher Color, a free variable color font from Henrique Beier with a Flintstones vibe. From looking at Wakamai Foundue we can see that this typeface uses four colors and comes with eleven different palette options.

Grid of hex color values.

Using base-palette: 0 will select the default color palette (in the case of Rocher, that’s shades of orange and a brown).

Rocher COLR font.

Using base-palette: 1 will select the first alternative palette defined by the creator of the typeface, and so on. In the following code example, I’m selecting a color palette that’s different shades of gray:

 @font-palette-values --Grays {   font-family: Rocher;   base-palette: 9; }

Once you’ve selected a palette with the CSS @font-palette-values rule, you can apply it using the font-palette property:

.grays {   font-family: 'Rocher';   font-palette: --Grays; }

Of course, you might want to create your own palette to match your brand colors or to meet your own design sensibility. If you’re going to override all the colors then you don’t need to specify the base-palette.

Let’s take Bungee from pioneering type designer David Jonathan Ross as an example. It only uses two colors by default, red and white. In the following example, I’m overriding both colors of the font, so the base-palette doesn’t matter and is omitted:

 @font-palette-values --PinkAndGray {   font-family: bungee;   override-colors:     0 #c1cbed,     1 #ff3a92; }  @font-palette-values --GrayAndPink {   font-family: bungee;   override-colors:     0 #ff3a92,     1 #c1cbed; }
The word color in pink and fonts in light gray against a pink-saturated photo background.

Alternatively, you can set the base-palette as a starting point and selectively change just some of the colors. Below I’m using the gray color palette of Rocher, but overriding one color with a minty green:

@font-palette-values --GraysRemix {   font-family: Rocher;   base-palette: 9;   override-colors:      2 rgb(90,290,210); }  body {   font-family: "Rocher";   font-palette: --GraysRemix; }

When specifying override-colors it’s difficult to know which bit of the font will be overridden by which number — you have to play around and experiment and achieve the desired effect through trial and error.

Rocher COLR font.

Should you wish, you can even change the color of emoji fonts, such as Twemoji (shown below) or Noto. Here’s a fun demo from a font engineer at Google.

Brown illustrated cartoon dog with green ears and tongue.

Current limitations

One regrettable limitation, at least for the time being is that CSS custom properties don’t work in @font-palette-values. That means the following is invalid:

@font-palette-values --PinkAndBlue {   font-family: bungee;   override-colors:     0 var(--pink),     1 var(--blue); }

Another limitation: animations and transitions from one font-palette to another don’t interpolate — meaning you can switch instantly from one palette to another, but can’t gradually animate between them. My dream of a luridly animated emoji font is sadly unrealized.

Browser support

font-palette and @font-palette-values have been supported in Safari since version 15.4, and landed in Chrome and Edge with the release of version 101.

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

Chrome Firefox IE Edge Safari
101 No No No 15.4

Mobile / Tablet

Android Chrome Android Firefox Android iOS Safari
101 No 101 15.4

Use cases

You can probably already imagine how you might use color fonts in your own projects. There are a couple of specific use cases, though, that are worth calling out.

COLR and icon fonts

Icon fonts may no longer be the most popular method for displaying icons on the web (Chris explains why) but they are still widely used. If you use an icon font with multiple colors, like Duotone from FontAwesome or the two-tone icons from Material Design, font-palette could offer an easier method for customization.

Grid of Duotone icons.

Solving the emoji problem

Nolan Lawson recently wrote about the problems of using emoji on the web. The Chrome developer blog explains one rather complex current solution:

If you support user generated content, your users probably use emojis. Today it’s very common to scan text and replace any emoji encountered with images to ensure consistent cross-platform rendering and the ability to support newer emojis than the OS supports. Those images then have to be switched back to text during clipboard operations.

If it receives greater browser support, COLRv1 emoji fonts will offer a far simpler approach. COLRv1 also comes with the benefit of looking crisp at any size, whereas native browser emojis get blurry and pixelated at larger font sizes.

Wrapping up

Before color fonts, typographic creativity on the web was limited to applying strokes or gradient fills with CSS. You could always do something more custom with a vector image, but that’s not real text — it can’t be selected by the user and copied to the clipboard, it can’t be searched on the page with Command+F, it isn’t read by screen readers or search engines, and you’d need to open Adobe Illustrator just to edit the copy.

Color fonts have the potential to really grab a user’s attention, making them perfect for landing pages and banners. They may not be something you reach for often, but they promise new expressive and creative possibilities for web design that can make your site stand out.


COLRv1 and CSS font-palette: Web Typography Gets Colorful originally published on CSS-Tricks. You should get the newsletter.

CSS-Tricks

, , , ,
[Top]

8 Interesting Typography Links for January 2022

Every now and then, I find that I’ve accumulated a bunch of links about various things I find interesting. Typography is one of those things! Here’s a list of typography links to other articles that I’ve been saving up and think are worth sharing.

A specimen of the Retail typeface, once of the typography links in the list.
An awesome new font from OH no Type Company

Do you have any interesting typography links from the past month worth sharing? Drop ’em in the comments!


8 Interesting Typography Links for January 2022 originally published on CSS-Tricks. You should get the newsletter and become a supporter.

CSS-Tricks

, , , ,
[Top]

Some Typography Links VIII


The post Some Typography Links VIII appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , ,
[Top]

Some Typography Links VII


The post Some Typography Links VII appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, ,
[Top]

Some Typography Links

  • Glitter text — whO (I learned a name for people who go by a one-word moniker like that: Mononymous) created a builder for fancy SVG-based type. It’s a custom font with <text>, and the fancy comes in with a gradient and somewhat exotic filters that make noise and blend the noise into the color.
  • Optical Size tweaking for dark mode — Mark Boulton opens by questioning the usefulness of variable fonts (blaspheme!) but then finds a nice use case in adjusting the optical size in dark mode. Robin covered that right here not too long ago.
  • Optical size, the hidden superpower of variable fonts — Speaking of optical size, Roel Nieskens digs into that here. It’s not just a weight thing… This feature will make letters actually change the way they look when shown in small or large sizes. It all happens automatically in the browser.”
  • Updates to v-fonts.com — Annnnd speaking of variable fonts, Piper Haywood talks about some updates to v-fonts.com, introducing some browsable taxonomies. It takes me about 20 seconds browing this site to want to redesign everything using variable fonts.
  • All you need is 5 fonts — (Matej Latin) I’ve been hearing about these mythical designers who focus all their creative energy on deep-learning how to use a very limited set of fonts. Maybe it’s kinda the same as us web nerds who only know HTML, CSS, and JavaScript and leave it at that.
  • Best practices for fontsJust like CSS, fonts affect Web Core Vitals in big ways (e.g. layout shifts and paints). Katie Hempenius is at it again here covering how to make fonts faster. I think these best practices are starting to set in a bit… preconnecting to the font host, subsetting, font-display, etc.
  • Sans Bullshit Sans — Kinda like the Cloud to Butt browser plugin, only the text replacements are done via ligatures (🤯) converting them into little Comic Sans badges. Some of them are angled? How the heck does that work?
  • Bryan Font — Jon Hicks builds a font for his father, John Bryan Hicks, who passed away. What a loving tribute.
  • Inherit ancestor font-size, for fun and profit — Lea Verou finds yet another use case for @property. I wonder if it’s an emerging best practice to register all your custom properties, since it unlocks possibilites and makes them behave more like you expect them to behave. Lea shows how you can browser test for @property in JavaScript, but if you for some reason you can’t do that and don’t mind pretty mind-bending CSS, Jane has pure CSS way.

The post Some Typography Links appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, ,
[Top]

Working around the viewport-based fluid typography bug in Safari

Sara digs into a bug I happened to have mentioned back in 2012 where fluid type didn’t resize when the browser window resized. Back then, it affected Chrome 20 and Safari 6, but the bug still persists today in Safari when a calc() involves viewport units.

Sara credits Martin Auswöger for a super weird and clever trick using -webkit-marquee-increment: 0vw; (here’s the documentation) to force Safari into the correct behavior. I’ll make a screencast just to document it:

I randomly happened to have Safari Technology Preview open, which at the moment is Safari 15, and I see the bug is fixed. So I wouldn’t rush out the door to implement this.

Direct Link to ArticlePermalink


The post Working around the viewport-based fluid typography bug in Safari appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , , ,
[Top]

Links on Typography

  • I studied the fonts of the top 1000 websites. Here’s what I learned. — Michael Li brings the data. San-serif has total dominance. “[…] it is rare to go below 10px or above 24px.” And poor <h5> always being the same size as <p>. Makes me feel extra sad for <h6>, are you destined to be smaller than body copy?
  • How tracking and kerning improves all caps text — Oliver Schöndorfer gets into why ALL CAPS text generally looks better when spaced out (i.e. letter-spacing in CSS). I’m not exactly a renowned typographer, but this tracks with what I’ve always felt. All-caps looks good spaced out (sometimes quite a bit), and conversely, it almost never looks good to track out lowercase. Like the PG version of the famous quote.
  • Leveraging System Fonts on the Web — Jim Nielsen shared some of my confusion with “system fonts” in CSS. Like we have system-ui now, which I use pretty often because it actually works in Chrome and Safari for selecting the system font (i.e. getting to use San Francisco on macOS). Before that was a thing, to leverage the same kind of thing, you’d do a big long stack. But we kinda still need the stack for real production sites, since system-ui isn’t universally supported. There is a nice world going forward though, because we’re getting ui-sans-serif, ui-sans-serif, ui-monospace, and ui-rounded. Browser support is quite limited, but it’s gonna be nice.
  • Simpler Font Licensing: Introducing V2 — “The core of V2 is this: you buy a font, and then you can use it.” God bless ’em. As the owner of several sites that get a lot of page views but don’t have waterfalls of cash as a budget, I need web font pricing that is sane.
  • 5 steps to faster web fonts — Iain Bean goes through the biggies: WOFF2, font-display, <link rel="preload" ...>, Subsetting, and self-hosting. And never forget about the holy bible.
  • A New Way To Reduce Font Loading Impact: CSS Font Descriptors — Barry Pollard looks at new CSS descriptors (not just regular properties as they only work within @font-face blocks) like size-adjust and ascent-override. YES. THIS IS AWESOME. I declared perfect font fallbacks one of the all-time great CSS tricks, but alas, it required a smidge of JavaScript and hackery. This brings it all into CSS perfectly.
  • Why You Should Stop Using Times New Roman — Vanessa Hill was asked to reformat a research paper into Times New Roman. She was told it’s because it’s so readable and researches the truth: it’s not. Personally, I can’t stand the look of it because it looks like your font-stack failed in CSS.
  • Pixel font converter! — Looks like an ancient tool (via Remy Sharp) but I love it as it opens up the idea of creating a font to anyone who knows how to draw some letters and save a static image.

The post Links on Typography appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

,
[Top]

Links on Typography

A few links that I’ve been holding onto:

  • How to pick a Typeface for User Interface and App Design?” by Oliver Schöndorfer. I like the term “functional text” for everything that isn’t display or body type. Look for clearly distinct letters, open shapes, and little contrast. This reminds me of how we have the charmap screen on the Coding Fonts site, but still need to re-shoot most of the screenshots so they all have it.
  • Uniwidth typefaces for interface design by Lisa Staudinger. “Uniwidth typefaces, on the other hand, are proportionally-spaced typefaces, but every character occupies the same space across different cuts or weights.” So you can change the font-weight but the box the type occupies doesn’t change. Nice for menus! This is a different concept, but it reminds me of the Operator typeface (as opposed to Operator Mono) which “is a natural width family, its characters differing in proportion according to their weight and underlying design.”
  • Should we standardize the naming of font weights?” by Pedro Mascarenhas. As in, the literal names as opposed to font-weight in CSS where we already have names and numeric values but are at the mercy of the font. The image of how dramatically different fonts, say Gilroy Heavy and Avenir Heavy, makes the point.
  • About Legibility and Readability” by Bruno Maag. “Functional accessibility” is another good term. We can create heuristics like specific font-sizes that make for good accessibility, but all nuance is lost there. Good typography involves making type readable and legible. Generally, anyway. I realize typography is a broad world and you might be designing a grungy skateboard that is intentionally neither readable nor legible. But if you do achieve readability and legibility, it has sorts of benefits, like aesthetics and me-taking-you-seriously, but even better: accessibility.
  • Font size is useless; let’s fix it” by Nikita Prokopov. “Useless” is maybe strong since it, ya know, controls the font size. But this graphic does make the point. I found myself making that same point recently. Across typefaces, an identical font-size can feel dramatically different.
  • “The sans selection” by Tejas Bhatt. A journey from a huge selection of fonts for a long-form journalism platform down to just a few, then finally lands on Söhne. I enjoyed all of the very practical considerations like (yet again) a tall x-height, not-too-heavy, and even price (although the final selection was among the most costly of the bunch).
  • Plymouth Press” by James Brocklehurst. You don’t see many “SVG fonts” these days, even though the idea (any SVG can be a character) is ridiculously cool. This one, being all grungy, has far too many vector points to be practical on the web, but that isn’t a big factor for local design software use.
  • “Beyond Calibri: Finding Microsoft’s next default font” (I guess nobody wanted that byline). I’m so turned off by the sample graphics they chose for the blog post that I can’t bring myself to care, even though this should be super interesting to follow because of the scale of use here. The tweet is slightly better.
  • Why you should Self-Host Google Fonts in 2021″ by Gijo Varghese. I am aware of “Cache Partitioning” (my site can’t use cached fonts from your site, even if they both come from Google) but I could have seen myself trotting out the other two arguments in a discussion about this and it’s interesting to see them debunked here.

The post Links on Typography appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

,
[Top]

Intrinsic Typography is the Future of Styling Text on the Web

The way we style text hasn’t changed much over the years. There have been numerous advancements to help make things more flexible, like layouts, but in terms of styling, most finite aspects of our designs, like text, remain relatively unchanged. This is especially true of text styling. We write code to style text explicitly for every portion of our layouts, and then, to make it responsive, we write more code to make it work at every breakpoint. This means that, as different areas of text compress and expand, the result is tension — palpable, experiential tension — just before the content breaks. At these places, content suffers from not being sized or spaced well, all the while being supported by overly complicated and brittle code.

Intrinsic typography shifts all this, clearing it away by starting at the code itself to affect the styling. Instead of writing explicit text styles, you define how those styles change in proportion to the text’s area. This enables you to use more flexible text components in more layout variations. It simplifies your code, increasing the opportunities for new layout possibilities. Intrinsic typography works so that text self-adjusts to the area in which it’s rendered. Instead of sizing and spacing text for each component at every breakpoint, the text is given instructions to respond to the areas it is placed in. As a result, intrinsic typography enables designs to be far more flexible, adapting to the area in which it is placed, with far less code.

Typographic superpowers beyond clamp()

The result of using intrinsic typography goes well beyond what is possible with tools like clamp(). Intrinsic typographic styling blends the component portability of element queries with the interpolation control of CSS animations, enabling seamless changes of any value across container widths. This technique enables things that aren’t possible with other CSS techniques, such as fluidly adjusting variable font settings, color, and unitless line-height as an element’s area changes. You also avoid the accessibility pitfalls of clamp() and locks where changing the browser’s default font size shifts your typography out of alignment with your breakpoints when using relative units.

How is this different from responsive typography?

Responsive typography references the viewport to transform text. It does this through media queries, clamp(), or CSS Locks. While these techniques enable granular control of typography across screen sizes, they lack the ability to control typography in different components. This means that, for a page with an array of differently sized content areas, a new headline style would need to be created for each of these areas with a responsive typography approach.

Intrinsic typography doesn’t need all that. With intrinsic typography, a single headline style can be used in all different content areas. Discrete headline styles can be consolidated into one intrinsic headline. This is a distinction similar to that of element queries versus media queries: with element queries it’s possible to bind all of the scaling information to a component, where media queries the styles always reference the viewport.

A series of entries scaling proportionally to the container they are rendered in. The font in this demo is Obviously by OHno Type Co.

The anatomy of an intrinsic style

If we were to take the intrinsic headline styles above and extrude out all the variations within them, it would look like the following:

An extrapolation of an intrinsic style along the Z-axis. As the width of an area of text changes, different cross sections of this extrapolation are used as the styles.

Within larger areas of the page, the text is typeset to be bigger, bolder, and wider. In smaller areas of the page the text is smaller, lighter, and narrower. The area in which a headline is rendered is measured, and then the appropriate slice is taken from this intrinsic headline style to be used for that specific headline.

You may notice a few things about the shape of this extruded headline style. The text goes from being smaller to larger, but the shape itself has curves. This control over how text scales from one point to another is particularly useful as screens get smaller to ensure optimal legibility. Below you can see the same set of styles being applied to two columns of text, one with a curved shape and one with a linear shape. In the curved intrinsic example the text is vastly more legible in more places, in comparison to the example using linear interpolation, where the text becomes too small too quickly.

Two panels of text that share the same start and end styles. However on the right, the styles are interpolated using a Bézier curve to optimize legibility at all sizes.

Through combining the ability to interpolate text styling across sizes and areas of a layout as well as shaping how those settings are interpolated, intrinsic typography gives designers an unprecedented amount of control over how text is rendered at any screen or component size.

Typeset intrinsically

Typetura developed a tool to add intrinsic typesetting functionality to CSS. This tool enables the necessary typographic styles to be written, injecting flexibility where previously there was none. Intrinsic styles are stored in CSS keyframes and change based on the width of a parent element. This enables interpolation of any animatable property across element widths. To reference back to our element queries example, think interpolated element queries.

To set up your keyframes, 0% is equal to a container with of 0px, and keyframe 100% is the maximum container width your styles will cover. This value is 1600px by default. Containers can be defined by adding the class typetura to an element, with the root element as the default container. Child elements will be styled based on the parent context’s width, unless a new context is defined.

@keyframes headline {   0% {     font-size: 1rem;   }   100% {     font-size: 4rem;   } }

To attach these styles to your element, use the custom property --tt-key. Now you can see your first intrinsic style.

@keyframes headline {   0% {     font-size: 1rem;     line-height: 1.1;   }   100% {     font-size: 4rem;     line-height: 1;   } }  .headline {   --tt-key: headline; }

To shape how these styles scale, use the custom property --tt-ease. This property accepts CSS easing functions and keywords. This enables you to rapidly bring up your base font size or taper off headline scaling and spacing. Additionally, we can constrain the range these styles cover with --tt-max to better fit the constraints of your layouts and what the text is used for.

@keyframes headline {   0% {     font-size: 1rem;     line-height: 1.1;   }   100% {     font-size: 4rem;     line-height: 1;   } }  .headline {   --tt-key: headline;   --tt-max: 600;   --tt-ease: ease-in-out; }

The following example shows how flexible your page can be when all the text on it is driven by intrinsic typographic styles; from the root of the document and up. The text can seamlessly transition from a monitor serving a conference room all the way down to the size of a watch — all without media queries. Text styles can also be shared in different modules; for example, the headline at the top of the page and headlines in the next-click area are all driven by the same style. While efficiencies appear immediately at any size of website, they quickly compound: the larger site you have, the more these efficiencies build.

Editorial page demo at a desktop screen size
Editorial page demo at a small tablet screen size
Editorial page demo at a small phone or watch screen size, and no text is getting cut off

Check out this Pen. In it, I’ve added an intrinsic style inspector so you can click on each headline and see what the rendered size is. Within the inspector you can also manipulate the shape of the intrinsic style, and the upper boundary. This allows you to begin to see the typographic styling possibilities for enabled by Typetura.

Intrinsic Typography is the future of styling on the web

Baking these design rules into your content is the practice of intrinsic design, and baking these rules into your text is the practice of intrinsic typography. Intrinsic web design, coined by Jen Simmons, is a concept where common design mutations are baked into the very fabric of our components. Instead of explicitly stating the style of each individual piece of content, intrinsic layouts are given design constraints and our content responds to its environment, as opposed to explicitly defining styles. This approach both simplifies your codebase and enhances the flexibility of your designs, as components have instructions that help them respond to more than just the viewport.

Typetura brings this philosophy into text styling. With text components being our most foundational design material, a material that is reused in almost every component, intrinsic typography has significant advantages over other methodologies. Advantages of design resilience, scalability, and simplification of code exist deeper in your project and extend its lifespan. Scale down to the size of a watch or up to the size of a TV, and where text once limited how far your layout could reach, it now supports your ambitions.


The post Intrinsic Typography is the Future of Styling Text on the Web appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , ,
[Top]