カテゴリー: 技術系

フッターの上の角を丸めています。ページの下に別の面が敷かれている、という見え方を作るためです。

ところが、実機で見返すと「もう少し丸くていい、50pxでもいいくらい」と感じました。当時は14pxでした。

丸みは1つの表で持っている

このサイトでは、角の丸さを6段階の表で持っています。既定値より意識的に小さくしてあります。

表で持っている理由は、調整を1か所で終わらせるためです。「全体的にもう少し角を立てたい」と思ったとき、この表の数字を書き換えれば、丸みを指定しているすべての場所が同じ方向へ動きます。個別に書いていたら、直し漏れた場所だけが取り残されます。

一番大きい値を50pxにすればいい、ではなかった

最初に考えたのは、表の一番大きい値を50pxにすることでした。フッターはその値を使っているので、これで目的は果たせます。

しかもこの値は、調べたらサイト全体でフッター1か所しか使っていませんでした。他に影響が出ないので、書き換えても壊れません。

それでもやめました。

比べる相手が違うものは、同じ表に置けない

考え直して分かったのは、この表が何のためにあるかでした。

DEFAULTから一番大きい値までは、1本の段階になっています。小さいものから大きいものへ並んでいて、ボタン、入力欄、タグ、カードのように本文の中に置かれる部品のためにあります。

これらの部品には共通点があります。画面の中で隣り合って並ぶので、互いの丸みを見比べられるということです。ボタンよりカードのほうが少し丸い、という関係が意味を持ちます。だから同じ段階の上に居る必要があります。

フッターは違います。幅が画面いっぱいあり、隣に並ぶものがありません。比べる相手は画面の縁だけです。

なぜ14pxでは足りなかったのか

数字の話も書いておきます。

同じ半径でも、対象が横に広いほど、角の丸みは相対的に小さく見えます。幅300pxのカードの14pxと、幅1200pxのフッターの14pxでは、目に入る割合が違います。

フッターの角を丸めているのは、そこに背景がわずかに覗いて「下に別の面が重なっている」と伝えるためです。角が丸いことに気づけない大きさでは、その役割を果たしません。14pxは、部品としては十分でも、面としては足りませんでした。

今回の学び

まず、壊れないことは、変えてよい理由にはならないこと。使っている場所が1か所しかなければ、書き換えても何も起きません。ただし表の意味は変わっていて、次にその表を使う人が想定外の値を受け取ります。影響が出るのが今日でないだけです。

次に、同じ言葉で呼んでいるものが、同じ決め方とは限らないこと。部品の丸みは隣と比べて決まり、面の丸みはそれ単体で伝わるかで決まります。決め方が違うものを1本の段階に押し込むと、どちらかが無理をすることになります。

そして、例外は、例外だと分かる場所に置くこと。段階の中に極端な値を混ぜると、段階のほうが読めなくなります。外へ出して名前を付ければ、なぜそこにあるのかを書き残せます。書き残せる形にすること自体が、判断を残す手段になります。

ダークモードを入れました。色を反転させるだけの作業だと思っていたのですが、最後に厄介なものが残りました。

ページを開いた瞬間、一瞬だけ白くなる。そのあと黒に切り替わる。暗い部屋で見ると、はっきり目に刺さります。

まず、切り替えを何状態にするか

最初は「ライト／ダーク」の2つで作りかけました。書いている途中で手が止まりました。

OSにも同じ設定があります。夜になると自動で暗くなる設定を使っている人は、サイト側で固定されると、その設定が効かなくなります。

そこで3状態にしました。

初期値を「システムに合わせる」にしたのは、何も選んでいない人の意思表示は、すでにOS側にあるからです。サイトが勝手に上書きするものではありません。

一瞬だけ白くなる、の正体

ここが今回の本題です。

このサイトのページは、あらかじめ組み立てたHTMLを配っています。速いのですが、組み立てた時点では、見る人がどちらを選んでいるか分かりません。

選択はブラウザに保存されています。サーバーはそれを読めません。だから最初に届くHTMLは、必ずどちらかの配色で塗られた状態で届きます。

そのあとJavaScriptが動いて、保存された選択を読み、色を切り替える。この「そのあと」が見えてしまうのが、白い一瞬の正体でした。

解決は、順番を変えること

JavaScriptを速くしても解決しません。画面が描かれる前に決めるしかありません。

