Summary

  • 内側のスクロール領域が端に達すると、残った操作が外側の領域へ伝わることがある。チャットは止まったまま、記事だけが移動する。
  • contain は外側への伝達を止め、内側の端を知らせる視覚効果は残せる。none はその効果も止める。違いは利用者が境界をどう感じるかに直結する。

長い記事の上にチャット欄がある。最後の発言まで下げたところで、もう一度ホイールを回す。すると記事の段落が画面から逃げる。2019 年の W3C 初の公開作業草案は、この仕組みをスクロール連鎖として説明した。操作は内側の容器から始まり、そこが端に着くと祖先の容器へ伝わり得る。機械には筋の通った処理でも、読者から見れば、会話の床板を踏んだら記事のエレベーターが動いたようなものだ。

開発者はかつて、タッチやホイールのイベントを監視し、端で preventDefault() を呼んでいた。しかし草案は、その手当ての不器用さを列挙する。非パッシブの監視処理があると、ブラウザーはスクリプトの判断を待ち、スクロールが遅れ得る。イベントを止めれば、端を越える動きだけでなく、端までの正常な動きも止めかねない。端に達したことを知らせる小さな弾みや光まで消える場合もある。背景の記事を動かしたくないだけなのに、チャット自身の「ここで終わりです」まで奪う必要はない。

2016 年 12 月の CSS 作業部会議事録には、名前も定まらない段階の議論が残る。当時の案は scroll-boundary-behavior。Tab Atkins は、スクロールが上端や下端に着いたとき、操作の意図を外へ逃がすか内側に留めるかを問うた。Simon Fraser は、一つのジェスチャーの間は同じ領域をつかみ続けるブラウザーの挙動と、ページが人の操作を閉じ込める危険を指摘した。最後まで読んだチャット欄は、会議で実際に挙がった例だ。仕様化への支持はあったが、決定は持ち越された。名前にも、挙動にも、まだ仕事が残っていた。

WICG で育った提案について、Majid Valipour は 2018 年 1 月に CSS 作業部会の草案へ移すよう求めた。議題には当時のブラウザー実装状況も記されている。小さな部品を守るための工夫が、異なるブラウザーで共有する境界の約束へ進んだ瞬間だった。作者が決めるのは「どこから先へ渡さないか」であり、指の動きの物理を自作することではない。

W3C の公開履歴は、最初の公開作業草案を 2019 年 6 月 6 日と記す。仕様は境界で起こる動きを二つに分けた。チャット内の反発や光は局所的な反応。親ページへの伝達やナビゲーションは外側に影響する反応だ。auto は通常の動作に任せる。contain は外側への動きを禁じつつ、内側の反応を許す。none は内側の反応も抑える。チャットに必要なのは、たいてい外へ通じる扉の鍵であって、壁の手触りまで消すことではない。

向きにも落とし穴があった。物理的な x 軸と y 軸だけを考えると、文字の流れが違うページで意図がずれる。2018 年 4 月のベルリン会議で、作業部会は block と inline の指定を追加すると決めた。境界の規則を文章の論理的な方向に沿わせるためだ。日本語の縦書きまで視野に入れると、この一行はけっして飾りではない。

草案には固定されたサイドナビゲーション、独自の引っ張って更新する操作、次々に項目を足すリストも登場する。同じ端でも、外へ渡したいか、反発を見せたいかは違う。チャットが最後の一言へ着いたとき、記事まで連れ去られない。それだけで、読者の手と画面の約束はずっと分かりやすくなる。