DEV Community: Adam Butterfield

Custom Styling Checkboxes: The Modern Way

Adam Butterfield — Tue, 12 Sep 2023 21:40:56 +0000

TL;DR:

I made another thing. Maybe you think it's cool? See code here.

For people who read, please continue.

Also, in case you missed it, I got a write up about custom styling radio buttons too!

Since radio buttons and checkboxes are kind of the siblings of the input world, a lot of what I already wrote about radio buttons applies here as well. They share the same traditional approach for styling, they share the same limitation for using pseudo-elements, and they share the same accessibility concerns.

So really, if you didn't read my article about radio buttons, you might want to do that first.

Let's get to the code!

My approach for styling checkboxes uses more or less the same approach as for radio buttons.

Let's break it down step by step:

1. Define Color Variables

Using the :root selector, we can define global CSS variables. This makes it easier to change the color scheme without having to search and replace values throughout the CSS.

Of course it's up to you with how creative you want to be with the colors. But at minimum you will need 4 different colors:

Border color
Checked color
Hover color
Disabled background color

It's pretty common these days to two tones of blue and two tones of gray (as I did here).

:root {
  --checkbox-border-color: #8b8c89;
  --checkbox-checked-color: #274c77;
  --checkbox-hover-color: #a3cef1;
  --checkbox-disabled-bg-color: #d9d9d9;
}

I actually used the same colors as for radio buttons. So in your design system or application, you will want to rename the variables and use them consistently across both types of inputs.

2. Base Styling

The core styling for our checkboxes. Same as with radio buttons, we use the appearance property set to none to remove the default appearance of the checkbox. (More info on appearance in my other article.)

input[type="checkbox"] {
  box-sizing: border-box;
  width: 20px;
  height: 20px;
  margin: 6px;
  padding: 0;
  border: 2px solid var(--checkbox-border-color);
  appearance: none;
  background-color: transparent;
  outline: none;
  transition: outline 0.1s;
}

3. Styling the Checked State

The :not() pseudo-class combined with :checked is used to style checkboxes when they're checked, but not disabled. I'm a big fan of using pseudo-classes like this to be really explicit when these styles are applied, instead of letting things cascade and just overwriting them farther down the stylesheet.

For radio buttons, we used radial-gradient to create the appearance of a selected inner circle. For checkboxes, we can't use the same approach. It's pretty easy to use linear-gradient to draw an X mark for the checked state. It might be possible to draw a check mark as well, but I decided to use background-image with an inlined svg instead.

Both the disabled and non-disabled states share some styles, which is why we have the first block. With the second block only applying to :not(:disabled):checked.

input[type="checkbox"]:checked {
  background-size: cover;
  padding: 2px;
}

input[type="checkbox"]:not(:disabled):checked {
  border-color: var(--checkbox-checked-color);
  background-image: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="20" height="20" viewBox="0 0 32 32" xml:space="preserve"><path style="fill: %23274c77" d="M11.941,28.877l-11.941-11.942l5.695-5.696l6.246,6.246l14.364-14.364L32,8.818"/></svg>');
}

So why use an inline svg? Of course we all know that a svg scales much better than a plain old image, which could be important because the check mark is so small and we want it to look nice and sharp. We will also need to use the same check mark for the disabled state, but with a different color. And of course we can change the color of a svg. If using images, we would need 2 separate ones with different colors. Then finally, we want to inline the svg so we don't get a flash of unstyled content while your application has to go fetch the asset if it was on a remote resource.

One important thing to notice about the svg. For setting the color, you need to URL encode the color variable, which is why you see %23274c77 (of course "%23" === "#"). Unfortunately we can't use the CSS variables, there's an issue with using CSS variables within data: URIs. CSS variables won't be evaluated within the context of a data: URI because they are processed within the CSS of your stylesheet, and data: URIs are typically not part of that processing. Kind of a bummer...

4. Styling for Disabled State

For the disabled state, we only need to add a background color, and cover the case when a checkbox can be checked && disabled. Here we use the same svg, but with a different fill color.

input[type="checkbox"]:disabled {
  background-color: var(--checkbox-disabled-bg-color);
}

input[type="checkbox"]:disabled:checked {
  background-image: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="20" height="20" viewBox="0 0 32 32" xml:space="preserve"><path style="fill: %238b8c89" d="M11.941,28.877l-11.941-11.942l5.695-5.696l6.246,6.246l14.364-14.364L32,8.818"/></svg>');
}

