タグ: React

スマートフォンで自分の記事を読んでいて、気になることがありました。

画面の上に、ヘッダーと目次がずっと貼り付いたままです。どちらも便利なつもりで置いたものですが、読んでいるあいだは、ただ場所を取っています。

貼り付いたものは、面積を占め続ける

スマートフォンの画面の高さは、だいたい本文15〜20行ぶんです。そこにヘッダーが1行、目次のバーが1行居座ると、実際に読める範囲は1割ほど減ります。

減るだけならまだしも、目次のバーはいま読もうとしている行の上に半透明でかぶさります。スクロールしている最中がいちばん邪魔です。

3つの変更

1. ヘッダーは「量」ではなく「向き」で判断する

最初に考えたのは「300pxスクロールしたら隠す」でした。単純ですが、これだと読み進めるほど隠れっぱなしになります。メニューを開きたくなったとき、ページの先頭まで戻ることになります。

採用したのは、スクロールの向きで判断する方式です。

下へ読み進んでいる  → 隠す（読むのに要らない）
上へ戻し始めた      → 出す（何かしたいはず）
ページの先頭付近    → 必ず出す

上へのスクロールは、たいてい「前に戻りたい」「別の場所へ行きたい」という合図です。その動作を、ヘッダーを呼び出す操作として兼ねさせています。新しい操作を覚えてもらう必要がありません。

細かいが要る配慮が3つあった

ひとつめはわずかな揺れを無視すること。指の震えや慣性の揺り戻しで数px動くたびに出し入れすると、ヘッダーが点滅します。6px未満の移動は無視しています。

ふたつめは画面の端で引っ張ったとき。iPhoneでは画面の一番上でさらに引っ張ると、スクロール位置がマイナスになります。そのまま計算すると「上に動いた」と誤判定します。0で止めるようにしました。

みっつめはメニューを開いているあいだは隠さないこと。開いた本人の操作でヘッダーごと消えたら、何が起きたのか分かりません。

2. 目次は「消す」のではなく「薄くする」

目次も同じように隠す案がありました。やめました。

この目次のバーには読了の進捗も出しています。消すと、どこまで読んだかが分からなくなります。

開いているときは薄くしません。開いているのは読むためではなく選ぶためなので、そこで薄くすると目的の見出しを探せなくなります。

3. 2つの追従が、食い違った

ここで問題が出ました。

目次は「ヘッダーの高さ（56px）ぶん下」に貼り付く指定になっています。ヘッダーがそこにある前提です。

ところがヘッダーは引っ込むようになりました。すると——

画面の上端
   ↓
（56pxの空白）   ← ヘッダーが居たはずの場所
   ↓
目次のバー       ← 宙に浮いて見える

目次だけが、意味のない隙間を空けて浮きます。

状態を、渡さずに共有する

ヘッダーが隠れているかどうかを、目次に伝える必要があります。素直に考えると「上から順に受け渡す」ですが、この構成では間にあるページ全体を作り替えることになります。

選んだのは、ページ全体に1つの値を置く方法です。

ヘッダー: --header-offset = 3.5rem（表示中）/ 0rem（隠れている）
目次    : 貼り付く位置 = --header-offset

ヘッダーは自分の状態を書くだけ、目次はその値を見るだけです。お互いを直接知らないまま、位置だけが揃います。

あえてTailwindを使わなかった箇所

このサイトのスタイルはTailwind CSSで書いています。今回の位置指定も書けますが、1か所だけ普通のCSSにしました。

理由は、壊れ方です。Tailwindのクラス名を書き間違えると、CSSが生成されないだけで、ビルドは成功します。

4. 先頭へ戻るボタン

最後に、よくあるボタンを置きました。ここでも1つだけ気を付けた点があります。

薄くして消したボタンは、見えないのに押せます。透明度を0にしただけでは、そこにある扱いのままです。キーボードで操作している人には、見えない項目に順番が回ってきます。

見えないあいだは押せない・順番が回ってこない・読み上げられないの3つを揃えました。見た目と実体を一致させています。

あわせて、端末の「動きを減らす」設定を尊重しています。滑らかに移動するのが心地よい人ばかりではありません。

今回の学び

まず、常に出しておくものと、必要なときだけ出すものを分けること。便利だから常に出す、を積み重ねると、本文が読める面積だけが減っていきます。何のために画面を開いているのかに戻って決めるべきです。

次に、「隠す」の前に「薄くする」を検討すること。困っているのが重なりなら、濃さを変えるだけで解決することがあります。消してしまうと、その要素が持っていた別の役割まで一緒に失います。

そして、動かすものが増えたら、位置の前提を疑うこと。固定されている前提で書いた数値は、片方が動き出した瞬間に嘘になります。今回は「ヘッダーの高さ」がそれでした。

最後に、確かめにくい場所ほど、壊れたら気づく書き方を選ぶこと。同じ結果になる書き方が2つあるなら、間違えたときに黙って消えないほうを選ぶ価値があります。

スマホで目次を画面上部に貼り付けたい。

