CSSを書く前にスクロールバーを表示しよう
公開:
これを読むあなたはCSSを書く方だと思いますので、お尋ねします。
あなたは普段、幅と高さを持つ、クラシカルなスクロールバーを表示していますか?
していないのだとしら、それはどうしてなのでしょう。
OSの初期設定から変えていないだけかもしれません。スクロールバーを醜いものだと考えていて、スクロールするときだけに出現する控えめなスクロールバーを好んでいるからかもしれません。
あなたがどう考えていようと、現実にはそのような、ユーザーの操作に応じてオーバーレイで表示されるスクロールバーが選択できない環境も存在します。
そういった環境では、スクロールバーはウェブページ上で幅と高さを持ち、レイアウトに影響を与えます。
それを忘れて書かれたCSSは、オーバーレイ・スクロールバー前提のレイアウトであったり、不必要なスクロールバーの存在を生み出してしまうことがあります。
スクロールバーを表示、つまり、ウェブページ上で幅と高さを持つスクロールバーを使っていれば、そのような現象を発見することは容易いのです。
わざわざプレビュー用のブラウザーへマウスカーソルを移動してオーバーレイ・スクロールバーを表示させる必要もなく、一瞥するだけで判断できるでしょう。
これから挙げる少しの例は、幅と高さを持つスクロールバーのことを忘れて書かれたCSSの例で、現実のウェブサイトで見かけたものを簡略化したものです。 Viewport-percentage lengthsは、その要素がどこにあろうと、ビューポートに対して相対的な長さを指定することができる、とても便利なものです。 ある要素に オーバーレイ・スクロールバーを使っている方には何がおかしいのかわからない、正常なウェブページに見えるでしょうが、スクロールバーが幅と高さを持つ世界では、横スクロールバーが表示されています。 「CSS Values and Units Module Level 3」にはこうあります。 スクロールバーは存在しないものとして計算されるので、幅と高さを持つスクロールバーが存在した場合には、その分のずれが生じます。 ビューポートいっぱいに広げた要素で何をするのかにもよりますが、ほんの少し横スクロールしなければ見ることができないコンテンツを含む、というレイアウトを意図しているのは稀でしょう。 オーバーレイ・スクロールバーの利用者は通常どおり、他の利用者は少しの横スクロールが必須である、という2つの要件があるウェブページというものは想像できませんが、そのような意図がない限りは、この横スクロールバーは不要です。 Viewport-percentage lengthsを、特に 「CSS Values and Units Module Level 4」(リンク先は2019年1月31日版)では、スクロールバーのことが考慮されていますので、多くの環境がこちらの仕様に合わせられるころには、 いろいろなウェブサイトを見ていると、とってもオシャレでスタイリッシュなイントロ・アニメーションや、クールなローディング・アニメーションを見ることがあります(以降、イントロ画面と呼びます)。 その存在、または動作の是非についてはここで話すことではありませんので、いったん忘れましょう。 イントロ画面を表示するページでは、それを表示している間はユーザーにスクロールさせたくないという理由で、メイン画面の要素(多くの場合はルートとなる要素)に その気持ちはわかります。スクロールできてしまうと、イントロ画面が消えたあと、ユーザーは途中からコンテンツを見ることになりますから。 ともかく、スクロールをロックするという処理は行われています。 イントロ画面の表示から非表示までは、いろいろなパターンがありますが、単純な例を作りましたので、ご覧ください。 どうでしょう、違和感なく見ることができましたか。オーバーレイ・スクロールバーの方は何も気にならないでしょう。そうでない方は気づいたことと思います。 ウェブページの閲覧や操作には大きな影響を及ぼしませんが、とってもオシャレでスタイリッシュなイントロ画面を必要とするような、見栄えを気にするウェブページで、この現象は許容されるのでしょうか。 この現象は何もページを開いたら見ることを強制されるようなイントロ画面に限りません。 この現象は幅と高さを持つスクロールバーを表示していればすぐに気づきます。 「CSS Overflow Module Level 4」(リンク先は2017年6月13日版)には 簡単に言うと、スクロールバーのスペースを予約しておくかどうかを制御できるプロパティです。これが使えるようになれば、スクロールバーが「こんにちは!」したときのレイアウトのずれを制御することも容易になるでしょう。 ただし、2020年2月現在、実装しているブラウザーは存在しません。 なお、このプロパティはCSS Overflow Moduleではなく、スクロールバーの仕様に移動されるようです。「CSS Scrollbars Module Level 1」(リンク先はEditor’s Draft)を追っていれば、そのうち追加されるでしょう。100vw
ですが、それらの単位を使うときにはスクロールバーの存在を忘れてはなりません。100vw
を指定した例を見てみましょう。100vw
はスクロールバーの幅を含めた幅です。いまのところは。
ウェブページの利用者にとっても特に意味のないスクロールバーです。ですが、スクロールできます。できてしまいます。それによって配置されているコンテンツは少し移動してしまいますので、もしかすると見切れることがあるかもしれません。100
という数値を利用する際にはスクロールバーの存在を忘れてはなりません。
幅と高さを持つスクロールバーを表示していれば、この現象はすぐに見つけられるでしょう。アップデートされたViewport-percentage lengths
100vw
で横スクロールバーが発生する、という現象はいまより減るかもしれません。こんにちは、スクロールバーです!
あなたも見かけたことがあるでしょう? または、あなたはそれを作る側かもしれません。overflow: hidden
が指定されていることがあります。
制作者の都合でスクロールをロックするのはいいのか、ですか。さきほど書いたとおり、その話は別の問題です。
アニメーションが終わったとたんにスクロールバーが出現することで、その幅の分、全体のレイアウトが狭くなり、ガタつきが発生しています。
ページ遷移の際のローディング画面、モーダル・ウィンドウの表示、ハンバーガー・ボタンによって出現するナビゲーションなど、スクロールをロックするような場面では頻出します。
気づいた上で対応するかどうかは別の話ですが、気づいていないのはよいことだと思えません。scrollbar-gutter
プロパティscrollbar-gutter
プロパティというものがあります。
たった2つだけの例でしたが、他にもスクロールバーが幅と高さを持つことによる現象はあります。
また、特定のブラウザーでのみ意図しないスクロールバーが出現することもあります。
それらを発生させてしまうことは仕方がありません。
問題はそれを発見できるかどうかです。
発見を容易にするには、せめてCSSを書くときだけでも幅と高さを持つスクロールバーを表示しておくことです。
たとえあなたがそれを嫌っていようとも、現実にはそのスクロールバーを使っているユーザーは数え切れないほど存在します。
ですので、どうか「だったらスクロールバー自体を見えなくしてやる」という結論に達することのないように願っています。それは通常のウェブページでは不便なだけです。