Designing for Long-Form Articles

Daniel Schwarz — Wed, 10 Aug 2022 14:30:01 +0000

Designing a beautiful “article” is wrought with tons of considerations. Unlike, say, a homepage, a long-form article is less about designing an interface than it is designing text in a way that creates a relaxed and comfortable reading experience.

That’s because articles deal with long-form content which, in turn, tends to be valued by a ”time on page” interaction with users. We want someone to read a complete narrative. There’s a natural space between the time someone lands on an article and reads all the words. And hopefully, that space is immersive enough to not only hold a user’s, but provoke thoughts, ideas, and, possibly, actions. At least that’s what I’m hoping as I have your attention and you make your way through the very article you’re reading.

There’s a balance. On one hand, we hear that “no one reads the Internet.” On the other, a long-form article demands careful attention. Considering the current value of content marketing and the growing impatience in users, captivating readers for as long as possible should be a key concern. Let’s take a look at some best practices and examples of incredible article pages to get a better idea of what makes a visually appealing reading experience for long-form articles (without sacrificing user experience), and how we can replicate the effects.

Quick wins

Let me quickly list out what I think might already be obvious to many of you, but are effective things for content legibility:

Increase the font size: We know that 16px is the default and is perfectly fine in many designs, but a larger font size is inviting in that it implies the user is free to lean back and settle in without having to angle forward with the screen in their face to read.
Aim for characters per line: Very few people I know like to work harder than they need to, and that goes for reading too. Rather than using the full viewport width, try to narrow things down and balance that with your larger font size to get fewer characters on each line of text. Your sweet spot may vary, though many folks suggest somewhere between 45-75 characters per line to help limit how far the reader’s eye has to work to go from left to right. Chris has a bookmarklet to help count characters, but we also have the ch unit in CSS to get predictable results.
Bump up the line height: A default line height is going to feel smashed. It’s funny, but more space between lines (up to a point, of course) is less work for eyes, which seems antithetical to the characters-per-line advice where we generally want eyes to travel a shorter distance. A line height between 1.2 and 1.5 seems to be a pretty typical range for long-form content.

If you haven’t seen it before, Pierrick Calvez has a great “five-minute” guide to typography that packs in a bunch of low-hanging fruit like these.

Design for extra breathing room

You may be accustomed to designing “above the fold” where real estate is a prime commodity. That’s sort of like beach-front property in the web world because it’s where we’re used to packing in high-value things, like hero banners, calls to action, and anything else to help sell a thing. Above the fold can be a lot like a dense urban downtown with high traffic and high-rise buildings.

Articles are different. They allow you to stretch out a bit. If we want to take the city development analogy a little further, articles have the acreage to lean into a “less is more” sort of design approach. That’s what makes seemingly small design choices — like type — so important to the overall experience.

Check out the example below. The link underlines have a little more room to breathe (specifically, they appear below the descenders). This is actually something that you can enable sitewide but looks especially nice on article pages since it increases readability. That’s the sort of subtle design choice that contributes to extra breathing room.

text-underline-position: under; is the line of CSS that makes this work. Naturally, text-decoration must be set to something other than none (underline in this case), too.

The example above also features text-decoration-thickness, which alters the thickness of underlines (and other line types). You can use this CSS property to match a line’s thickness to a font’s size and/or weight.

Here’s a full example:

a {
  text-decoration: underline;
  text-decoration-thickness: 2px;

  /* or */
  text-decoration: underline 2px;
  text-underline-position: under;
}

But before you reach for the text-decoration shorthand, Šime Vidas has a few “gotchas” when it comes to using it that are worth reviewing.

Leading into the content

Drop caps are stylized letters that can be placed at the beginning of a document or document section. They were once used in Latin texts, but today they’re mostly used for decorative reasons.

Personally, I think that drop caps hinder readability. However, they can be a nice way to “lead” a reader into the main content, and they shouldn’t introduce any serious accessibility issues as long as you’re using the ::first-letter pseudo-element. There are other (older) methods that involve more HTML and CSS as well as the use of ARIA attributes in order for the content to remain accessible.

Using ::first-letter, the CSS would look something like this:

/* select the first letter of the first paragraph */
article > p:first-child::first-letter {
  color: #903;
  float: left;
  font-family: Georgia;
  font-size: 75px;
  line-height: 60px;
  padding-top: 4px;
  padding-right: 8px;
  padding-left: 3px;
}

It sure would be nice if we could use the initial-letter property, but there’s pretty much no support for it at the time I’m writing this. If we had it, all that math for font size and line height would be calculated for us!

CodePen challenged folks to show off their drop-cap-styling skills several years ago and you can see a whole bunch of neat examples from it in this collection.

Screen readers allow users to skip to the main content as long as it wraps it within a

element. However, those who navigate websites by tabbing don’t benefit from this. Instead, we must create a “skip to main content” anchor link. This link is customarily hidden but revealed once the user makes their first tab (i.e. show on focus).

It would look something like this:


Skip to main content

#skip-link {
  position: absolute; /* remove it from the flow */
  transform: translateX(-100%); /* move it off-screen so that it appears hidden but remains focusable */
}
#skip-link:focus {
  position: unset; /* insert it back into the flow */
  transform: unset; /* move it back onto the screen */
}

.main {
  scroll-margin: 1rem; /* adds breathing room above the scroll target */
}

There are other ways to go about it, of course. Here are a couple of deeper dives on creating skip links.

Article on Aug 3, 2021

A Deep Dive on Skipping to Content

Paul Ratcliffe

Article on Aug 25, 2021

How to Create a “Skip to Content” Link

design design principles editorial typography

Paul Ryan

Seamless visuals