That covers the basic states of the input. Now time to move on to the interactions.

5. Enhancing Hover Effects

The @media (hover: hover) media query ensures that hover effects are applied only on devices that support hovering, like desktops. This detail is easy to overlook, especially if you haven't worked with CSS recently.

@media (hover: hover) {
  input[type="checkbox"]:not(:disabled):hover {
    background-color: var(--checkbox-hover-color);
    outline: 6px solid var(--checkbox-hover-color);
    transform: scale(1.05);
  }
}

6. Focus Indication with :focus-visible

The :focus-visible pseudo-class is a modern approach to style the focus state only when it's relevant (like when using keyboard navigation). No longer do you have to annoy users (and of course get annoyed yourself) by showing a focus ring to users who don't need it.

input[type="checkbox"]:focus-visible {
  outline: 6px solid var(--checkbox-hover-color);
  transform: scale(1.05);
}

In the current code, both hover/focus have the same style. This may not be the case though for you. Always make sure to follow accessibility best practices when picking colors and width of hover/focus ring effects.

7. Adding the Finishing Touches

I already included the same smooth transitions, subtle scaling in the checkbox code that I added to the radio buttons. Wwe also want to honor user preferences the same way we did with radio buttons. You'll see that in the final code, but I won't explain that again here for checkboxes.

And that's about it for the code.

You can find the full code here.

Make sure you also read about the accessibility concerns before applying this or any custom input in your application.

Parting Words

(Totally just copy/pasting this from my other article. Very anti-DRY of me...)

Modern CSS offers a cleaner, more streamlined approach to customizing checkboxes without the need for extra HTML or convoluted CSS. Embracing these techniques allows for efficient, maintainable, and user-friendly designs.

Always think about WHY you want to create a custom checkbox in the first place. If the reason is to offer a better experience to users, then be sure to think about ALL users; think about accessibility. By focusing on accessibility from the outset, designers and developers can ensure a more inclusive web experience for all users, regardless of their abilities or how they access content.

And if improving user experience is really your goal, make sure to keep things as performant as you can. I don't think we're really optimizing early here or anything. It's a simple matter of less code means less bugs, less bytes sent down the wire, and hopefully after reading this, less css in js in your application or design system.

JavaScript got 99 problems, but Bun ain't one?

Adam Butterfield — Sat, 09 Sep 2023 00:47:06 +0000

I reckon I've come across at least 100 articles discussing JavaScript fatigue over the years. Undoubtedly, for those who have experienced the challenges of upgrading Node versions and dealing with major package version updates, wiring different development, build and testing tools together, the difficulties are undeniable.

However, is there a single solution on the horizon to alleviate all this frustration?

Enter Bun.

Bun is an all-in-one toolkit for JavaScript and TypeScript development, offering fast performance, simplified tooling, and seamless integration. The project has been in development for the last two years, but Bun team just announced the release of v1.0.

Bun serves as a replacement for various existing tools, including Node.js, transpilers, bundlers, package managers, and testing libraries. Bun provides Node.js compatibility, exceptional speed, TypeScript and JSX support, Web API integration, hot reloading, customizable plugins, and optimized standard library APIs. Additionally, Bun functions as a package manager, a bundler with a plugin API, and a test runner with Jest compatibility. It introduces JavaScript macros for bundle-time execution and offers experimental support for Windows. The release marks the beginning of Bun's journey toward new deployment methods for JavaScript and TypeScript.

Sounds pretty awesome if you ask me. But...will it live up to it's promise?

Maybe, maybe not.

On this Hacker News thread about the v1.0 release, there's some valid comments about the discrepancy between Bun being a "drop-in replacement for Node.js", while also admitting Bun doesn't implement all of Node.js. There is a page documenting Node.js compatibility, but yeah, I kind of agree that a drop-in replacement should ideally come without any exceptions.

Regardless, I'm willing to give it a try. Could Bun be the start of a new era of JS/TS development? Or maybe serve as inspiration and motivation for the Node.js team to bring the now 14 year old runtime to serve the needs of current development? Or will we all be replaced by AI by that time? Only time will tell...

Custom Styling Radio Buttons: The Modern Way

Adam Butterfield — Sat, 02 Sep 2023 16:39:05 +0000

TL;DR:

I made a thing. Maybe you think it's cool? See code here.

For people who read, please continue.

