令和時代の CSS 記法再考

昔は CSS と言えば壊れやすい代名詞のようなもので、堅牢な CSS を書くためによく BEM や FLOCSS といったCSS 設計記法の縛りを入れて書いたりしていましたが、最近は React と Scoped CSS のセットで書くことが多くて、素の HTML/CSS で設計記法を遵守した CSS を書く機会はだいぶ減りました。

衝突を気にしなくて良い環境で CSS を書いているので BEM (Block/Element/Modifier) で言うところの Element あたりはあまり気にならなくなりましたが、Modifier の扱いに関しては引き続き現役というか、むしろコンポーネントの Props などでより意識をする機会が多くなったように感じます。

ちなみに 自分は CSS in JS に関しては若干距離を置いてるというか、Scoped CSS が実現できれば十分で、ユーザーに負担を負わせないという意味でゼロバンドルである CSS Modules や vanilla-extract を主に好んで使っています。

これから紹介する記法は比較的 バニラ寄りの CSS を書く際に使えるテクニックですので、CSS Modules な人も、Vue.js な人も、BEM や FLOCSS が現役な人にも使えるものとなっています。逆に styled-components のようなガチガチの CSS in JS を使ってる人にはあまり刺さらない内容かもしれません。

BEM で言うところの Modifier の書き方を見直す

さて、今まで Modifier を HTML/CSS で表現するとこんな感じになると思います。

HTML

<button
  type="button"
  class="button button--primay button--is-pressed"
>
  ボタン
<button>

CSS

.button {
  color: #333;
  background-color: #f0f0f0;
  border: #999 1px solid;
  padding: .4em;

  &--primay {
    background-color: #fcc;
  }

  &--is-pressed {
    box-shadow: 2px 2px 4px #999 inset;
  }
}

これを自分は、

1. 極力 WAI-ARIA 属性で表現する
2. WAI-ARIA で表現できないものはカスタムデータ属性で表現する

といった書き方を推奨しています。

HTML

<button
  type="button"
  class="button"
  data-level="primary"
  aria-pressed="true"
>
  ボタン
<button>

CSS

.button {
  color: #333;
  background-color: #f0f0f0;
  border: #999 1px solid;
  padding: .4em;

  &[data-level="primay"] {
    background-color: #fcc;
  }

  &[aria-pressed="true"] {
    box-shadow: 2px 2px 4px #999 inset;
  }
}

ただそれだけなんですが、こちらのほうが従来の BEM 的な書き方よりも優れている点がいくつかあります。

メリット1: HTML/CSS の見通しが良くなる

従来の方法だと スタイリングがすべて class 属性に集約されるため、Modifier が多いと HTML がとても読みにくくなりますが、この方式は Modifier が属性ごとに分割されているため、よりリーダブルなコードになります。

CSS も属性セレクタで定義されているものが Modifier であることが明示的になります。
CSS 詳細度は BEM と比べて上がりますが、このルールで統一されている以上はそれほど問題になることはないので受容としています。

また、React の JSX では従来の記法では clsx などを使って以下のように className を合成しますが、

JSX

function Button({ level, isPressed }) {
 return (
   <button
     type="button"
     className={clsx(style.button, level, { 'is-pressed' : isPressed })]
   >
     ボタン
   <button>
 )
}

推奨記法では Props と属性が対となるので受け渡しも容易、コードも宣言的で読みやすいです。
もちろん className 合成のためのパッケージも不要です。

JSX

function Button({ type, isPressed }) {
 return (
   <button
     type="button"
     className={style.button}
     data-level={level}
     aria-pressed={isPressed}
   >
     ボタン
   <button>
 )
}

メリット2: アクセシビリティが向上する

WAI-ARIA には要素の状態を示す様々な属性があります。

https://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/Attributes

表示/非表示を示す aria-hidden、UI の選択状態を示す aria-selected, aria-checked, aria-pressed、開閉状態を示す aria-expanded、現在地を示す aria-current、読み込み中を示す aria-busy など。

これらの状態は class で表現するよりも WAI-ARIA 属性を使った方が、コンポーネントの状態を正しく伝えることができるためアクセシビリティが向上します。また、属性セレクタを使えば WAI-ARIA 属性も CSS から参照できます。

React では状態と WAI-ARIA 属性を紐づけることで HTML/CSS/JavaScript すべての参照を WAI-ARIA 属性に集約できるため、より効率的にコンポーネントを管理できます。

さらに、昨今のフロントエンドではテストを書く機会が多くなったと思いますが、ユニットテストで使われる Testing Library や E2E テストで使われる Playwright でも getByRole のオプションでは WAI-ARIA 属性を検索条件に加える事ができます。

https://testing-library.com/docs/queries/byrole
https://playwright.dev/docs/api/class-framelocator#frame-locator-get-by-role

そのため、積極的に WAI-ARIA 属性を利用することでテスタビリティも向上します。

