CSS大解剖 4日目: 「閲覧環境 2/3」

• ビューポートが使われるようなデバイスでは、ビューポートの大きさがそのまま初期包含ブロックの大きさになります。ただし、以下の「動的なビューポート その2」の内容を考慮に入れると、話は少しややこしくなります。
• ページが使われるようなデバイスでは、最初のページのマージン、ボーダー、パディングを除いたページエリアが初期包含ブロックとして使われます。

初期包含ブロックはおおむね描画領域全体の大きさを表すため、Webページ全体のレイアウト指定で利用したくなることがしばしばあります。このために使えるのがビューポート百分率長さです。名前に反して、これらはビューポートではなく初期包含ブロックからの相対として定義されています。これには以下の亜種がありますが、以下の「動的なビューポート その2」でさらに一般化されます。

• 物理座標に基づく指定
  • 100vw … 初期包含ブロックのx軸方向の大きさ
  • 100vh … 初期包含ブロックのy軸方向の大きさ
• 論理座標に基づく指定 (Working DraftのCSS Values and Units Level 4 で定義)
  • 100vi … 初期包含ブロックのインライン軸方向の大きさ
  • 100vd … 初期包含ブロックのブロック軸方向の大きさ
• デバイスの向きに応じた指定
  • 100vmin … 100vw と 100vh のうち小さいほう。つまり、縦長なら 100vw, 横長なら 100vh
  • 100vmax … 100vw と 100vh のうち大きいほう。つまり、縦長なら 100vh, 横長なら 100vw

動的なビューポート その2

ビューポートの大きさが動的に変わりうることは「動的なビューポート その1」で説明しました。しかし、スマートフォン向けブラウザの進歩により、この事情には大きな変化が発生します。

スマートフォンのように面積の制限が厳しいデバイスでは、限りある画面を有効に使うことが非常に重要になります。そこでWebブラウザは、必要性の薄いツールバーをユーザーのナビゲーション操作にあわせて賢く動的に隠すような機能を実装するようになりました。よく見られるのは以下のような実装です。

• ツールバーはコンテンツの上に存在し、初期状態では表示されている。
• ユーザーがコンテンツを下にスクロールするときは、コンテンツに関心があると推定されるため、スクロール操作にあわせて徐々にツールバーを隠す。
• しかし、それだけだとツールバーを再表示する手段がないため、ユーザーがコンテンツを上にスクロールするときは、その操作にあわせて徐々にツールバーを再表示する。上にスクロールするときはコンテンツに興味がなくなったかナビゲーションを行いたいと推測されるので、この推定はある程度合理的だと考えられる。

これにより実質的なビューポートの大きさは動的に変化します。動的に変化するということ自体は以前の挙動と同じですが、この出し入れ操作が今までにない頻度で、ユーザーの無意識下で発生することが問題になります。

従来、ビューポートのリサイズの多くはユーザーの明示的な指示のもとで発生していました。たとえばPCでウインドウの端をドラッグする操作はこれに当たります。このような場合に、ビューポートの変化にあわせてWebページのレイアウトが変化することはそれほど問題にはなりません。しかし、スマートフォンの例ではユーザーは表示中のコンテンツを上下にスクロールしているだけであり、これによりレイアウトがガタガタと変化するのは問題になりえます。

この問題の対応として、「ビューポート」という概念は3種類に細分されることになりました。ここではWorking Draft段階のCSS Values and Units Module Level 4を参照します。

• 動的なビューポート (dynamic viewport)は従来のビューポートの概念と同様に、ユーザーがコンテンツを見るために実際に使われている領域を指します。動的なビューポートは頻繁に変化するので、動的なビューポートに依存するレイアウトはなるべく避けるのが肝要です。
  • 実際のWebブラウザは、表示の変化にあわせてCSS/JS向けの動的ビューポートサイズをリアルタイムに更新することはせず、1秒程度のデバウンスを行うようです。
• 大きいビューポート (large viewport)は、動的なビューポートの大きさの上界を与えます。これはスクロール等により頻繁には変化しません。
• 小さいビューポート (small viewport)は、動的なビューポートの大きさの下界を与えます。これはスクロール等により頻繁には変化しません。

CSSやJSでレイアウトを組むにあたっては、要件にあわせてこれらを使い分けるのが重要になるでしょう。

• もし、ビューポート内の全ての領域を埋め尽くすようにコンテンツを配置することが重要であり、少しぐらいコンテンツがはみ出てもいいのであれば、大きいビューポートを使うのがいいでしょう。そうすれば、意図せず余白を生じてしまうことはなくなりますし、レイアウトは安定します。
• 逆に、コンテンツがビューポート内に収まることが重要であり、少しくらい余白が出てもいいのであれば、小さいビューポートを使うのがいいでしょう。そうすれば、コンテンツが大きすぎて画面からはみ出してしまうことはなくなりますし、レイアウトは安定します。
• どうしても画面の大きさに対してぴったり合わせる必要があるのであれば、動的ビューポートの大きさを参照することも可能です。しかし、ユーザーのスクロールに対して結果がガタガタするなどの弊害が生じるかもしれません。

これまで用いられてきた「ビューポート」の概念は、新しい3種類のビューポートのいずれかに対応づけられます。