PCではすでに右側に追従表示していました。同じことをスマホでもやるだけ——のはずが、実際に置いてみると本文を読む場所が足りなくなりました。貼り付くものは、そこにある間ずっと画面を占め続けるからです。

PCとスマホで、余っているものが違う

PCの画面では、本文の横に十分な余白があります。だから目次は右側に置けます。本文の面積を1ピクセルも削らずに、常に見えている状態を作れます。

スマホには横の余白がありません。置けるのは本文の上か下だけです。そして上に貼り付ければ、その高さのぶん本文が押し出されます。

同じ「追従する目次」でも、払っている代償が違います。PCでの成功をそのまま持ち込むと、スマホでは負担のほうが大きくなる可能性があります。

最初の実装は、高すぎた

もともとスマホ版の目次には、進捗バーと「読了まで／あと35%」の表示が縦に積まれ、その下に「目次（8項目）」の開閉ボタンがありました。これをそのまま貼り付けると、こうなります。

ヘッダー        57px
目次バー        85px
────────────────────
合計           142px

iPhone SE の表示領域（667px）に対して 21%

2割が常時埋まります。しかもスマホでは、画面の下端もブラウザのUIに取られています。実際に本文が見えている範囲は、思っているより狭いのです。

縦に積むのをやめる

減らせるものを探しました。表示している情報は3つです。

どれも消せません。消せないなら、並べ方を変えます。縦に積んでいたものを横一列にしました。

［目次 ▸］ ──────────── あと 35%
           （進捗バー）

これで85pxが約40pxになりました。ヘッダーと合わせて約97px、本文が見える範囲は85%まで戻ります。情報は1つも減らしていません。

実装：同じ部品を2通りに並べる

進捗バーの部品には、並べ方を選べるようにしました。

layout?: "stacked" | "row";

// 表示する部品は3つだけ。並べ方が2通りあるので、
// 部品を変数に切り出してから並べ替える。
const finishedLabel  = ( ... );
const remainingLabel = ( ... );
const bar            = ( ... );

if (layout === "row") {
  return (
    <div className="flex items-center gap-2.5">
      <div className="min-w-0 flex-1">{bar}</div>
      {finished ? finishedLabel : remainingLabel}
    </div>
  );
}

ここで避けたかったのは、レイアウトごとに同じJSXを書き写すことです。書き写すと、表示内容を変えたときに片方だけ直し忘れます。部品を変数にしておけば、並べ替えても中身は1つのままです。

飛んだ先が、バーの裏に隠れる

実装して気づいた副作用です。

目次のリンクを押すと、その見出しまでスクロールします。ところが貼り付いたバーの裏に見出しが潜り込んで見えなくなりました。ブラウザは「見出しを画面の一番上に持ってくる」ことしかしないので、上に何かが被さっていることを知りません。

@media (max-width: 1023px) {
  .wp-content h2,
  .wp-content h3 {
    scroll-margin-top: 8.5rem;   /* ヘッダー + 目次バー + 余白 */
  }
}

scroll-margin-top は「スクロールで停止する位置を、この分だけ手前にずらす」指定です。PCには目次バーが無いので、幅の狭い画面だけに適用しています。1024pxという境目は、目次がサイドバーからバーに切り替わる位置に合わせました。

開いたときの高さも止める

もうひとつ。目次を開いたときの高さにも上限が要ります。

見出しが8個ある記事だと、開いた目次は約340pxありました。ヘッダーと合わせて約400px。667pxの画面では、飛び先を選んでいる間、本文がほとんど見えません。

max-h-[50vh] overflow-y-auto

画面の半分までに制限し、それを超える場合は目次の中だけをスクロールさせます。これで、どんなに見出しが多い記事でも本文が半分は見えたままになります。

記事が終われば、消える

最後にひとつ、意図してそうしている挙動があります。

この目次バーは記事本文のカードの中に置いてあります。position: sticky は親要素の範囲でしか効きません。だから記事本文が終わると、バーも一緒に流れて消えます。

画面の最上端に固定する方法もありましたが、そうすると読み終えた後の「前後の記事」や「一覧へ戻る」を見ているときにも居座り続けます。もう使わないものが場所を取り続けるのは、狭い画面では特に邪魔です。

今回の学び

まず、PCでうまくいった置き方が、スマホでも良いとは限らないこと。PCの追従目次は本文の面積を削りませんが、スマホでは削ります。同じ機能でも、払う代償が違います。

次に、消す前に並べ替えを試すこと。場所が足りないときに情報を削ると、機能が減ります。縦を横にするだけで、失わずに半分の高さに収まりました。

そして、動作の正しさと体験の正しさは別だということ。目次リンクのスクロールは仕様どおり動いていましたが、使う側には「反応しない」と見えていました。正しく動いているかだけを確認していると、この種の問題は見つかりません。

最後に、貼り付くものには終わりを決めておくこと。ずっと画面にあるものは、必要な間だけあればいい。記事の中でだけ生きて、読み終えたら消える——親要素の範囲で自然にそうなる形を選びました。