I love the illustrations in this article. Despite how incredible they look, they don’t demand too much cognitive attention. They introduce brief moments of delight but also suggest that the article itself has something more important to say. Partly, this comes down to the use of transparency, whereas rectangular images capture more negative space and therefore demand more attention (which is fine if that’s the desired effect and images are crucial to the story).

However, it’s important to know that the images aren’t actually transparent at all, but instead are non-transparent JPEGs with the same background color as the content. I’m presuming that’s to keep the size of the images smaller compared to PNGs that support transparency.

The downside to “faking” a transparent background like this is that it would require additional trickery (and maintenance) to support a dark mode UI if your site happens to offer one. If the illustrations are pretty flat and simple, then SVG might be the way to go instead since it’s small, scalable, and capable of blending into whatever background it’s on.

But if you’re bound to using raster images and would rather work with PNG files for transparency, you’ll want to look into using responsive images and the loading="lazy" attribute for faster loading times.

Put the focus on the type and semantics

You may have very little say over how or where someone reads content on the web these days. Whether the user receives it in an RSS feed, gets it delivered by email, sees it copy-and-pasted from a colleague, finds it on a scraped site, or whatnot, your content might look different than you prefer. You could design what you think is the most gorgeous article in all the land and the user still might smash that Reader Mode button to your dismay.

That’s ok! The discoverability of content is very much as important as the design of it, and many users have their own ways of discovering content and preferences for what makes a good reading experience.

But there are reasons why someone would want a Reader Mode. For one, it’s like “not seeing any CSS” at all. By that, I mean Safari’s Reader Mode or Brave SpeedReader, which use machine learning to detect articles. There’s no fetching or executing of CSS, JavaScript, or non-article images, which boosts performance and also blocks ads and tracking.

This sort of “brute minimalism” puts the focus on the content rather than the styles. So, you might actually want to embrace a browser’s opinionated reading styles specifically for that purpose.

The way to do that is not by using CSS, but by paying closer attention to your HTML. Reader modes work best with markup that uses simple, semantic, article-related HTML. You’ve got to do more than simply slapping

tags around the article to get the most from it.

You might just find that a minimal design that emphasizes legibility over slickness is actually a good strategy to use in your site’s design. I’d strongly suggest reading Robin’s post on the “smallest CSS” for a solid reading experience.

Roundup of long-form articles!

I’ve shared a lot of what I think makes for a great reading experience for long-form articles on the web. But seeing is believing and I’ve rounded up a bunch of examples that showcase what we’ve covered.

Polygon uses a strong, provacative visual to hook readers into the ain content. Notice how the drop cap, larger font size, and increased line height make this feel like a page you can sit back with and relax.
The TASTE website uses transparent images that blend into the background color of the content. There’s plenty of space between elements and bold accents — like thick borders and a heavy drop cap — pull the reader’s eye down the page.
The Outline is a prime example of minimalism. Notice how something as subtle as a squiggly horizontal rule can be an eye-catching embellishment when there are fewer things competing for attention.
The brutalist style of the Dropbox blog is probably a controversial one. The colors, fonts, and use of space are all over the place, and the content being floated to the right just feels unfamiliar. But does it break any design ‘rules’? Nope. I could grow to like it in time, especially in a milder form.
Urban Beardsman’s design is extremely linear. As somebody that has difficulty concentrating and is easily distracted by sidebars, in-article CTA boxes, and even blockquotes, I very much enjoy how easy it is to read this blog like a book. The perfect example of “less is more.”
There’s nothing unique about the GoSquared blog, but it managed to include pretty much all of the things we discussed in the article — a better underline design, seamless images, and some very readable typography. Quite impressive.
The Smart Passive Income blog proves how far you can get just by choosing a legible font and using readable font sizes, line heights, letter spacings, and paragraph spacings.
Recipe pages are consistently sucky, but not Little Fat Boy. The lack of sameness throughout the page makes it easy jump to different parts of the recipe without getting lost. Plus, the ingredients are pinned to the top-right for your convenience.

Designing for Long-Form Articles originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Improving Icons for UI Elements with Typographic Alignment and Scale

Marcel Moreau — Tue, 17 May 2022 14:30:18 +0000

Utilizing icons in user interface elements is helpful. In addition to element labeling, icons can help reinforce a user element’s intention to users. But I have to say, I notice a bit of icon misalignment while browsing the web. Even if the icon’s alignment is correct, icons often do not respond well when typographic styles for the element change.

I took note of a couple real-world examples and I’d like to share my thoughts on how I improved them. It’s my hope these techniques can help others build user interface elements that better accommodate typographic changes and while upholding the original goals of the design.

Example 1 — Site messaging

I found this messaging example on a popular media website. The icon’s position doesn’t look so bad. But when changing some of the element’s style properties like font-size and line-height, it begins to unravel.

CodePen Embed Fallback

Identified issues

the icon is absolutely positioned from the left edge using a relative unit (rem)
because the icon is taken out of the flow, the parent is given a larger padding-left value to help with overall spacing – ideally, our padding-x is uniform, and everything looks good whether or not an icon is present
the icon (it’s an SVG) is also sized in rems – this doesn’t allow for respective resizing if its parent’s font-size changes

Recommendations

Indicating the issues with aligning the icon and typography.

We want our icon’s top edge to be at the blue dashed line, but we often find our icon’s top edge at the red dashed line.

Have you ever inserted an icon next to some text and it just won’t align to the top of the text? You may move the icon into place with something like position: relative; top: 0.2em. This works well enough, but if typographic styles change in the future, your icon could look misaligned.

We can position our icon more reliably. Let’s use the element’s baseline distance (the distance from one line’s baseline to the next line’s baseline) to help solve this.

Calculating the baseline distance.

Baseline distance is font-size * line-height.

We’ll store that in a CSS custom property:

--baselineDistance: calc(var(--fontSize) * var(--lineHeight));