Radio buttons have been around for quite some time, and as a staple of UI, developers often want to style them to better match the theme or style of their applications. The traditional way to customize radio buttons usually involves extra HTML elements or wrapping the radio input with a label, coupled with the use of :before and :after pseudo-elements. However, with the advancements in modern CSS, we can now style them with just the input element alone.

The Traditional Approach

In the past, custom styling radio buttons usually involved:

Additional HTML elements (like div or span) as overlays.
Utilizing the sibling selector combined with label elements.
Leveraging :before and :after pseudo-elements to create custom designs.

While these methods are tried and true, they can be cumbersome and add unnecessary weight to the DOM.

The Pseudo-Element Limitation on Input Elements

An often overlooked, but crucial detail when styling form elements, particularly input, is their limitation with :before and :after pseudo-elements. Historically, these pseudo-elements have been used extensively to add decorative content or visual cues to elements. However, input elements are "replaced elements", and as per the CSS specification, replaced elements and their pseudo-elements do not have a visual box and thus cannot be styled or receive generated content using :before and :after (see here and here).

This limitation often led designers and developers to resort to workarounds, like wrapping input elements inside other elements or using sibling selectors combined with label elements. While these methods work, they introduce unnecessary complexity and can bloat the DOM.

By leaning into modern CSS, as I outline below, we sidestep the need for these workarounds entirely. We embrace a more streamlined approach, focusing on the input element itself, and doing away with the need for extra HTML or pseudo-elements.

Embracing Modern CSS

Modern CSS has introduced several properties and selectors that make styling more straightforward, cleaner, and maintainable.

Let's break down the new approach, step by step:

1. Define Color Variables

Using the :root selector, we can define global CSS variables. This makes it easier to change the color scheme without having to search and replace values throughout the CSS.

Of course it's up to you with how creative you want to be with the colors. But at minimum you will need 4 different colors:

Border color
Checked color
Hover color
Disabled background color

It's pretty common these days to two tones of blue and two tones of gray (as I did here).

:root {
  --radio-border-color: #8b8c89;
  --radio-checked-color: #274c77;
  --radio-hover-color: #a3cef1;
  --radio-disabled-bg-color: #d9d9d9;
}

2. Base Styling

The core styling for our radio button. We use the appearance property set to none to remove the default appearance of the radio button.

input[type="radio"] {
  box-sizing: border-box;
  width: 20px;
  height: 20px;
  margin: 6px;
  padding: 0;
  border: 2px solid var(--radio-border-color);
  border-radius: 50%;
  appearance: none;
  background-color: transparent;
  outline: none;
}

Of course the appearance property isn't exactly new. In fact, it actually has quite a rich history...

Side quest: A Brief History of the appearance property

Early Days & Vendor Prefixes (Late 1990s - Early 2000s):

In the late 1990s and early 2000s, web browsers had implemented proprietary properties to allow for the customization of form controls. That era was marked by vendor prefixes:

-webkit-appearance was for WebKit browsers (like Chrome and Safari)
-moz-appearance was for Firefox

Discouraged Use (Mid-2000s):

By the mid-2000s, as more developers had begun to explore the web's capabilities, the non-standard nature of the appearance property had led to its discouraged use. The cross-browser inconsistency had meant that web developers often had to rely on hacks and workarounds.

Standardization Efforts (Late 2000s - Early 2010s):

By the late 2000s, the CSS Working Group had started discussions about the appearance property's potential standardization. It had been considered for inclusion in the CSS UI (User Interface) specification drafts. The property was formally introduced in the CSS Basic User Interface Module Level 3 (CSS3 UI) around 2012.

Modern Usage (Mid-2010s - Present):

From the mid-2010s onwards, browsers had started aligning their implementations with the CSS3 UI specification. The use of vendor prefixes had started to decline, with many modern browsers having begun to support the unprefixed appearance property. By 2019, the widespread support for appearance: none had solidified its position as a reliable tool for web developers.

Now back to your regularly scheduled article.

3. Styling the Checked State

The :not() pseudo-class combined with :checked is used to style radio buttons when they're checked, but not disabled. I'm a big fan of using pseudo-classes like this to be really explicit when these styles are applied, instead of letting things cascade and just overwriting them farther down the stylesheet.