• CSSの単位としての vh/vw/vmin/vmax は、大きいビューポートを参照します。これはすでにこの機能を実装していたWebブラウザの挙動に合わせる形でこのように記述されているものです。なるべく動的ビューポートを参照させないことがユーザーの快適性にとって重要であるため、このような挙動になったのでしょう。
• 初期包含ブロックは小さいビューポートを参照します。これもWebブラウザの挙動に合わせる形で定義されています。
• 初期包含ブロックは position: absolute; な要素に影響を与えますが、いっぽう position: fixed; でレイアウトされる要素の位置やサイズ指定は動的なビューポートを参照します。

この新しいビューポート種別を明示するためにCSSの単位が拡張されます。以下はCSS Values and Units Module Level 4で定義されているビューポート相対単位の一覧です。

動的なビューポート その3

スマートフォンのようなデバイスでは、ソフトウェアキーボードもビューポートの大きさに影響を与えます。これはブラウザのツールバーにも似ていますが、以下の違いがあります。

• 初期状態では表示されない。
• ツールバーほどの頻度では出し入れされない。

このような性質もあってか、ソフトウェアキーボードのようなUIは動的ビューポートとは別の方法で取り扱われています。

ソフトウェアキーボードの挙動は以下の「モバイルビューポート」の節で紹介する タグで設定できます。 (これはWorking DraftであるCSS Viewport Module Level 1中に記述されています)

• interactive-widget=overlays-content … ソフトウェアキーボードはビューポートの「上」に重ねる形で表示されます。ビューポートの大きさは変わりません。
• interactive-widget=resizes-content … ソフトウェアキーボードはビューポートの領域を奪います。ソフトウェアキーボードの大きさ分だけ、ビューポートの大きさが小さくなります。
• interactive-widget=resizes-visual … overlays-contentとresizes-contentの中間です。以下で説明する「視覚ビューポート」の大きさのみ縮小します。

非矩形ビューポート

切り欠き (notch) を持つスマートフォンやスマートウォッチなど、四角形以外の表示領域を持つデバイスもあります。このような場合は通常、表示可能な領域全体を覆うようにビューポートが設定されます。このような場合、画像などのコンテンツをビューポート全体に拡大するようにレイアウトすると、コンテンツの一部が欠けてしまうことになります。

このような場合に対応するための仕様がCSS Environment Variables Module Level 1というdraftで策定中です。この仕様では、以下の2つの環境変数を定義することで、非矩形ビューポートでコンテンツ全体を表示するための最適なレイアウトを表現できるようにしています。

• ビューポートの端の表示不可能な領域を取り除くために必要なマージン量
• 複数の不連続な領域に分割されている画面における、各々の領域の座標

関連するドラフト仕様として、非矩形ビューポートに関するメディアクエリを定義するCSS Round Display Level 1も策定中です。

モバイルビューポート

スマートフォンのような小さいデバイスで、コンテンツを読みやすいように (物理単位または視角単位にあわせて) 長さを規定すると、画面の幅と高さはかなり小さくなります。

たとえば2012年発売のiPhone 5の画面の横幅は5cm程度です。物理単位を基準にすると、これはおよそ190pxに相当します。また、30cm程度の距離で閲覧することを想定して視角単位を計算すると、これはおよそ450pxに相当します (実際のiPhone 5はこれを物理ピクセルサイズの2倍に丸め、横幅320pxとして計算していたようです)。

しかし、実際にこのような小さい幅でレイアウトを行うと、従来のPC環境を想定したWebサイトの中にはレイアウトが崩れてしまうものも出てきます。そこで、スマートフォン向けWebブラウザでは以下のような対策が取られることになりました。

• 従来のWebサイトを表示する際は、ビューポートを大きめで計算してレイアウトする。その結果はスマートフォンの画面に収まらないので、ズームアウトするか左右にスクロールして読む。
• スマートフォン環境に対応したWebサイトはそのことを タグで明示する。この場合レイアウトは本来のビューポートに基づいて算出される。

このとき使われる タグは歴史的に2種類あり、HandheldFriendly/MobileOptimized meta tagを使う方法とviewport meta tagを使う方法があります。現在は後者が事実上の標準となっており、こちらの標準化がCSS Viewport Module Level 1で進められています。

ただし、この仕様書の完成度はまだかなり低いので、そこから参照されているA new Device Adaptation spec – QuirksBlogを参考にします。

2つのビューポート

この仕様では、ビューポートが2種類に分割されます。

• 視覚ビューポート (visual viewport) はスマートフォンの画面に対応する領域です。その大きさは、スマートフォンの本来の画面サイズ × ピンチズーム率 です。
  • ピンチズームとは、レイアウト済みの画面を単純拡大・縮小するようなズームのことで、スマートフォン上のピンチ操作に関連付けられていることが多いです。ピンチズーム以外のズームとしては、デフォルトのフォントサイズを変更するようなズームがよく使われます。
• レイアウトビューポート (layout viewport) はCSSの指定を解釈してレイアウト処理を行うときに参照される仮想的な領域です。

Webブラウザは、レイアウトビューポートの一部分を切り出して視覚ビューポートに表示することになります。別の言い方をすると、レイアウトビューポートは の上位にもう1つスクロールコンテナを配置する仕組みであるとも言えます。

meta name="viewport" content="width=device-width, initial-scale=1">

meta name="viewport" content="width=device-width">

@viewport {
  min-zoom: 0.25;
  max-zoom: 5;

  min-width: 980px;
}