コメントで指摘がありましたので追記しておきます。
積極的に WAI-ARIA 属性を使うと記載しましたが、MDN の注記にもあるように、要素が本来持っている属性と WAI-ARIA 属性が重複しているときは要素の属性を優先して利用するようにしましょう。

以上の理由から、ユーザーにとっても開発者にとってもメリットが大きいので自分はこの記述方法を推奨しています。

ダイナミックスタイリングの書き方を見直す

コンポーネントの中には静的な CSS だけでは表現できないケースがあります。
例えばダイアログやポップアップ、ツールチップのようなレイヤーを重ねて表示するものは、JavaScript で動的に計算した座標を出力する必要があります。
その場合、今までは style 属性でプロパティを直接記述して座標をコントロールしていました。

HTML

<div
  class="tooltip"
  aria-hidden="false"
  style="top: 120px; left: 40px"
>…中略…</div>

CSS

.tooltip {
  position: absolute;
}

これでも動作としては問題はないんですが、より良い書き方として、直接 style 属性にスタイルを書かずに CSS カスタムプロパティを使って以下のように書き直しています。

HTML

<div
  class="tooltip"
  aria-hidden="false"
  style="--top: 120px; --left: 40px"
>…中略…</div>

CSS

.tooltip {
  --top: 0;
  --left: 0;
  position: absolute;
  top: var(--top);
  left: var(--left);
}

わざわざ CSS カスタムプロパティを経由するという冗長なことをしているように見えますが、これによってコード管理上のメリットがあります。

メリット1: CSS と style 属性の混在による詳細度の差異を緩和する

基本は CSS ファイルに書かれたプロパティよりも style 属性に書かれたプロパティの方が詳細度が高いため style 属性の定義が常に優先されます。そのため、通常 CSS ファイルに書かれたプロパティは style 属性に勝つことはできません。

今回の記述で CSS カスタムプロパティを経由することで style 属性勝ちのルールを覆すことができます。つまり、詳細度を CSS ファイルの中の定義だけで完結させることができます。

また、この CSS カスタムプロパティはコンポーネント単位にスコープが分かれているため、同じコンポーネントをたくさん HTML に記述しても、style 属性の CSS カスタムプロパティは自身以外のコンポーネントに影響を与えません。

メリット2: ダイナミックスタイリングの影響範囲を CSS ファイルの中で宣言的に定義できる

HTML 側から style 属性で CSS プロパティを上書きする従来の方法は、CSS ファイルの定義と HTML 側の style 属性の内容の両方を見て、合成される CSS プロパティを想像したり、ブラウザの computed style から情報を得る必要がありました。

これを CSS カスタムプロパティを経由することで、CSS ファイルは外から注入される CSS プロパティを予め定義しておく形になります。

CSS

.tooltip {
  /* 外部から挿入されるパラメータの宣言 */
  --top: 0; 
  --left: 0;

  /* スタイル本体 */
  position: absolute;
  top: var(--top);
  left: var(--left);
}

結果的に CSS ファイルを見るだけで、どのプロパティがダイナミックスタイリングの対象となるのかが一目瞭然になり、より宣言的でリーダブルな CSS になります。

メリット3: 疑似要素に対してもダイナミックスタイリングを適用できる（2024/05/03 追記）

style 属性からスタイルを指定する従来の方法では対象となる要素に直接スタイルを適用することになりますが、CSS カスタムプロパティを経由すると、その要素を起点とした子要素にまでその影響を与えることができます。
その要素が ::before, ::after のような疑似要素を内包している場合は、それも CSS カスタムプロパティのスコープに含まれるため、従来の style 属性では適用できなかった疑似要素に対しても動的なスタイルを適用することができます。

HTML

<button type="button" class="button" style="--icon: '★'">ボタン</button>

CSS

.button {
  /* 外部から挿入されるパラメータの宣言 */
  --icon: ""; 

  /* スタイル本体 */
  display: flex;
  align-items: center;
  text-align: left;
}

/* 疑似要素に対して CSS カスタムプロパティを適用する */
.button::before {
  content: var(--icon);
}

従来の style 属性によるダイナミックスタイリングでは疑似要素へのスタイル適用はできないので、完全な上位互換としてこの記法を利用することができます。

まとめ

• スタイルの定義を class に集約するよりも WAI-ARIA 属性とカスタムデータ属性を使った方が、よりリーダブルな HTML（JSX）になります
• WAI-ARIA 属性を積極的に使うことで、アクセシビリティとテスタビリティの向上を狙えます
• ダイナミックスタイリングは CSS のカスタムプロパティを使うことで CSS プロパティの定義を CSS ファイルに集約、詳細度の平準化とよりリーダブルな CSS を実現できます

CSS 記法というにはちょっと大げさかもしれませんが、一つの考え方としてアウトプットしておきます。CSS を書く上で何らかの参考になれば幸いです。