The radial-gradient creates the appearance of a selected inner circle. Instead of reaching for SVGs (I'm looking at you Material UI), or using wrappers and whatever else, we can draw that circle with just straight up CSS!

input[type="radio"]:not(:disabled):checked {
  border-color: var(--radio-checked-color);
  background-color: var(--radio-checked-color);
  background-clip: content-box;
  padding: 2px;
  background-image: radial-gradient(
    circle,
    var(--radio-checked-color) 0%,
    var(--radio-checked-color) 50%,
    transparent 60%,
    transparent 100%
  );
}

4. Styling for Disabled State

For the disabled state, we only need to add a background color, and cover the case when a radio can be checked && disabled.

input[type="radio"]:disabled {
  background-color: var(--radio-disabled-bg-color);
}

input[type="radio"]:disabled:checked {
  background-image: radial-gradient(
    circle,
    var(--radio-border-color) 0%,
    var(--radio-border-color) 50%,
    transparent 50%,
    transparent 100%
  );
}

That covers the basic states of the input. Now time to move on to the interactions.

5. Enhancing Hover Effects

@media (hover: hover) {
  input[type="radio"]:not(:disabled):hover {
    background-color: var(--radio-hover-color);
    outline: 6px solid var(--radio-hover-color);
  }
}

6. Focus Indication with :focus-visible

input[type="radio"]:focus-visible {
  background-color: var(--radio-hover-color);
  outline: 6px solid var(--radio-hover-color);
}

7. Adding the Finishing Touches

Refinements can make a big difference in user experience. There's a couple things we can add to polish this thing up a bit:

Smooth Transitions:

A slight transition can make state changes feel more natural.

input[type="radio"] {
  box-sizing: border-box;
  width: 20px;
  height: 20px;
  margin: 6px;
  padding: 0;
  border: 2px solid var(--radio-border-color);
  border-radius: 50%;
  appearance: none;
  background-color: transparent;
  outline: none;
+ transition: outline 0.1s;
}

Subtle Scaling:

A hint of scaling can indicate interaction, provided it's not overdone.

@media (hover: hover) {
  input[type="radio"]:not(:disabled):hover {
    background-color: var(--radio-hover-color);
    outline: 6px solid var(--radio-hover-color);
+   transform: scale(1.05);
  }
}

input[type="radio"]:focus-visible {
  background-color: var(--radio-hover-color);
  outline: 6px solid var(--radio-hover-color);
+ transform: scale(1.05);
}

Honoring User Preferences:

With the prefers-reduced-motion media query, we ensure that our design respects users who prefer reduced motion.

@media (prefers-reduced-motion: reduce) {
  input[type="radio"] {
    transition: none;
  }

  input[type="radio"]:focus-visible {
    transform: scale(1);
  }
}

@media (prefers-reduced-motion: reduce) and (hover: hover) {
  input[type="radio"]:not(:disabled):hover {
    transform: scale(1);
  }
}

And that's about it for the code.

You can find the full code here (and here if you use scss or some preprocessor with nested styles, but it's only 4 lines shorter, so who needs it anyways?).

Accessibility Considerations for Custom Radio Button Styling

In the world of web design, aesthetics often take center stage. However, it's super important that our designs are not just visually appealing but also accessible to all, including persons with disabilities. Ensuring that your custom-styled elements remain user-friendly and compliant with accessibility standards is both a responsibility and a mark of excellent web design.

There are several important things to think about if you want to use my approach, or use any other custom radio button implementation.

Contrast

Ensure the colors you choose meet the minimum contrast ratios set by the Web Content Accessibility Guidelines (WCAG). Tools like the WebAIM Color Contrast Checker can help evaluate your color choices.

Label Associations

Wrap the input with a label to increase the clickable/tappable area, making it easier for everyone, especially users with motor impairments. Ensure the label contains descriptive text that clearly indicates the choice the radio button represents.

<label>
  <input type="radio" name="choice" value="option1" />
  Descriptive Option Text
</label>

Focus Styles

The custom radio button uses :focus-visible to show a distinct style when the radio is focused. It’s crucial to ensure that the focus style is clearly visible to aid keyboard-only users in navigating and making selections.

Size Matters

Aim for a minimum size of 44x44 pixels for the clickable/tappable area, as recommended by the WCAG. This size is not only beneficial for users with motor impairments but also improves the experience for mobile users. The current size in these styles is only 20x20 pixels, so you will want to have the label wrapping the input at least 44x44 pixels.

Be Sensible with Animations

While subtle transitions and animations (like scaling) can enhance user experience, avoid overly complex or distracting animations. Some users are sensitive to motion. Always include a provision for users who have set a preference for reduced motion.

Semantic HTML

Ensure that the HTML structure is semantic. While styling is important, maintaining the semantic integrity of elements like input and label ensures assistive technologies can interpret and convey the content effectively. Of course you can always aria-hidden="true" to unnecessary markup, but more code === more maintenance overhead && more bytes you're shipping to users' browsers, so it's something to think about.

ARIA Attributes

While native HTML elements, when used correctly, often don't require additional ARIA attributes, always be on the lookout for scenarios where they might enhance accessibility. For instance, if you have a group of radio buttons, the group could be wrapped in a fieldset with a legend describing the set.

Testing

Of course, it's always best to test your designs with real users, including those who rely on assistive technologies. Manual testing, while time-consuming, often surfaces issues automated tools might miss.

Parting words

Modern CSS offers a cleaner, more streamlined approach to customizing radio buttons without the need for extra HTML or convoluted CSS. Embracing these techniques allows for efficient, maintainable, and user-friendly designs.

Always think about WHY you want to create a custom radio button in the first place. If the reason is to offer a better experience to users, then be sure to think about ALL users; think about accessibility. By focusing on accessibility from the outset, designers and developers can ensure a more inclusive web experience for all users, regardless of their abilities or how they access content.

使用React Content Font提高字体加载效率

Adam Butterfield — Wed, 19 Jul 2023 15:31:23 +0000

Language:

在网络性能方面，每个千字节都至关重要。开发者不断努力使应用程序更高效，无论用户的网络速度如何，都能确保顺畅的用户体验。这在开发日语或中文等拥有大量字符集的应用程序时尤为重要。在这些情况下，如何有效使用字体可能会成为主要的关注点，因为字体的大小通常非常大。

其中一个挑战是处理像日语这样需要大字体文件的语言。例如，单一的Noto Sans日语字体重量达到惊人的5.7 MB。让用户下载这样大的文件并不理想，更不用说如果你需要更多的字体重量。

React Content Font，一种专门为解决这个问题而开发的包，就此登场。

什么是React Content Font?

React Content Font是一个为React应用程序设计的包。它通过检查网页，获取页面上的独特字符列表，然后请求Google Fonts中仅包含这些字符的字体。这个过程使用了优化的请求，确保只加载所需的字符，最大限度地减少了用户需要下载的数据。

使用此包非常简便，只需在应用程序的高层添加上下文提供者即可。简单地提供你想要的字体的fontName属性，它将默认请求一个普通的（即400）重量的字体。

例如，如果你有一个使用 App Router 的 Next.js应用，你可以像这样更新你的 app/layout.tsx文件：

import FontProvider from 'react-content-font';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="jp">
      <body>
        <FontProvider fontName="Noto Sans JP">{children}</FontProvider>
      </body>
    </html>
  );
}