We can then move our icon down using the result of (baseline distance – font size) / 2.

--iconOffset: calc((var(--baselineDistance) - var(--fontSize)) / 2);

With a font-size of 1rem (16px) and line-height of 1.5, our icon will be moved 4 pixels.

baseline distance = 16px * 1.5 = 24px
icon offset = (24px – 16px) / 2 = 4px

Demo: before and after

CodePen Embed Fallback

Example 2 – unordered lists

The second example I found is an unordered list. It uses a web font (Font Awesome) for its icon via a ::before pseudo-element. There have been plenty of great articles on styling both ordered and unordered lists, so I won’t go into details about the relatively new ::marker pseudo-element and such. Web fonts can generally work pretty well with icon alignment depending on the icon used.

CodePen Embed Fallback

Identified issues

no absolute positioning used – when using pseudo-elements, we don’t often use flexbox like our first example and absolute positioning shines here
the list item uses a combination of padding and negative text-indent to help with layout – I am never able to get this to work well when accounting for multi-line text and icon scalability

Recommendations

Because we’ll also use a pseudo-element in our solution, we’ll leverage absolute positioning. This example’s icon size was a bit larger than its adjacent copy (about 2x). Because of this, we will alter how we calculate the icon’s top position. The center of our icon should align vertically with the center of the first line.

Start with the baseline distance calculation:

--baselineDistance: calc(var(--fontSize) * var(--lineHeight));

Move the icon down using the result of (baseline distance – icon size) / 2.

--iconOffset: calc((var(--baselineDistance) - var(--iconSize)) / 2);

So with a font-size of 1rem (16px), a line-height of 1.6, and an icon sized 2x the copy (32px), our icon will get get a top value of -3.2 pixels.

baseline distance = 16px * 1.6 = 25.6px
icon offset = (25.6px – 32px) / 2 = -3.2px

With a larger font-size of 2rem (32px), line-height of 1.2, and 64px icon, our icon will get get a top value of -12.8 pixels.

baseline distance = 32px * 1.2 = 38.4px
icon offset = (38.4px – 64px) / 2 = -12.8px

Demo: before and after

CodePen Embed Fallback

Conclusion

For user interface icons, we have a lot of options and techniques. We have SVGs, web fonts, static images, ::marker, and list-style-type. One could even use background-colors and clip-paths to achieve some interesting icon results. Performing some simple calculations can help align and scale icons in a more graceful manner, resulting in implementations that are a bit more bulletproof.

Improving Icons for UI Elements with Typographic Alignment and Scale originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

COLRv1 and CSS font-palette: Web Typography Gets Colorful

Ollie Williams — Wed, 11 May 2022 14:12:51 +0000

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.

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
108	107	108	11.0-11.2

COLRv0 and COLRv1

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:

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

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

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

CodePen Embed Fallback

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

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.

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.

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	107	No	105	15.4

Mobile / Tablet

Android Chrome	Android Firefox	Android	iOS Safari
108	107	108	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.

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, which is part of the DigitalOcean family. You should get the newsletter.

8 Interesting Typography Links for January 2022

Chris Coyier — Fri, 07 Jan 2022 22:31:52 +0000

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.

An awesome new font from OH no Type Company

Output Sans goes variable — David Jonathan Ross’s Output is a real workhorse typeface. He’s been re-doing it as a variable as part of an effort to get variable fonts “over the hump” — that is, away from being thought of as experimental and thought of as practical for day-to-day usage.
Line Lengths — Shawn says, “it seems an obvious immediate win to apply max-width: 69ch to your blog content blocks.” Nice. Oliver Schöndorfer dug into line length recently too.
Smarter line-heights with “calc” — Check out this particular part of Josh’s custom CSS reset. A potentially cool way to handle line-height for both body copy and headers in one swoop.
Women in Type — Just an incredible website from the University of Reading team. “These women worked daily on developing and producing typefaces that were, eventually, almost always attributed to male designers. They merit attention as key contributors to the design process of many renowned typefaces that emerged throughout the twentieth century.”
Retail — “Retail is the result of focussing our energy on the not-too-trendy world of humanist sans.” Very nice work from OH no Type Company.
Designers’ Pick: Best Google Fonts for 2022 — The fact that you can go from zero to implemented custom fonts, for free, in like 30 seconds with Google Fonts is going to keep it the most-used custom font solution likely as long as it exists. Fortunately, the website for it has gotten a lot better, the performance of them has gotten good (and controllable), and as this post on Qode shows, there is a ton of really great new choices available. I like the look of Space Grotesk. The Typewolf newsletter is always covering new good ones. Lately: Readex Pro & Spline Sans.
Google Fonts Knowledge — Speaking of Google Fonts! Elliot Jay Stocks worked on this beefy project: “30+ lessons spread out over three modules — “Introducing Type”, “Choosing Type”, and “Using Type” — and 100+ glossary definitions.”
Modern fluid typography editor — The output from this generator tool by Adrian Bece is a lot like the clamp() stuff from Andy’s Consistent, Fluidly Scaling Type and Spacing. Adrian’s helps you visualize the “curve”, but actually this Fluid Type Scale Calculator from Aleksandr Hovhannisyan might be a smidge more useful when setting up a new project as it gives you a full spectrum of custom properties to use.

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, which is part of the DigitalOcean family. You should get the newsletter.

Consistent, Fluidly Scaling Type and Spacing

Andy Bell — Thu, 16 Dec 2021 22:06:03 +0000

When Chris first sent me this prompt, I was thinking about writing about progressive enhancement, but that subject is so wide-reaching to be one thing and all too predictable, especially for those already familiar with my writing. Saying that, what I’m going to outline in this article also isn’t just one thing either, but the day I meet a writing prompt exactly will be the day pigs start flying. This one group of things, though, will change how you write CSS.

