スムーススクロールのWebサイト独自実装をやめろ

スライダー・カルーセルなどがホイールで操作されてしまうページやコンテンツ単位のジャンプに置き換えられてるページの方がまだ好感が持てる。いいかスクロール量と速度を中途半端に変えるな。普通のスクロールの顔をしてさも気遣いをしているような態度で俺とページの間のインタラクションを奪うな
— 稲葉 (@eps_r) 2016年12月22日

説明しづらいんですが、ブラウザでのホイール回転を勝手にスムーススクロールというか、余韻（イージング）スクロールとか表現されるものに置き換えてしまうWebサイトを時折見かけます。

後付けの慣性とでも言うのでしょうか。はっきりいって右クリック禁止並にダサくてユーザー体験を毀損していて、友達に噂とかされると恥ずかしいサイトだと思っているのですが、不満に思う人が少ないのか、あるいは地味で説明しづらい事象なのをいいことに実装しているやからがいい気になっているのか、一向に消滅してくれません。

自衛策

いやだ、いやだと言っていても仕方ないので、ごく簡単なUserScriptをChrome版Tampermonkey向けに書きました。

gist.github.com

環境によってはrawがインストールのリンクになります。

動作の要点は上に書いてある通りなのですが一応説明しておくと、

1. イベントリスナ―の追加を妨害する

windowおよびdocumentオブジェクト、それからhtml要素のaddEventListenerをラップして、通常のイベントリスナーは通し、ホイールイベントのリスナーを追加できないよう妨害します。

このためページ製作者の意図しない挙動となり、ホイールに反応する何らかのギミックが停止したり、想定外の画面スクロールを発生させる可能性があります。典型的な例としては、ScrollifyやfullPage等のような画面単位のページング的スクロールをもたらすスクリプトは停止します。画面スクロールに連動する遅延ローディングが機能せず画像やコンテンツが表示されなくなることも考えられるでしょう。

2. スクロールバーを復元する

ページにホイールイベントの追加をする挙動があった場合、ページ読み込み完了時(DOMContentLoaded)とページの全要素読み込み完了時(load)の2回、html要素とbody要素のスタイルにoverflow: autoを上書きします。

これはjQuery.NiceScrollのように独自のスクロールバーを設定できるスクリプトがページ全体にoverflow: hiddenを設定し、スクロール自体を無効化することがあるため、対抗措置として書いています。

f:id:appalerm:20200625022605p:plain

画像の右端のように、ページ製作者の意図しないスクロールバーが出現し、デザインや動作に予想外の挙動をもたらす可能性があります。

動作チェック

わたしの環境では現時点でコルクのブログで良好に、マンガ図書館Zでまれに失敗する程度の動作をします。これで対応できなかったり不具合の出る例も大量にあるでしょうから、もっといい拡張や参考資料があったら教えてください。

もっといい拡張や参考資料があったら教えてください。（わりと切実なので2回書きました）

余談

ここで言っている独自実装のスムーススクロールとは、特に理由もなくユーザー標準のマウスホイールの動作を殺害し、手前勝手なスクロールの量と速度を押し付ける仕組みのことです。

以下は批判の対象外だと思っています。

いわゆるスライダーやカルーセルのような部品単位の操作
ページ内ジャンプの移動を補間する効果（どこに飛ぶか分かりやすくはなるので、ページ内リンクに適用する分には比較的マシ。速度次第）
fullPageのようなリッチコンテンツ様

今回はこれらの是非は問いません。

勝手なスムーススクロール実装を嫌う理由は上の「手前勝手なスクロールの量と速度を押し付ける」でほとんど説明がつきます。わたしはWindows版Chromeのスムーススクロールをオフにしていますが、にも関わらず、無神経なWeb制作者たちはeaseScrollやNiceScrollのような醜悪なプラグインを使ってわざわざ遅いスクロールを強要するわけです。クライアントから「Macみたいになるようにしてよ」とでも言われているのか？

スムーススクロール自体を嫌っているわけではありません。この手のスクロールはPageUp/PageDownを置き換えているものも多くありますが、単発で大きく動くこれらのキーとの相性は悪くないと思えるし、あるいはブラウザ/OSなどで操作が一貫していればいいでしょう。私がChromeでオフにしているのは、単にある日突然スムーススクロールの中でもとりわけ出来の悪いものが載って耐えられなかったというだけの話です。

一貫性を欠く、という話でもあります。あるWebサイトではノッチ式（段階的）だったスクロールが、別のWebサイトではヌルヌル動くようになることがあっていいのか？　何のためにユーザーはOSやブラウザの設定でスクロール量と速度を決められるのか？　特に工夫のないホイールの挙動*1なんてものを決めるのはWebサイト制作者ではなくユーザーの方です。つまり、ユーザーのスムーススクロールをノッチスクロールに変えるWebサイトがもし存在すれば、これも同等にクソです。

W3Cのアクセシビリティガイドラインでも言われているでしょう。

ガイドライン 3.2 予測可能: ウェブページの表示や挙動を予測可能にすること。

Web Content Accessibility Guidelines (WCAG) 2.0

いや、これは少し強引でした。

アクセシビリティガイドラインで言っているのは文書構成や入力フォームが主ですのでたぶん違うやつですが、考え方は似たようなものです。マウスはユーザーにとってキーボードと並んで主要な入力機器であり、その動作はなるべく予測可能とするのが望ましいでしょう。右クリックやステータスバーを阻害しないことが世間の常識になっていったように、ホイール回転のフックもある程度慎重に扱うべきだと個人的には思っています。ここでダサいということにしておかないとVAP公式サイトにおける右クリック禁止のようにバカがいつまでも変な所で残し続けるかもしれませんし。

大上段からまとめると、勝手スムーススクロールからは「世間の皆が同じマシンを使っていないと分かった上でなお同じ使用感を強要する」というエゴイズムを感じますから、今どきそんなことやめてほしい、という話です。そのように思った発端であり、記事とUserScriptを書く原動力になったコルクのブログのコードを紹介して今回は終わりです。

if (navigator.userAgent.indexOf('Mac OS X') == -1) {
    (function() {

        /* ********** 中略 スムーススクロール実現部分など ********** */

        function T(e, t, n) {
            window.addEventListener(e, t, n || false)
        }

        /* ********** 中略 removeEeventListenerなど ********** */

        var P = /chrome/i.test(window.navigator.userAgent);
        var H = "onmousewheel"in document;
        if (H && P) {
            T("mousedown", b);
            T("mousewheel", g);
            T("load", h)
        }
    })();
}