如果你需要多于一个字体重量，甚至是一些重量的斜体版本，React Content Font通过fontWeights属性为你提供了支持。

import FontProvider from 'react-content-font';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="jp">
      <body>
        <FontProvider fontName="Noto Sans JP" fontWeights={[400, 600]}>
          {children}
        </FontProvider>
      </body>
    </html>
  );
}

满足多样的字体需求

你可能会想知道是否有任何日语字体带有斜体变体。虽然这不常见，但也许你想使用的字体确实具有这个特性。React Content Font允许你请求你想要的任何重量的斜体变体。

import FontProvider from 'react-content-font';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="jp">
      <body>
        <FontProvider
          fontName="Noto Sans JP"
          fontWeights={[400, 600, ['ital', 400], ['ital', 900]]}
        >
          {children}
        </FontProvider>
      </body>
    </html>
  );
}

此外，该包还允许你指定font-display属性。这个属性定义了字体文件如何被浏览器加载和渲染，这直接影响到性能的感知。

import FontProvider from 'react-content-font';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="jp">
      <body>
        <FontProvider fontName="Noto Sans JP" display="block">
          {children}
        </FontProvider>
      </body>
    </html>
  );
}

检查字体加载状态

在某些情况下，你可能希望在显示内容之前等待字体加载，或者显示一个加载状态。React Content Font提供了一个可以标记字体加载状态的hook。这个特性允许你根据字体的加载状态控制内容的可见性。

'use client';

import { useFontContext } from 'react-content-font';

