細かすぎて伝わらない Snow Monkey の地味なこだわり

「レイアウトが選べますよ」とか「ブロックエディターに対応しているので使いやすいですよ」とか、「開発者向けの API が整備されているので受託開発の現場でも使い勝手が良いですよ」とか、そういうキャッチーで明示しやすいものはアピールしやすいので人に Snow Monkey のことを紹介するときに良く使うのですが、めっちゃこだわっているけど細かすぎて人に紹介するにははばかられる…という地味なこだわりが実は結構あったりします。

ということで、そういうスポットがあたってこなかった部分について今日は書いてみたいと思います。

グローバルナビゲーションのタブ操作

web サイトを閲覧する方が必ずマウスを使っているとは限らないので、キーボードでも操作できるようにしておくほうが良いです。ほとんどの場合は普通につくれば普通にフォーカスが移動していくようにできますが、グローバルナビゲーションのようにサブメニューは通常隠れているけどフォーカスすると表示される、次のメニューに移動すると前のサブメニューが隠れる、のような「動作」が絡んでくる部分は特別に対応が必要になってきます。

Snow Monkey （というか Snow Monkey のベースとなっている CSS フレームワーク Basis）ではキーボード操作でも違和感がないように頑張りました。

これ、わりとできていないサイトが多いので、僕はグローバルナビゲーションがあるサイトを見かけたらキーボード操作して優越感に浸っています！

ハンバーガーボタン + ドロワーの操作

これはちょっと動画ではわかりにくいかもしれませんが、次のこだわりがあります。

• ドロワーもキーボード操作が可能
• ドロワーを開くとフォーカスがドロワー内の最初の要素に移る
• ドロワーは ESC ボタン、ハンバーガーボタン、ドロワー外のクリックで閉じることができる
• ドロワーを閉じたときはフォーカスがハンバーガーボタンに戻る

ドロワーをキーボードするには「ドロワーを開くとフォーカスがドロワー内の最初の要素に移る」「ドロワーを閉じたときはフォーカスがハンバーガーボタンに戻る」が重要です。開いたときにドロワーにフォーカスが移らないとまた最初の位置からドロワーまでフォーカスを移動させていかないといけませんし、閉じたときにハンバーガーボタンにフォーカスが戻らないと閉じたときにどこにフォーカスがあるかわからず迷子になってしまいます（あるいはまた最初の位置にフォーカスが戻って超絶めんどい）。

これもわりとできていないサイトが多いので、ハンバーガーボタンがあるサイトを見かけたらキーボード操作して優越感に浸っています！

管理バー対応

WordPress は、ログインしている状態だとページの上部に「管理バー」が表示されるようになっています。この管理バーがなかなかのクセモノです。

PC の場合だと管理バーは常に上部に固定されているのですが、ブラウザ幅が600px未満になると管理バーは非固定になります。この動作と「ヘッダー上部固定」の組み合わせがめちゃくちゃめんどくさい！ちょっと技術的な話になりますが、ヘッダーを上部固定する場合はまぁだいたいこんな感じにすると思います。

.l-header {
  position: fixed;
  right: 0;
  left: 0;
}

これで最初にヘッダーが表示された位置（つまりページ上部）に固定表示されます。管理バーが有る場合は管理バーの下に固定表示されます。ここまでは問題ありません。ところがブラウザ幅が600px未満になったとき…

ということで、ブラウザ幅が600px未満の場合は管理バーが画面から消えるところまではヘッダーを position: absolute に、消えたら従来どおりの position: fixed に戻すという処理をおこなわないといけないのです。

ログインするのは管理者だけの場合が多いと思うので、管理バー対応はコストとの天秤で対応しないことが多いかもしれませんが、放っておくのもなんだか気持ちわるいし、こういう細かくて表からは見えない部分もしっかり対応するのがプロだと思うので対応しています！

iPhone におけるフッター固定ボタンの表示

まずはキャプチャ動画をご覧ください。

フッターに固定されているボタンのエリアに注目してください。下にスクロールすると透過されることがわかると思います。上にスクロールするか、クリックすると透過が解除されます。

iPhone はページを表示した瞬間はブラウザの下部にナビゲーションバーが表示されます。下にスクロールするとそのナビゲーションバーが消えます。で、そのナビゲーションバーがあった部分をタップすると、またナビゲーションバーが表示されるという動作になります。このとき、「ナビゲーションバーがあった部分」にフッター固定ボタンがあった場合、「ボタンのクリック動作」より「ナビゲーションバーの表示動作」が優先されるため、「ボタンをクリックしたつもりがボタンが反応しない」ということがおこります。

「ボタンをクリックしてもボタンが反応しない」とユーザーは一瞬混乱すると思うので、ボタンが押せないとき（ナビゲーションバーがかくれているとき）は透過、ボタンがクリックできるとき（ナビゲーションバーが表示されているとき）は透過を解除するようにしています。

連続する見出し間の余白

テーマによって見出しの上下の余白は様々だと思いますが、見出しがコンテンツの区切りになることを考えると、通常の段落間の余白を1としたら、見出しの上は1.5とか2にすることが多いと思います。

このとき、h2、h3、h4 など全てのレベルの見出しで上を1.5とか2にしたとします。すると、h2の次にh3とか、h3の次にh4がくることって普通にあると思うですよね。状況によってはh2、h3、h4と連続で見出しがあってから段落とか。そうなると、見出し間の余白が大きすぎてバランスがおかしくみえてしまいます。なので、Snow Monkey の場合、普通は見出し上の余白は1.5とか2だけど、見出しが連続する場合は1になるように調整を入れています。

抜粋ですが CSS はこんな感じ。見出しが連続する場合は先行する見出しの下余白だけで間隔をとるようにしています。

  > h2, > h3, > h4, > h5, > h6 {
    & + h2, & + h3, & + h4, & + h5, & + h6 {
      margin-top: 0;
    }
  }

追加 CSS がエディターにも反映される

有料/無料テーマを使う場合ってゼロからテーマをつくりたくなくてラクをしたい場合が多いと思うので、PHP をゴリゴリ書くより CSS で装飾を変えるという使い方が多いのじゃないかなぁと思っています。その場合、CSS を書くためだけに子テーマをつくるのも面倒なので、そういうときはカスタマイザーの「追加 CSS」に書くのが便利です。

が、この追加 CSS、表側にはちゃんと反映されますがエディターには反映されません。WordPress 5.3 からはグループブロックも使えるようになって、ちょろっとデザインを変えたい用途で追加 CSS を書くことは増えるのではないかなと思うのですが、エディターに反映されないのは実に不便です。なんと Snow Monkey を使っている場合は追加 CSS もエディターに反映されるのです！

これめっちゃ良いのでコアに取り込んでもらおうと思って Core Trac と GitHub の issue で提案してみたのですが、影響範囲を完全には制御できないのがネックらしく却下されました。悲しい…。でもある程度理解がある人が使う分にはすごく良い機能だと思うので Snow Monkey ではそのまま機能を残しています。

他にももっと細かい点でネタはあると思うのですが、パッと思いついたものを書きました。他に思いついたときはまた書きます。では！