I personally think this group of things lets a lot of sites down—especially in a responsive design sense. The things in this group are typography and spacing. So often, I see inconsistent spacing—especially vertically—that makes content hard to scan and creates this subtle, disjointed feeling. The same goes for type: huge headings on small viewports, or heading hierarchies that visually have no contrast in size, rendering them useless in a visual sense.

There is a pretty easy fix for all of this using a sizing scale and fluid type, and I promise it’ll make your websites look and feel heaps better. Let’s get into it.

What the heck is a sizing scale?

A sizing scale is a uniform progression of sizes based on a scale—or, more accurately, a ratio.

In that screenshot of type-scale.com, I’ve selected a “Perfect Fourth” scale which uses a ratio of 1.333. This means each time you go up a size, you multiply the current size by 1.333, and each time you go down a size, you divide by 1.333.

If you have a base font size of 16px, using this scale, the next size up is 16 * 1.333, which is 21.33px. The next size up is 21.33 * 1.333, which is 28.43px. This provides a lovely curve as you move up and down the scale.

CSS `clamp()` and type fluidity

For years, if you were to say, “Hey Andy, what’s your favorite CSS feature?” I would immediately say flexbox, but nah, not these days. I am a clamp() super fan. I wrote about it in more detail here, but the summary of clamp() is that it does clever stuff based on three parameters you give it:

a minimum value
an ideal value
a maximum value

This makes for a very useful tool in the context of fluid typography and spacing, because you write CSS like this:

.my-element {
  font-size: clamp(1rem, calc(1rem * 3vw), 2rem);
}

This tiny bit of CSS gives us full responsive text sizes based on the viewport width with handy locks to make sure sizes don’t get too big or too small.

It’s really important to test that your text is legible when you zoom in and zoom out when using clamp. It should be very obviously larger or smaller. Because we’re using a rem units as part of our fluid calculation, we’re helping that considerably.

Putting it all together

Right, so we’ve got a size scale and CSS clamp() all set up—how does it all come together? The smart people behind Utopia came up with the simplest, but handiest of approaches. I use their type tool and their spacing tool to create size scales for small and large viewports. Then, using clamp(), I generate a master size scale that’s completely fluid, as well as a Sass map that informs Gorko’s configuration.

$gorko-size-scale: (
  '300': clamp(0.7rem, 0.66rem + 0.2vw, 0.8rem),
  '400': clamp(0.88rem, 0.83rem + 0.24vw, 1rem),
  '500': clamp(1.09rem, 1rem + 0.47vw, 1.33rem),
  '600': clamp(1.37rem, 1.21rem + 0.8vw, 1.78rem),
  '700': clamp(1.71rem, 1.45rem + 1.29vw, 2.37rem),
  '800': clamp(2.14rem, 1.74rem + 1.99vw, 3.16rem),
  '900': clamp(2.67rem, 2.07rem + 3vw, 4.21rem),
  '1000': clamp(3.34rem, 2.45rem + 4.43vw, 5.61rem)
);

This snippet is from my site, piccalil.li, and the typography is super simple to work with because of it.

You could also translate that into good ol’ CSS Custom Properties:

:root {
  --size-300: clamp(0.7rem, 0.66rem + 0.2vw, 0.8rem);
  --size-400: clamp(0.88rem, 0.83rem + 0.24vw, 1rem);
  --size-500: clamp(1.09rem, 1rem + 0.47vw, 1.33rem);
  --size-600: clamp(1.37rem, 1.21rem + 0.8vw, 1.78rem);
  --size-700: clamp(1.71rem, 1.45rem + 1.29vw, 2.37rem);
  --size-800: clamp(2.14rem, 1.74rem + 1.99vw, 3.16rem);
  --size-900: clamp(2.67rem, 2.07rem + 3vw, 4.21rem);
  --size-1000: clamp(3.34rem, 2.45rem + 4.43vw, 5.61rem);
};

This approach also works for much larger sites, too. Take the new web.dev design or this fancy software agency’s site. The latter has a huge size scale for large viewports and a much smaller, more sensible, scale for smaller viewports, all perfectly applied and without media queries.

I’m all about keeping things simple. This approach combines a classic design practice—a sizing scale—and a modern CSS feature—clamp()—to make for much simpler CSS that achieves a lot.

Consistent, Fluidly Scaling Type and Spacing originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Coding Font Game

Chris Coyier — Fri, 19 Nov 2021 21:18:50 +0000

A tournament bracket UI where you pick your favorite between two coding fonts and your choices are whittled down all the way to a final winner. A clever way to suss out your own taste and arrive at a choice.

(P.S. We have our own little coding fonts website to showcase some high-quality favorites.)

Wenting Zhang documented in a newsletter (update: that was originally published on the Retool blog, so updating the link) that she built it the whole thing with Retool, meaning she had to write very little code directly, and instead used pre-built components. That’s kind of the point of Retool. It’s like a UI library with existing components for building stuff out quickly, but it goes the extra mile in connecting to your own data.

Five years ago, if I wanted to build this coding font game, I would have had to spend days or weeks hand-coding it in React or other frameworks. But since then, I have discovered no code and low code apps which are essentially libraries of pre-existing informational or functional things. They can be powered by a database or an API, and the interaction layer is standard, often with minimal customization needs.

The two bits of code shared in that post look… pretty complicated. So, in this case, it’s a “low code” thing where those bits of code really hone in on the core functionality and experience, but a lot of the rest of the more mundane and boilerplate code is avoided. Seems compelling to me. In the end, the whole “game” is an pointing to the Retool widget thing.

Coding Font Game originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Line length revisited: following the research

Geoff Graham — Tue, 16 Nov 2021 21:35:39 +0000