export default function PageText() {
  const { isFontLoaded } = useFontContext();

  return (
    <p style={{ visibility: isFontLoaded ? 'visible' : 'hidden' }}>
      よそはほかまあこの威圧心というのの後をしないう。きっと場合で仕事帰りはひょろひょろその評でたなりでするが行くたをも表裏できなけれでば、なぜにはもっなないうた。個人にできたのはついに十月から向後ますだない。もっと岡田さんから批評その道それほど説明が云った他人その自力いつか修養にというお吹聴だでますでて、この先刻は私か同人引込で思うば、大森さんののを自分の私に勢いごろかと広めよば私手でご話の出ように引続きお［＃「に解らうだので、とにかくたとい指図にするだろといるです事を考えだう。
    </p>
  );
}

然而，关键的是要渲染文本，这样字符才能被发现并包含在请求的字体中。

检测字体更新

React Content Font也允许你知道字体是否正在更新，为你的应用程序的用户体验提供了另一层控制。

'use client';

import { useFontContext } from 'react-content-font';

export default function PageText() {
  const { isFontLoaded } = useFontContext();

  return (
    <>
      {isFontLoaded && (
        <p>
          よそはほかまあこの威圧心というのの後をしないう。きっと場合で仕事帰りはひょろひょろその評でたなりでするが行くたをも表裏できなけれでば、なぜにはもっなないうた。個人にできたのはついに十月から向後ますだない。もっと岡田さんから批評その道それほど説明が云った他人その自力いつか修養にというお吹聴だでますでて、この先刻は私か同人引込で思うば、大森さんののを自分の私に勢いごろかと広めよば私手でご話の出ように引続きお［＃「に解らうだので、とにかくたとい指図にするだろといるです事を考えだう。
        </p>
      )}
    </>
  )
}

再次强调，就像检查加载状态一样，你必须渲染文本，这样字符才能被发现并包含在请求的字体中。

让我知道你的想法！

作为React Content Font背后的唯一开发者，我发现这个旅程充满挑战，但也很有回报。这是我为自己建立的东西，但我很确定其他人也会想要使用它。

你在你的项目中发现这个包有用吗？你是否看到任何可以改进的地方？或者，你有没有一些创新的想法用于未来的增强？我很愿意听到你的想法！

React Content Fontでフォントの読み込みを効率化する

Adam Butterfield — Wed, 19 Jul 2023 15:21:40 +0000

Language:

ウェブパフォーマンスにおいて、各キロバイトが重要です。開発者はユーザーのインターネット速度に関わらず、スムーズな体験を提供するために、アプリケーションを効率的にすることを常に目指しています。特に、日本語や中国語のような広範な文字セットを持つ言語のアプリケーションを開発する際には、通常大きなサイズのフォントを効率的に使用することが大きな関心事となります。

例えば、日本語の「Noto Sans Japanese」の単一のフォントウェイトだけでもファイルサイズは驚くべき5.7MBにもなります。このような大きなファイルをユーザーにダウンロードさせるのは理想的ではありません、さらに複数のフォントウェイトが必要な場合はなおさらです。ここで登場するのが、この問題に特化して開発されたパッケージ、React Content Fontです。

React Content Fontとは何か？

React Content FontはReactアプリケーション用に設計されたパッケージで、ウェブページをチェックしてそのページに含まれるユニークな文字のリストを取得し、その文字だけを含むフォントをGoogle Fontsからリクエストします。このプロセスは最適化されたリクエストを使用するため、必要な文字だけがロードされ、ユーザーがダウンロードする必要のあるデータを最小限に抑えます。

このパッケージは使いやすく、アプリケーションの高い位置にコンテクストプロバイダを追加するだけです。fontName propで欲しいフォントを指定すれば、デフォルトで正常な（つまり400の）ウェイトのフォントをリクエストします。

例えば、App Routerを使用したNext.jsアプリがある場合、app/layout.tsxファイルを以下のように更新できます：

import FontProvider from 'react-content-font';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="jp">
      <body>
        <FontProvider fontName="Noto Sans JP">{children}</FontProvider>
      </body>
    </html>
  );
}

複数のフォントウェイトが必要な場合、または一部のウェイトのイタリックバージョンが必要な場合でも、React Content FontのfontWeights propで対応可能です。

import FontProvider from 'react-content-font';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="jp">
      <body>
        <FontProvider fontName="Noto Sans JP" fontWeights={[400, 600]}>
          {children}
        </FontProvider>
      </body>
    </html>
  );
}

