この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方)
出典検索?: "スクロールバー"
スクロールバー(英: scroll bar)は、主にウィンドウシステムにおいて単一のウインドウ内で収まりきらない情報の部分領域だけ表示し、必要に応じて表示領域を移動するためのGUIパーツ(ウィジェット)のことをいう。縦(垂直)方向と横(水平)方向の二種類があり、前者を単にスクロールバー(或いは垂直スクロールバー)、後者を横スクロールバー(水平スクロールバー)などと呼ぶ。なおスクロールバーはユーザ側からみた呼び名で、プログラム上ではスクローラー(英: scroller)と呼ばれる場合がある[1]。
スクロールの原義は「巻物」のことである。画面を移動する操作が巻物を巻き上げる様子に似ている事から、スクロールと呼ばれるようになった。 スクロールバーは複数のパーツからなる複合コンポーネントである。 スクロールバー本体はウインドウ内の右と下にそれぞれ垂直、水平のバーが置かれるケースが一般的である。この配置はXerox Starで最初に採用され[9]、初期のApple Macintoshから普及した[要出典]。対象となるウィンドウに対して常にスクロールバーが表示されるモードだけでなく、コンテンツのサイズがウィンドウのサイズを超えた場合にのみスクロールバーが自動で表示されるモードもある[注釈 2]。 他にも次のような配置や挙動のパターンがある。 本記事が対象とするウィジェットとしてのスクロールバー[注釈 3]自体はアラン・ケイらが開発した暫定ダイナブック環境(Altoで動作するSmalltalk)においてウィジェットとしての“ペイン”(ウインドウ表示域を分割する区画)に付属するものとして初めて考案・実装されたものである[10](1976)が、この時点では左側に配置される(ただし後述のとおりウインドウやペインの表示域外に描かれる)方式が採用された[11]。 左側に配置することのメリットは、グラフィカルインターフェイス上の表現では重要な機能が左側に集中する事が多く、ポインタや視線の移動効率が良い点が挙げられる[注釈 4]。Smalltalk-76[12](1976)、-80[13](1981)等の古典的Smalltalk処理系のGUIの他にも初期のLispマシン(Symbolics Genera OS
概要
名称と操作
つまみ(ノブ)
いわゆる「つまみ」。現在表示されている位置や、全体に占める割合などを示す。ノブをドラッグすると表示領域を移動する事ができる。この時内容がリアルタイムで更新される場合(ライブスクロール)と、ノブを放した時に更新される場合がある。米国などではつまみのバー(棒)をサム (英: thumb) ともいう。このサムには異なる名称があり、Macintoshでは「スクローラー」と呼ばれている。JavaプラットフォームのAWTやSwing、JavaFXでは「バブル」「サム」「スクロールボックス」または「ノブ」[2] [3] [4]、マイクロソフトのMSDNドキュメントでは「スクロールボックス」「サム」「スクロールサム」と称する[5] [6] [7] [8]。他には、@media screen{.mw-parser-output .fix-domain{border-bottom:dashed 1px}}「エレベーター」、「クイント」、「パック」、「ワイパー」または「グリップ」とも呼ばれる[要出典]。
矢印(アロー)
上下(左右)の矢印で、クリックするとその方向にノブが1単位移動する。移動量はおおむねテキスト1行である。多くはボタンを押し続けると連続移動を行なう(リピートボタン)。アローの配置には2つの流儀があり、スクロールバーの両端に分かれて配置される場合と、一方の端にそろえて配置される[注釈 1]場合に分かれる。前者の配置は「ノブを上下左右に移動させたい場合は上下左右それぞれの端にあるアローを操作する」という表現となっており、直感的で自然であるが、後者の集中配置型のほうがアロー間の距離が近くなるため、マウス移動の効率は良い。
本体
スクロールバーの本体はノブとアローを適切に配置し、制御している。この部分をクリックするとページ量が充分な場合は、おおむねテキスト1ページ移動する。「Shift」キーを押しながら本体部分をクリックすると、クリックした地点にノブが移動する。ページの一番上から一番下に一気に移動するときは「Shift」を押しながら、矢印(下向き)の少し上を押す。
スクロールバーの配置
垂直スクロールバーを左側に置くパターン
これとは別に、アラビア語のように右から左に向かって記述する言語版のインターフェイスでは、左から右に向かって記述する他の言語との対称性に配慮して、スクロールバーは左側に配置されるのが一般的である。
なお、水平スクロールバーはほとんどの場合、下側に配置される傾向が強い。 スクロールバーをウインドウやペイン内部に常時表示することはせず、マウスオーバー(あるいはタッチ操作であればスクロールのアクション)をフックして適宜描き足す場合がある。iOSデバイスやmacOS(OS X Mavericks以降)などを通じ徐々に普及しつつあるオーバーレイ描画のスクロールバーが本パターンに属する。 この方式には、ウインドウ内に固定されたスクロールバー表示領域をとらずにすむという画面効率上の利点がある。表示領域を節約する以外にも、画面表示をシンプルかつスタイリッシュに保つのにも役立つ。一方、トレードオフとして、スクロールバーが表示されない状態ではウインドウやペインがスクロール可能かどうかや全体に対して表示されている内容の割合がどれぐらいかが分からないといったデメリットも生じうる。 このパターンの歴史は古く、前述のとおりSmalltalkにおけるGUI初のスクロールバーは同様の方針(ただしオーバーレイ表示ではなく、当時のモノクロ二値表示でも実装が容易であったウインドウやペインの左脇に瞬時に描き足す方式)で実装されている。 スクロールバーは画面の固定領域を占有し、また情報を覆い隠してしまうので、利用を可能な限り避けるべきである。とはいえ画面の大きさには限りがあり、必要な大きさが事前に分かっているケースはまれである。またホイールを使えば移動の補助は可能だが、全体の大きさや位置はやはり必要となる。 他に代替手段としては、3次元コンピュータグラフィックスの3Dビューなどにおいてマウスカーソルの移動やドラッグを活用したズームやパンにより全体を拡大縮小・移動するインタフェースなどが考案されている。
状況に応じて追加描画されるパターン
インタフェースとしてのスクロールバー