Mary Dyson produces nitty gritty research on the long-accepted notion that shorter line lengths are more legible than longer ones. The study finds that shorter lines do not necessarily lead to faster reading. If you’re looking for a definitive answer to use in your next design review debate, though, no dice. The big finding is that long lines don’t slow things down as much as previously thought, not that they’re better or worse.

But there’s so much more meat in here that I found much more interesting, mostly because I’m largely ignorant on the topic and gained a dollop of context on writing, legibility, and behavior.

Things like…

There’s a term for transitioning between lines of text

It’s return sweeps. You know, like your eye hits the Return key at the end of the line and sweeps to the start of the next line. Then, there are undershoots. The idea is that eyes may not sweep to the exact start of the next line, instead stopping a bit short.

Those little rapid eye movements between words and phrases? Those are called saccades. I had to look that up.

The impact of undershoots is what’s being challenged

The previous research we’ve relied on for years comes from 1940(!), a time when we obviously were more concerned with paper pages than bright digital displays. Longer lines, it said, increased the likelihood that eyes undershoot during a return sweep, and undershooting results in a regression that results in a 130ms to 250ms delay where the brain needs to get its bearings. The report refers to that as undersweep-fixation.

We can still process words during undersweep-fixation

This report cites a 2019 study that tried to correct undershoots by bolding the first word at the start of each new line, sort of like an anchor that naturally draws the eye closer to the left margin.

The 2019 study did find that the bolded words did decrease undershot return sweeps But despite that, reading speed did not improve. That’s the impetus for challenging the long-held assumption that shorter is better.

Mary explains further:

In seeking to reconcile why longer line lengths may not slow down reading on screen but do so when reading print, I outlined some differences, e.g. visual angle, time spent scrolling. But although physical differences between reading from screen and reading print still exist, we now have direct evidence to explain why longer lines were read at least as fast as shorter lines. Readers can process words during the brief fixation when undershooting the start of the new line. This saves time in subsequent processing. Now we might also acknowledge that there is greater consistency between the range of optimal line lengths for print and screen.

Where does this leave us today?

Well, nowhere closer to a clear answer we can use in our day-to-day work. But it’s good to dust off our collection of design and copywriting best practices and know that line length is less of a constraint than perhaps it has been.

Again, none of this tells us whether long or short lines are better. Mary ends her report by saying she cannot definitely recommend using longer lines of text because there are clear because there are still some factors at play, including:

Shorter lines are more effective for people with dyslexia.
More questions about return sweeps and undershooting need to be answered.
Several other studies indicate that users prefer shorter lines and judge longer lines as more difficult to read.

To Shared Link — Permalink on CSS-Tricks

Line length revisited: following the research originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Some Typography Links VIII

Chris Coyier — Wed, 20 Oct 2021 23:25:22 +0000

Do you know what to use the @ sign for something other than email addresses and Twitter handles? I do! — Pawel Grzybek notes how some old physical typewriters had an “Arroba” on them which was represented with the @ sign.
Atkinson Hyperlegible Font — The Braille Institute is giving away this font that “focuses on letterform distinction to increase character recognition, ultimately improving readability.” The page itself is set in it so you can get a taste for it just by going there. Looks nice to me. Sorta evokes a slab serif without actually being one?
Marvel Character or Font? — 14/20 and I think I fat-fingered one. Proxima Midnight?! C’mon!
Firefox 92 — Ruth John notes that Firefox now supports font-size-adjust in CSS, as well as size-adjust (which you can only use within a @font-face rule). The point is jiggering your fonts such that if a user sees FOUT at all, there is little reflow jank when the custom font loads. In theory, it makes perfect font fallbacks easier.
Typography for Data — Michael Yom has to re-evalute the type styles in a design system to accomodate some some components with fairly dense/complex type needs.
Improving the New York Times’ line wrap balancer — Daniel Aleksandersen: “A text wrapping balancer is a program that tries to more evenly distribute words over multiple lines. There are at least two dozen algorithms used to achieve this.” This new one is faster than Adobe’s popular one.
Line length revisited: following the research — Mary Dyson goes deep. Apparently most of the older research on this was based on print, which, I hope we all know by now, just ain’t the same as a digital screen. We might be able to go a little longer, but as with anything, it depends.

Some Typography Links VIII originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Firefox’s `bolder` Default is a Problem for Variable Fonts

Šime Vidas — Tue, 07 Sep 2021 14:41:57 +0000

Variable fonts make it easy to create a large set of font styles from a single font file. Unfortunately, the default rendering of the and elements in browsers today is not very compatible with the wide range of font-weight values enabled by variable fonts.

https://twitter.com/zachleat/status/1374443096281280517

Browsers disagree on the default font-weight of

The purpose of the and elements is to draw attention to a specific word or span of text on the page. Browsers make these elements stand out by increasing their font-weight. This works well under normal conditions. For example, MDN Web Docs uses in a few places in the “Found a problem?” card at the bottom of each page.

Things become more complicated when the text on the page has a custom font-weight. The default weight of text is 400, but the font-weight property accepts any number between 1 and 1000 (inclusive). Let’s take a look at how Chrome and Firefox render text wrapped in by default depending on the font-weight of the surrounding text.

View on CodePen

Chrome and Firefox disagree on the default rendering of elements. Chrome uses a constant font-weight of 700 (Safari behaves the same), while Firefox chooses between three values (400, 700, and 900) depending on the font-weight of the surrounding text.

Where is this difference coming from?

As you might have guessed, Chrome and Firefox use different font-weight values for the and elements in their user agent stylesheets.

/* Chrome and Safari’s user agent stylesheet */ strong, b { font-weight: bold; } /* Firefox’s user agent stylesheet */ strong, b { font-weight: bolder; }

The bold and bolder values are specified in the CSS Fonts module; bold is equivalent to 700, while bolder is a relative weight that is calculated as follows:

If the outer text has a font-weight of… the bolder keyword computes to…
1 to 349 400
350 to 549 700
550 to 899 900
900 to 1000 No change (same value as outer text)

Chrome and Firefox disagree on the default rendering of , but which browser follows the standards more closely? The font-weight property itself is defined in the CSS Fonts module, but the suggested font-weight values for different HTML elements are located in the Rendering section of the HTML Standard.

/* The HTML Standard suggests the following user agent style */ strong, b { font-weight: bolder; }

The HTML Standard started suggesting bolder instead of bold all the way back in 2012. As of today, only Firefox follows this recommendation. Chrome and Safari have not made the switch to bolder. Because of this inconsistency, the popular Normalize base stylesheet has a CSS rule that enforces bolder across browsers.

Which of the two defaults is better?

There are two different defaults in browsers, and Firefox’s default matches the standard. So, should Chrome align with Firefox, or is Chrome’s default the better one? Let’s take another look at the default rendering of the element.

View on CodePen

Each of the two defaults has a weak spot: Chrome’s bold default breaks down at higher font-weight values (around 700), while Firefox’s bolder default has a problem with lower font-weight values (around 300).

In the worst-case scenario for Firefox, text wrapped in becomes virtually indiscernible. The following screenshot shows text at a font-weight of 349 in Firefox. Can you spot the single word that is wrapped in ? Firefox renders this element at a default font-weight of 400, which is an increase of only 51 points.

(View on CodePen)

The takeaway

If you use thin fonts or variable fonts at font-weight values below 350, be aware that the and elements may not always be discernible in Firefox by default. In this case, it is probably a good idea to manually define a custom font-weight for and instead of relying on the browser’s sub-optimal default, which insufficiently increases the font-weight of these elements.

/* Defining the regular and bold font-weight at the same time */ body { font-weight: 340; } b, strong { font-weight: 620; }

The bolder value is outdated and doesn’t work well with variable fonts. Ideally, text wrapped in should be easy to spot regardless of the font-weight of the surrounding text. Browsers could achieve that by always increasing the font-weight by the same or a similar amount.

On that note, there is a discussion in the CSS Working Group about allowing percentages in font-weight in the same manner as in font-size. Lea Verou writes:

A far more common use case is when we want a bolder or lighter stroke than the surrounding text, in a way that’s agnostic to the weight of the surrounding text.

/* Increasing font-size by 100% */ h1 { font-size: 200%; } /* PROPOSAL - Increasing font-weight by 50% */ strong, b { font-weight: 150%; }

Taking variable fonts into account, a value like 150% would probably be a better default than the existing bold/bolder defaults in browsers today.

Firefox’s `bolder` Default is a Problem for Variable Fonts originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

If the outer text has a `font-weight` of…	the `bolder` keyword computes to…
`1` to `349`	`400`
`350` to `549`	`700`
`550` to `899`	`900`
`900` to `1000`	No change (same value as outer text)

Some Typography Links VII

Chris Coyier — Wed, 01 Sep 2021 14:37:38 +0000

SKWAR — Heydon Pickering made a hard-edged monospaced variable font. The axes are width and weight.
Twenty Bits I Learned About Making Fonts Book — Dan Cederholm has been making fonts, like Captain Edward and Ship Whistle and has turned his learnings into a book.
The perfect cross-platform serif and sans-serif font stacks — Daniel Aleksandersen has lots of details about pre-installed fonts across operating systems, like: Mac and iOS also come with Helvetica Neue preinstalled. It addresses some of Helvetica’s legibility issues … On Windows, you might find a more modern version of Arial called Arial Nova. Arial Nova makes much the same legibility improvements and compromises as Helvetica Neue.
Pairing fonts – 3 ways to find great typeface combinations — Oliver Schöndorfer says it’s an artistist decision so don’t be afraid to try stuff. But also, do you even need more than one? If so, have a reason. Repeat your font choices as often as you can, and only when something does not work in a given situation, add a new style.
Twitter thread about Really Sans — Riley Cran gets into optical sizing and how Really Sans […] is a sans serif typeface with two optical sizes. The small optical size works for text. The large optical size revives the tone of the 1970s headlines. I see Riley is using the pricing model based on # of employees rather than pageviews which I love.
Helvetica® Now Variable — I think having major fonts like Helvetica, that a lot of brands rely on, is the kind of thing that pushes the needle on variable fonts forward.
Fonts in the Twilight Zone — John Boardley looks at some rather unclassifiable fonts: Among my favorite kinds of typefaces are those that don’t fit neatly into predefined or existing categories; those that dip their toes into more than one genre, or take their cues from disparate historical periods.
Coding with Character — Doug Wilson looks at coding typefaces: If you spend all day looking at code, letters, and characters—why not make it fun? I’m down.

Article on Aug 24, 2021
Some Typography Links I

typography variable fonts

Chris Coyier

Article on Aug 24, 2021
Some Typography Links II

typography variable fonts

Chris Coyier

Article on Aug 24, 2021
Some Typography Links III

typography variable fonts

Chris Coyier

Article on Aug 24, 2021
Some Typography Links IV

typography variable fonts

Chris Coyier

Article on Sep 1, 2021
Some Typography Links V

typography variable fonts

Chris Coyier

Article on Sep 1, 2021
Some Typography Links VI

typography variable fonts

Chris Coyier

Some Typography Links VII originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Some Typography Links VI

Chris Coyier — Fri, 16 Jul 2021 14:42:40 +0000

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 , 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 fonts — Just 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.

Some Typography Links VI originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Working around the viewport-based fluid typography bug in Safari

Chris Coyier — Mon, 28 Jun 2021 21:17:26 +0000

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.