さまざまなフォントニーズに対応

さらに、あなたがイタリックバリアントを持つ日本語のフォントを探しているかもしれません。それはあまり一般的ではありませんが、使用したいフォントにはその機能があるかもしれません。React Content Fontでは、どのウェイトでもイタリックバリアントをリクエストすることができます。

import FontProvider from 'react-content-font';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="jp">
      <body>
        <FontProvider
          fontName="Noto Sans JP"
          fontWeights={[400, 600, ['ital', 400], ['ital', 900]]}
        >
          {children}
        </FontProvider>
      </body>
    </html>
  );
}

また、このパッケージではfont-displayプロパティを指定することが可能です。このプロパティはフォントファイルのロードと表示方法を定義し、直接パフォーマンスを影響を与えます。

import FontProvider from 'react-content-font';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="jp">
      <body>
        <FontProvider fontName="Noto Sans JP" display="block">
          {children}
        </FontProvider>
      </body>
    </html>
  );
}

フォントのロード状態の確認

場合によっては、コンテンツを表示する前にフォントのロードを待ちたい場合や、ローディング状態を表示したい場合があります。React Content Fontはフォントのロード状態をフラグするフックを提供します。この機能により、フォントのロード状態に基づいてコンテンツの可視性を制御することができます。

'use client';

import { useFontContext } from 'react-content-font';

export default function PageText() {
  const { isFontLoaded } = useFontContext();

  return (
    <p style={{ visibility: isFontLoaded ? 'visible' : 'hidden' }}>
      よそはほかまあこの威圧心というのの後をしないう。きっと場合で仕事帰りはひょろひょろその評でたなりでするが行くたをも表裏できなけれでば、なぜにはもっなないうた。個人にできたのはついに十月から向後ますだない。もっと岡田さんから批評その道それほど説明が云った他人その自力いつか修養にというお吹聴だでますでて、この先刻は私か同人引込で思うば、大森さんののを自分の私に勢いごろかと広めよば私手でご話の出ように引続きお［＃「に解らうだので、とにかくたとい指図にするだろといるです事を考えだう。
    </p>
  );
}

ただし、リクエストされたフォントに文字が含まれるように、テキストをレンダリングすることが重要です。

フォントの更新の検出

React Content Fontはまた、フォントが更新されているかどうかを知ることを可能にします。これにより、アプリケーションのUXにさらなる制御を提供します。

'use client';

import { useFontContext } from 'react-content-font';

export default function PageText() {
  const { isFontLoaded } = useFontContext();

  return (
    <>
      {isFontLoaded && (
        <p>
          よそはほかまあこの威圧心というのの後をしないう。きっと場合で仕事帰りはひょろひょろその評でたなりでするが行くたをも表裏できなけれでば、なぜにはもっなないうた。個人にできたのはついに十月から向後ますだない。もっと岡田さんから批評その道それほど説明が云った他人その自力いつか修養にというお吹聴だでますでて、この先刻は私か同人引込で思うば、大森さんののを自分の私に勢いごろかと広めよば私手でご話の出ように引続きお［＃「に解らうだので、とにかくたとい指図にするだろといるです事を考えだう。
        </p>
      )}
    </>
  )
}

こちらもロード状態の確認と同様に、文字がリクエストされたフォントに含まれるようにテキストをレンダリングする必要があります。

あなたの意見を教えてください！

React Content Fontの開発者として、この旅は挑戦的でありながらも報われる経験でした。自分自身のために作ったものですが、他の人々もこれを使いたいと思うことでしょう。

あなたのプロジェクトでこのパッケージは役立ちましたか？改善できる箇所はありますか？あるいは、将来の拡張のための創造的なアイデアがありますか？あなたの意見を聞きたいです！

Making Font Loading More Efficient with React Content Font

Adam Butterfield — Wed, 19 Jul 2023 15:21:01 +0000

Language:

When it comes to web performance, every kilobyte matters. Developers continuously strive to make applications more efficient, ensuring a smooth experience for users, regardless of their internet speed. This is particularly true when developing applications in languages with vast character sets such as Japanese or Chinese. Ensuring efficient use of fonts in these scenarios can be a major concern due to the typically large size of the fonts.

One of the challenges is dealing with languages like Japanese that require large font files. For example, a single font weight for Noto Sans Japanese is a whopping 5.7 MB. It's not ideal to have your users download such a big file, not to mention if you need more than one font weight.