やったのは、HTMLの先頭に小さなスクリプトを1つ置くことです。ページの本体が描かれる前にブラウザがそこを読み、保存された選択（無ければOSの設定）を見て、いちばん外側の要素に印を付けます。

そのあとにCSSが適用されるので、最初から正しい色で描かれます。切り替わる瞬間そのものが無くなります。

ついでに、スクロールバーも合わせた

色を切り替えたあとも、スクロールバーやフォームの部品が明るいままでした。これらはブラウザが描いていて、サイトのCSSでは届きません。

ブラウザに「このページは暗い配色です」と伝える指定が別にあります。それを一緒に切り替えることで、部品の側も揃いました。

色を1つずつ直すのは、やめた

ここも判断が要りました。

画面の色は「白い背景」「濃いグレーの文字」のように、部品ごとに書いてあります。素直にやるなら、その1つずつに「暗いときはこの色」を書き足していきます。

数えてみると、色の指定は24個のファイルに散らばっていました。

色に名前を付けて、名前のほうを差し替えた

やり方を変えました。「白」や「濃いグレー」という色そのものではなく、その名前が指す中身を入れ替えることにしました。

部品側の書き方は一文字も変えていません。「白い背景」と書いてある場所はそのままで、「白」が何色を指すかを、明るいときと暗いときで切り替えます。

結果として、直した場所は色の定義1か所だけになりました。次に微調整したくなったときも、探すのはそこだけです。

記事の本文も、同じ仕組みで済んだ

記事の本文はCMSから来ます。見出しも段落も表も、こちらで書いたHTMLではありません。記事を書くたびに手で色を入れる運用は続きません。

ここは幸い、作ったときから色に名前を付けてありました。「本文の文字色」「罫線の色」「引用の背景」といった名前で書いてあったので、中身を差し替えるだけで済みました。当時そうしておいた理由は「あとで調整しやすいから」程度でしたが、今回はそれがそのまま効きました。

ただし、例外が2か所あった

この方法には穴があります。もともと背景が濃い場所です。

フッターとトップの見出し部分は、明るいときでも背景が濃紺です。そこに置いてある白い文字まで一緒に反転させると、濃紺の上に濃い色の文字になって読めなくなります。

この2か所だけは、名前を使わずに色を直接書きました。仕組みで揃えられる範囲と、そうでない範囲を分けた形です。

色を反転させただけでは、読めなかった

中身を入れ替えるとき、白と黒をそのまま逆にするとまぶしすぎます。

暗い背景に純白の文字を置くと、文字のふちがにじんで見えます。背景も純黒だとコントラストが強すぎて長く読めません。実際に暗い部屋で読んでみて、背景を少し明るく、文字を少し暗い白に寄せました。

逆に、薄いグレーの文字はダークモードで読めなくなります。明るいときに「補足だから薄く」としていた箇所が、暗い背景では沈んで消えます。補足の文字は、暗いとき用に明るさを上げ直しました。

やらなかったこと

画像を暗くすること。ダークモードで画像の明るさを落とす手はありますが、記事のアイキャッチはもともと暗い配色で作ってあるので、これ以上落とすと沈みます。

切り替えにアニメーションを付けること。色がなめらかに変わるのは気持ちよさそうですが、切り替えは一瞬で終わるべきものです。演出を挟むと、ちらつきを消すためにやった作業と矛盾します。

今回の学び

まず、設定は上書きより追従を初期値にすること。OSに同じ設定がある以上、何も選んでいない状態はすでに意思表示です。サイトが先に決めてしまうと、その意思が消えます。

次に、ちらつきは速さの問題ではなく順番の問題だということ。処理を速くしても、順番が後ろにある限り見えてしまいます。速くする前に、どの順で決まるかを見る必要がありました。

そして、原則には、それが守ろうとしているものがあること。「描画を止めるスクリプトを置かない」は、見え方を良くするための原則です。その原則を守ることで見え方が悪くなるなら、優先すべきは原則のほうではありません。

あわせて、散らばったものを1つずつ直さないこと。24か所に手を入れる作業は、終わったかどうかを自分で確かめられません。名前を1つ挟んで、そこだけを差し替える形に持っていけるなら、その手間のほうが安く済みます。

最後に、反転は変換ではないこと。明るい配色で作った濃淡は、暗い配色では意味が変わります。片方から機械的に作れるものだと思っていたのが、今回いちばんの見込み違いでした。