共通CSSを入れて分かったのは「揃っていない場所」と、間違いも共通化されるという事実

ページごとに色を書いていたサイトの配色を、1つのファイルに集約しました。揃えるための作業のつもりでしたが、実際に得たのは「揃っていない場所が見えるようになったこと」でした。そして同じ週に、共通CSSの1行の間違いが22のツールで同時にチェックボックスを壊しました。1年運用して、得たものと背負ったものが両方はっきりしたので書きます。

やったこと: 色だけを1ファイルに出す

それまで各ページは、自分の中に色を直接書いていました。同じ「本文の色」でもページによって微妙に違い、しかも作った時期によって系統ごと違いました。オレンジ寄りの時期と、青寄りの時期があったのです。

集約にあたって決めたのは、レイアウトには手を出さないことでした。共通化すべきものを増やすほど、既存ページと衝突する危険が増えます。色だけなら影響範囲がはっきりしています。

/* 共通ファイル側 */
:root { --ks-accent: #267b7d; --ks-bg: #f6f4ec; }

/* 各ページ側。自分の変数名から共通のものを参照する */
:root {
  --accent: var(--ks-accent, #267b7d);
  --bg:     var(--ks-bg, #f6f4ec);
}

第2引数はフォールバックです。共通ファイルの読み込みに失敗しても、表示は壊れません。ページ側のコードは変数名がそのまま使えるので、本文のCSSは1行も書き換えずに済みました。

得たもの: 揃っていない場所が「浮いて」見える

これが予想外の効果でした。ばらばらの色が並んでいるときは、どれも同じくらい馴染んで見えます。ところが地の色が揃った瞬間、揃っていないものだけが浮き上がって見えます。

集約の作業中に、意図していなかった残骸が次々に出てきました。

前の配色時代のオレンジ系の色が、透明度付きの指定の中に埋まっていた
青みがかった薄いグレーが、枠線やホバーの色として複数ページに残っていた
ページごとにまったく違う濃さの文字色が使われていた

どれも共通化する前から存在していた不揃いです。見えていなかっただけで、新しく壊れたわけではありません。共通化がしたのは、色を直すことではなく、直すべき場所に印を付けることでした。

この記事を書くために現状を確認したところ、当時「一掃した」と記録していた青みの色が、5つのツールページにまだ残っていました。共通CSS側は直っていたのに、ページ内に直接書かれたぶんが掃き残されていたのです。気づいた時点で置き換えました。共通化は網であって、網の外は自動では直りません。

背負ったもの: 1行の間違いが22ページで同時に起きる

同じ週に、逆側の性質も味わいました。共通CSSにこういう指定があったのです。

input { width: 100%; }

入力欄を横幅いっぱいにするための、ごく普通の指定です。ところがinputにはチェックボックスとラジオボタンも含まれます。結果として四角い枠が横幅いっぱいに引き伸ばされ、中のチェックの絵柄だけが中央にぽつんと浮いて、ラベルの文字から離れて表示されていました。

これが共通CSSを読んでいる22のツールすべてで同時に起きていました。1ページずつ色を書いていた時代なら、こんな壊れ方はしません。せいぜい1ページです。

直し方自体は単純でした。

/* チェック/ラジオは width:100% の対象外にする */
input[type=checkbox], input[type=radio] {
  width: auto;
  inline-size: 16px;
  block-size: 16px;
  accent-color: var(--accent);
}

/* チェックを含むラベルは「□ テキスト」の横並びに戻す */
label:has(> input[type=checkbox]) { display: flex; align-items: center; }

直すのも1箇所で22ページに効きます。壊れるのも一斉、直るのも一斉。これが共通化の本質だと理解しました。

2つの性質は同じものの裏表だった

整理するとこうなります。

共通化する前: 間違いはそのページだけで起きる。ただし、不揃いも見えない
共通化した後: 不揃いが見えるようになる。ただし、間違いは全ページで同時に起きる

「共通化すると保守が楽になる」とよく言われますが、楽になるのは修正の手数であって、確認の手数ではありません。むしろ確認は重くなります。1ページ直したつもりでも、影響範囲は全ページだからです。

それでも共通化してよかったと思っています。理由は「見えない不揃い」のほうが、「一斉に壊れる危険」より始末が悪いからです。一斉に壊れれば、すぐ気づいて1箇所直せば終わります。見えない不揃いは、何年でも残ります。

あとから効いた設計判断

1年運用してみて、特に効いたのは次の3つでした。

1. 色だけを共通化して、レイアウトは触らなかった

共通化の範囲を広げるほど、影響も広がります。チェックボックスの件は「色以外にも手を出していた部分」で起きました。範囲を絞っていたおかげで、被害がそこで止まっています。

2. フォールバック値を書いた

var(--ks-accent, #267b7d) の第2引数です。共通ファイルが読めなくても、ページは元の色で表示されます。共通化は単一障害点を作る作業でもあるので、ここは省かなくて正解でした。

3. ページ側の変数名を変えなかった

各ページが元から使っていた変数名をそのまま残し、その中身だけを共通のものに向けました。おかげでページ本文のCSSは1行も書き換えていません。大量の差分を出さずに済んだので、後から「何を変えたか」が追えます。

持ち帰れること

共通化の効果は「揃うこと」より「揃っていない場所が見えること」。作業を始めると、想定の何倍もの残骸が出てきます
間違いも共通化される。1行で全ページが壊れる代わりに、1行で全ページが直ります。修正の手数は減り、確認の手数は増えます
範囲を絞る。色だけ、間隔だけ、と決めておくと、事故もその範囲で止まります
フォールバック値を書く。共通ファイルは単一障害点になります
ページ側の名前は変えない。中身だけ差し替えれば、差分が小さく保てます
「一掃した」は、あとでもう一度数える。共通CSS側を直しても、ページ内に直接書かれたぶんは残ります

最後のひとつは、この記事を書くために確認して見つけたものです。1年前に「残存0を確認」と記録していたのに、実際には5ページ残っていました。そのときは共通CSS側だけを数えていて、ページ内の直書きを数えていなかったのだと思います。数えたつもりの範囲が、数えるべき範囲と一致していたかは、時間が経ってから分かります。