To Shared Link — Permalink on CSS-Tricks

Working around the viewport-based fluid typography bug in Safari originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Some Typography Links V

Chris Coyier — Fri, 18 Jun 2021 13:44:17 +0000

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
always being the same size as
. Makes me feel extra sad for
, 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, , 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.

Some Typography Links V originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

How to Create Neon Text With CSS

Silvia O'Dwyer — Tue, 18 May 2021 14:31:25 +0000

Neon text can add a nice, futuristic touch to any website. I’ve always loved the magic of neon signs, and wanted to recreate them using CSS. I thought I’d share some tips on how to do it! In this article, we’re going to take a look at how to add glowing effects to text. We’ll also take a look at various ways to animate the neon signs, all using CSS and keyframes.

Here’s what we’ll be making:

Adding a glow effect to text

First, let’s make the text glow. This can be done in CSS with the text-shadow property. What’s neat about text-shadow is that we can apply multiple shadows on it just by comma-separating them:

.neonText { color: #fff; text-shadow: 0 0 7px #fff, 0 0 10px #fff, 0 0 21px #fff, 0 0 42px #0fa, 0 0 82px #0fa, 0 0 92px #0fa, 0 0 102px #0fa, 0 0 151px #0fa; }

text-shadow requires four values, the first two of which represent the horizontal and vertical position of the shadow, respectively. The third value represents the size of the blur radius while the last value represents the color of the shadow. To increase the size of the glow effect, we would increase the third value, which represents the blur radius. Or, expressed another way:

text-shadow: [x-offset] [y-offset] [blur-radius] [color];

Here’s what we get with that small bit of CSS:

CodePen Embed Fallback

The next thing you might be wondering is what’s up with all of those values? How did I get those and why are there so many? First, we added white glow effects to the outer edges of the text’s letters with a small blur radius.

.neonText { color: #fff; text-shadow: /* White glow */ 0 0 7px #fff, 0 0 10px #fff, 0 0 21px #fff, }

The last five values are wider text shadows of a larger blur radius that forms the green glow.

.neonText { color: #fff; text-shadow: /* White glow */ 0 0 7px #fff, 0 0 10px #fff, 0 0 21px #fff, /* Green glow */ 0 0 42px #0fa, 0 0 82px #0fa, 0 0 92px #0fa, 0 0 102px #0fa, 0 0 151px #0fa; }

It’d be great if we could accomplish this with fewer than five shadows, but we need all these shadows so that they can be stacked over one another to add more depth to the glow. If we had used a single text-shadow instead, the effect would not have the depth required to make it look realistic.

CodePen Embed Fallback

Go ahead and experiment with various hues and colors as well as blur radius sizes! There’s a huge variety of cool glow effects you can make, so try different variations — you can even mix and match colors where one color blends into another.

The “flickering” effect

One thing you might notice about neon signs is that some of them — particularly older ones — tend to flicker. The light kind of goes in and out. We can do the same sort of thing with CSS animations! Let’s reach for @keyframes to make an animation that flickers the light on and off in quick, seemingly random flashes.

@keyframes flicker { 0%, 18%, 22%, 25%, 53%, 57%, 100% { text-shadow: 0 0 4px #fff, 0 0 11px #fff, 0 0 19px #fff, 0 0 40px #0fa, 0 0 80px #0fa, 0 0 90px #0fa, 0 0 100px #0fa, 0 0 150px #0fa; } 20%, 24%, 55% { text-shadow: none; } }

That’s really it! We’ve taken the exact same text-shadow property and values we had before, wrapped them in a @keyframes animation called flicker, and chose points in the timeline to apply the shadows, as well as points that completely remove the shadows.

All that’s left is to call the animation where we want the light to flicker. In this particular case, let’s only add it to the
element. Having one part of the entire sign flicker feels a little more realistic than if we applied the flicker to all of the text.

h1 { animation: flicker 1.5s infinite alternate; }

Note that if we did want the entire sign to flicker, then we could technically remove the text-shadow values on the .neonText class, add the animation to it, and let the @keyframes apply the shadows instead.

CodePen Embed Fallback

It’s quite a cool effect, and adds more realism to our neon text! Of course, there are other effects you could try out too, which will also be explored further in this article. For example, how about more of a pulsating animation or a more subtle flicker?

CodePen Embed Fallback

Let’s explore those and other effects!

Pulsating glow

We just got a quick peek at this. It uses keyframes, just as the previous example does, where we specify the size of the blur radius at the start and end of the animation.

We want the size of the blur radius to be smallest at the end of the animation, so we simply decrease the blur radius values for each text-shadow value in the 0% keyframe. This way, the size of the blur gradually ebbs and flows, creating a pulsating effect.

@keyframes pulsate { 100% { /* Larger blur radius */ text-shadow: 0 0 4px #fff, 0 0 11px #fff, 0 0 19px #fff, 0 0 40px #0fa, 0 0 80px #0fa, 0 0 90px #0fa, 0 0 100px #0fa, 0 0 150px #0fa; } 0% { /* Smaller blur radius */ text-shadow: 0 0 2px #fff, 0 0 4px #fff, 0 0 6px #fff, 0 0 10px #0fa, 0 0 45px #0fa, 0 0 55px #0fa, 0 0 70px #0fa, 0 0 80px #0fa; } }

Once again, we add the animation to some element. We’ll go with
again:

h1 { animation: pulsate 2.5s infinite alternate; }

Here it is with it all put together:

CodePen Embed Fallback

Subtle flicker

We can tone things down a bit and make the flickering action super subtle. All we need to do is slightly decrease the size of the blur radius in the 0% keyframe, just not to the extent as seen in the previous example.

@keyframes pulsate { 100% { /* Larger blur radius */ text-shadow: 0 0 4px #fff, 0 0 11px #fff, 0 0 19px #fff, 0 0 40px #f09, 0 0 80px #f09, 0 0 90px #f09, 0 0 100px #f09, 0 0 150px #f09; } 0% { /* A slightly smaller blur radius */ text-shadow: 0 0 4px #fff, 0 0 10px #fff, 0 0 18px #fff, 0 0 38px #f09, 0 0 73px #f09, 0 0 80px #f09, 0 0 94px #f09, 0 0 140px #f09; } }

Since the flickering is more subtle and the reduction of the blur radius is not as large, we should increase the number of times this animation occurs per second in order to emulate more frequent flickering. This can be done by decreasing the animation’s duration, say to a mere 0.11s:

h1 { animation: pulsate 0.11s ease-in-out infinite alternate; }

CodePen Embed Fallback

Using a background image

It would be really neat if our sign was hanging on a wall instead of empty space. Let’s grab a background image for that, maybe some sort of brick texture from Unsplash or something:

body { background-image: url(wall.jpg); }

CodePen Embed Fallback

Adding a border

One last detail we can add is some sort of circular or rectangular border around the sign. It’s just a nice way to frame the text and make it look like, you know, an actual sign. By adding a shadow to the border, we can give it the same neon effect as the text!

Whatever element is the container for the text is what needs a border. Let’s say we’re only working with an
element. That’s what gets the border. We call the border shorthand property to make a solid white border around the heading, plus a little padding to give the text some room to breathe:

h1 { border: 0.2rem solid #fff; padding: 0.4em; }

We can round the corners of the border a bit so things aren’t so sharp by applying a border-radius on the heading. You can use whatever value works best for you to get the exact roundness you want.

h1 { border: 0.2rem solid #fff; border-radius: 2rem; padding: 0.4em; }

The last piece is the glow! Now, text-shadow won’t work for the border here but that’s okay because that’s what the box-shadow property is designed to do. The syntax is extremely similar, so we can even pull exactly what we have for text-shadow and tweak the values slightly:

h1 { border: 0.2rem solid #fff; border-radius: 2rem; padding: 0.4em; box-shadow: 0 0 .2rem #fff, 0 0 .2rem #fff, 0 0 2rem #bc13fe, 0 0 0.8rem #bc13fe, 0 0 2.8rem #bc13fe, inset 0 0 1.3rem #bc13fe; }

Notice that inset keyword? That’s something text-shadow is unable to do but adding it to the border’s box-shadow allows us to get some of the glow on both sides of the border for some realistic depth.

CodePen Embed Fallback

What about accessibility?

If users have a preference for reduced motion, we’ll need to accommodate for this using the prefers-reduced-motion media query. This allows us to remove our animation effects in order to make our text more accessible to those with a preference for reduced motion.

For example, we could modify the flashing animation from the Pen above so that users who have prefers-reduced-motion enabled don’t see the animation. Recall that we applied the flashing effect to the
element only, so we’ll switch off the animation for this element:

@media screen and (prefers-reduced-motion) { h1 { animation: none; } }

It’s incredibly important to ensure that users’ preferences are catered for, and making use of this media query is a great way to make the effect more accessible for those with a preference for reduced motion.

Conclusion

Hopefully this has shown you how to create cool neon text for your next project! Make sure to experiment with various fonts, blur radius sizes and colors and don’t forget to try out different animations, too — there’s a world of possibilities out there. And add a comment if you’ve created a neat shadow effect you want to share. Thanks for reading!

How to Create Neon Text With CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Some Typography Links IV

Chris Coyier — Fri, 07 May 2021 13:54:01 +0000

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.

Some Typography Links IV originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

typography – CSS-Tricks

Designing for Long-Form Articles

Quick wins

Design for extra breathing room

Leading into the content

Skip to main content

Seamless visuals

Put the focus on the type and semantics

Roundup of long-form articles!

Improving Icons for UI Elements with Typographic Alignment and Scale

Example 1 — Site messaging

Identified issues

Recommendations

Demo: before and after

Example 2 – unordered lists

Identified issues

Recommendations

Demo: before and after

Conclusion

COLRv1 and CSS font-palette: Web Typography Gets Colorful

COLR support

Desktop

Mobile / Tablet

COLRv0 and COLRv1

COLR and CSS

Current limitations

Browser support

Desktop

Mobile / Tablet

Use cases

COLR and icon fonts

Solving the emoji problem

Wrapping up

8 Interesting Typography Links for January 2022

Consistent, Fluidly Scaling Type and Spacing

What the heck is a sizing scale?

CSS clamp() and type fluidity

Putting it all together

Coding Font Game

Line length revisited: following the research

There’s a term for transitioning between lines of text

The impact of undershoots is what’s being challenged

We can still process words during undersweep-fixation

Where does this leave us today?

Some Typography Links VIII

Firefox’s `bolder` Default is a Problem for Variable Fonts

Browsers disagree on the default font-weight of

Where is this difference coming from?

Which of the two defaults is better?

The takeaway

Some Typography Links VII

Some Typography Links VI

Working around the viewport-based fluid typography bug in Safari

Some Typography Links V

always being the same size as . Makes me feel extra sad for

, are you destined to be smaller than body copy?

How to Create Neon Text With CSS

Adding a glow effect to text

The “flickering” effect

Pulsating glow

again: h1 { animation: pulsate 2.5s infinite alternate; } Here it is with it all put together: CodePen Embed Fallback

Subtle flicker

Using a background image

Adding a border

What about accessibility?

Conclusion

Some Typography Links IV

CSS `clamp()` and type fluidity

Browsers disagree on the default `font-weight` of

always being the same size as
. Makes me feel extra sad for

again:

`h1 { animation: pulsate 2.5s infinite alternate; }`

Here it is with it all put together:

CodePen Embed Fallback