Enter React Content Font, a package developed specifically to tackle this issue.

What is React Content Font?

React Content Font is a package designed for React applications. It works by checking a webpage, getting a list of unique characters on that page, and then requesting a font from Google Fonts with only those characters included. This process uses an optimized request, ensuring that only the required characters are loaded, minimizing the data your users need to download.

The package is easy to use, as simple as adding the context provider high up in your application. Simply provide the font you want with the fontName prop, and it will by default request a normal (meaning 400) weight font.

For example, if you have a Next.js app using App Router, you can update your app/layout.tsx like this:

import FontProvider from 'react-content-font';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="jp">
      <body>
        <FontProvider fontName="Noto Sans JP">{children}</FontProvider>
      </body>
    </html>
  );
}

If you need more than one font weight, React Content Font got you covered with the fontWeights prop.

import FontProvider from 'react-content-font';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="jp">
      <body>
        <FontProvider fontName="Noto Sans JP" fontWeights={[400, 600]}>
          {children}
        </FontProvider>
      </body>
    </html>
  );
}

Meeting Diverse Font Needs

You may wonder if there are any Japanese fonts with italic variants. While it's uncommon, maybe the font you want to use does have this feature. React Content Font allows you to request italic variants for whatever weight you desire.

import FontProvider from 'react-content-font';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="jp">
      <body>
        <FontProvider
          fontName="Noto Sans JP"
          fontWeights={[400, 600, ['ital', 400], ['ital', 900]]}
        >
          {children}
        </FontProvider>
      </body>
    </html>
  );
}

Moreover, the package allows you to specify the font-display property. This property defines how font files are loaded and rendered by the browser, which directly impacts the perceived performance.

import FontProvider from 'react-content-font';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="jp">
      <body>
        <FontProvider fontName="Noto Sans JP" display="block">
          {children}
        </FontProvider>
      </body>
    </html>
  );
}

Checking Font Load State

In some cases, you might want to wait for the font to load before showing content, or display a loading state. React Content Font provides a hook that flags the load state of the font. This feature allows you to control the visibility of your content based on the font's load state.

'use client';

import { useFontContext } from 'react-content-font';

export default function PageText() {
  const { isFontLoaded } = useFontContext();

  return (
    <p style={{ visibility: isFontLoaded ? 'visible' : 'hidden' }}>
      よそはほかまあこの威圧心というのの後をしないう。きっと場合で仕事帰りはひょろひょろその評でたなりでするが行くたをも表裏できなけれでば、なぜにはもっなないうた。個人にできたのはついに十月から向後ますだない。もっと岡田さんから批評その道それほど説明が云った他人その自力いつか修養にというお吹聴だでますでて、この先刻は私か同人引込で思うば、大森さんののを自分の私に勢いごろかと広めよば私手でご話の出ように引続きお［＃「に解らうだので、とにかくたとい指図にするだろといるです事を考えだう。
    </p>
  );
}

It's crucial, however, to render the text so the characters can be discovered and included in the requested font.

Detecting Font Updates

React Content Font also allows you to know if the font is being updated, offering another layer of control over your application's UX.

'use client';

import { useFontContext } from 'react-content-font';

export default function PageText() {
  const { isFontLoaded } = useFontContext();

  return (
    <>
      {isFontLoaded && (
        <p>
          よそはほかまあこの威圧心というのの後をしないう。きっと場合で仕事帰りはひょろひょろその評でたなりでするが行くたをも表裏できなけれでば、なぜにはもっなないうた。個人にできたのはついに十月から向後ますだない。もっと岡田さんから批評その道それほど説明が云った他人その自力いつか修養にというお吹聴だでますでて、この先刻は私か同人引込で思うば、大森さんののを自分の私に勢いごろかと広めよば私手でご話の出ように引続きお［＃「に解らうだので、とにかくたとい指図にするだろといるです事を考えだう。
        </p>
      )}
    </>
  )
}

Again, just like with checking the load state, you must render the text for the characters to be discovered and included in the requested font.

Let me know what you think!

As the sole developer behind React Content Font, I've found the journey challenging yet rewarding. It's something I built for myself, but I'm pretty sure other people will want to use it too.

Have you found this package useful in your projects? Do you see any areas where it can be improved? Or perhaps, you have some creative ideas for future enhancements? I'd love to hear your thoughts!