scriptjunkie{}

レスポンシブ Web デザインの一般的なテクニック

Rahul Lalmalani | 2013 年 5 月 13 日

前回、 Web はレスポンシブ デザインに対応できるようになり、サイト所有者はユーザーのデバイスと画面領域のコンテキストを調べ、PC、携帯電話、コンソールなど、どのようなサイズの画面でも コンテキストに応じたエクスペリエンスをユーザーに提供できることを紹介しました。

今回は、レスポンシブなサイトのレイアウトとエクスペリエンスを構築するための最もよく使われる手法をいくつか調べます。まず、新たに登場した利用可能なサイト レイアウトのテクニック ("流動的なグリッド") について説明します。これは、サイトのレイアウトを画面領域に応じて柔軟にサイズ変更するテクニックで、どのような画面サイズでもユーザーが完全なエクスペリエンスを得られるようにします。さらに、リッチ メディア (特に画像) の表示方法や、小さい画面のデバイスを使用しているサイトの訪問者に高品質メディアを表示して帯域幅に追加コストを発生させるような事態を防ぐ方法を示します。

ここで紹介するテクニックを試すときに、サイトの外観をさまざまなデバイス解像度でテストする方法を以下にいくつか示します。

1. レスポンシブ Web デザイン ブックマークレット (英語) が Benjamin Keen により提供されています。これは、使用しているブラウザーのお気に入りバー （ブックマーク バー） に追加でき、クリックすると、さまざまな解像度でサイト レイアウトをテストできます。
2. Windows 8 を使用している場合は、 Windows 8 のスナップ モードを使用して Internet Explorer 10 でいつでもページ レイアウトをテストできます。Windows 8 では、Internet Explorer 10 を全画面 (フル モード) で使用することも、ブラウザーをスナップ モードに固定してスマート フォン ブラウザーのレイアウト特性のエミュレーションを行うことによってマルチタスクにすることもできます。さらに、ブラウザーをページ横幅に合わせたモードに固定することもできます。このモードは、既定の Windows 8 画面サイズ 1366 x 768 ピクセルのうち 1024 x 768 ピクセルに表示されるため、iPad や従来の 4:3 の画面でのサイトの外観を再現するのに最適です。
3. 最後に、図 1 のような操作をおそらく何度も行います (画像は Reddit.com からご提供いただきました)。

図 1. レスポンシブ Web デザインの基本的なテスト

メディア クエリ

これまで開発者はブラウザーのユーザー エージェント文字列を検出して、サイトを訪れたユーザーが使用しているのが PC かモバイル デバイスかを識別していました。識別後は、通常、ユーザーを別のサブサイトにリダイレクトします。サブサイトは実質的には同じコンテンツを表示しますが、レイアウトや情報デザインが異なります。たとえば、以前 MSN.com にアクセスしたユーザーは、従来の PC 用サイトが表示されるか、http://m.msn.comにリダイレクトされて専用のモバイル サイトが表示されていました。

しかし、リダイレクトには、2 つのエンジニアリング作業が個別に必要です。また、このアプローチは、"2 つの画面レイアウト (320 ピクセル幅のモバイルと 1024 ピクセル幅のデスクトップ) に最適化" されていたため、タブレットなどの中間的なサイズのデバイスでアクセスするユーザーや非常に大きな画面を使用するユーザーに適切なエクスペリエンスを提供することはできませんでした。

CSS3 は Web 開発者を助けるもので、"コンテンツの作成" (JavaScript と HTML でのページ マークアップと機能) とコンテンツのプレゼンテーションを切り離すことができ、メディア クエリを導入することで CSS 内から複数の画面サイズ用のレイアウトを処理できるようにします。

メディア クエリは、CSS3 スタイルシートを記述し、画面サイズ、メディアの種類など画面の物理要素を条件としてすべての UI 要素のスタイルを宣言する方法です。メディア クエリを使用すると、デバイスの幅、ピクセル密度、向きなど、関係する要素をブラウザーに要求することで、同一のマークアップに複数のスタイルを宣言できます。

CSS3 を使用する際に陥りがちな落とし穴は、同一の Web ページ マークアップに対して、現在一般的な画面サイズ (デスクトップ、タブレット、および携帯電話) を対象とする 3 種類の固定幅レイアウトを構成してしまうことです。しかし、これは "真のレスポンシブ Web デザイン" ではなく、すべてのデバイスで最適なエクスペリエンスは実現されてはいません。メディア クエリは真のレスポンシブ Web レイアウトを実現するソリューションの "一部" に過ぎず、利用可能な画面幅に合わせて相対的に拡大されるコンテンツも必要です。これについては、後ほど説明します。

"ピクセル" とは

Web のデザインやレイアウトには、これまで長い間 "ピクセル" が使われています。従来、この語は、ユーザーの画面に表示される赤、青、緑のドットの 1 点を意味してきました。ピクセル ベースの Web デザインは、Web ページの個々の要素のサイズや文字体裁を宣言する際の Web レイアウトの事実上の標準となっています。主な理由として、ほとんどのサイトでヘッダーやナビゲーションなどのページ UI 要素に画像が使用されており、サイト レイアウトは画像が美しく見える固定ピクセル幅で行われているからです。

ただし、最近の高ピクセル密度の画面や Retina ディスプレイの登場により、この用語には別の意味が加わりました。現代の Web デザインでは、ピクセル (先述のハードウェア ピクセル) は、画面に描画される点の 1 点を指すものではありません。

iPhone4 で Web サイトを表示すると、640 x 960 ピクセルのハードウェア画面は、画面サイズ 320 x 480 ピクセルとしてブラウザーに通知されます。わずか 2 インチの幅に 640 ピクセル幅のテキスト列を表示するのは望ましくないため、おそらくこれが最善です。しかし、iPhone 画面などの高密度デバイスに関して重要な点は、ハードウェア ピクセルを意識した開発を行わないことです。

W3C では、密度 96 ppi のデバイス上の 1 ピクセルを腕をのばした距離から見た際の視角を "参照ピクセル" (reference pixel) と定義しています。複雑な定義は別として、まとめると、最新の高解像度画面用にデザインする場合、メディア クエリでは参照ピクセル (別名 "CSS ピクセル") に対応します。CSS ピクセル数は、多くの場合ハードウェア ピクセル数より少ないというメリットがあります (注意: 大半のデバイス メーカーが高品質の携帯電話、スレート、Retina ディスプレイなどの宣伝にハードウェア ピクセル数を使用しているために、CSS で混乱が生じます)。

このハードウェア ピクセル数と CSS ピクセル数の比率を "デバイス ピクセル比" と呼びます。デバイス ピクセル比が高いと、各 CSS ピクセルが多くのハードウェア ピクセルでレンダリングされ、テキストやレイアウトがくっきりと表示されます。

Wikipedia には、 ピクセル密度別に最新ディスプレイを一覧にした便利なページ (英語) があり、デバイス ピクセル比も記載されています。必要な場合には、次のように CSS3 メディア クエリを使用してデバイス ピクセル比をいつでも特定できます。

/*Note that the below property device pixel ratio might need to be vendor-prefixed
 for some browsers*/
@media screen and (device-pixel-ratio: 1.5)
{
  /*adjust your layout for 1.5 hardware pixels to each reference pixel*/
}
@media screen and (device-pixel-ratio: 2)
{
  /*adjust your layout, font-sizes etc. for 2 hardware pixels to each reference pixel*/
}

また、 Tyson Matanich による GetDevicePixelRatio (いずれも英語) など、ブラウザーで JavaScript を使用してデバイス ピクセル比を計算するためのオープン ソース ライブラリも存在します。この結果を利用できるのは JavaScript でのみですが、この結果を利用して画像のダウンロードを最適化し、高解像度ディスプレイ搭載ではないデバイスに (ファイル サイズの大きい) 高品質の画像をダウンロードするのを避けることができます。

ただし、ページやコンテンツ レイアウトの定義に "デバイス ピクセル比を使用するのはお勧めしません"。参照ピクセルとハードウェア ピクセルの違いはわかりにくいですが、ユーザーによりよいエクスペリエンスを提供するために重要であることは容易に理解できます。iPhone 3GS と iPhone 4 は物理画面サイズと使用パターンがほぼ同じのため、当然ながら、テキスト ブロックをほぼ同じ物理サイズにすべきです。

同様に、1920 x 1080 p 画面の HDTV を使用している場合も、それだけの理由でデバイス本来の解像度に合わせてサイトのコンテンツをレンダリングすることはありません。ユーザーは TV から 1 ～ 2 メートル離れて、ジョイスティックなどのあまり正確でない入力メカニズムを使用して操作するため、TV ブラウザーでは複数のハードウェア ピクセルをまとめて 1 つの参照ピクセルにすることが好まれます。デスクトップ ブラウザー向けの 960 ピクセル幅のサイトをデザインしておけば、TV が 1080 p でも旧来モデルの 720 p でも、サイトは同じように表示されて利用できます。

一般には、テキスト コンテンツはこのような大型デバイスのほうがきれいに表示されます。ただし、画像コンテンツの場合、ピクセルが見えたり、ぼやけて見えることがあります。そのため、実用的な観点では、高品質の写真/画像データを高ピクセル密度の画面に表示する場合、デバイス ピクセル比が最も重要になります。また、ユーザーの最新高性能携帯電話にブランド ロゴをくっきりと表示したいと考えるでしょう。そこで後半では、レスポンシブな画像を実装するテクニックについて説明し、それを実現できる既存の JavaScript ライブラリをいくつか紹介します。

ここからは用語 "ピクセル" は "参照ピクセル" を指し、ハードウェア ピクセルを意味する場合には明示的に表現するものとします。

サイト レイアウトのレスポンシブな拡大/縮小

グリッド ベースのレイアウトが Web サイト デザインの主な構成要素です。大半のサイトは、ヘッダー、サイト ナビゲーション、コンテンツ、サイドバー、フッターなどのページ コンポーネントを一連の四角形ととらえて簡単に表現します。

レスポンシブ サイトをデザインするときの理想は、"ユーザーの画面サイズの影響を受けない" グリッド レイアウトを作成することです。つまり、2 ～ 3 種類の固定幅レイアウトを提供するのではなく、可能な限り (無理のない範囲で) 画面領域に合わせてレイアウトとコンテンツを拡大/縮小します。

モバイル優先のデザイン

このシリーズの第 1 回 (英語) で指摘したように、世界の Web トラフィックの 12% がモバイル デバイスからのものです。この割合は、スマートフォン普及率の高い国ではさらに高くなり、また、アジア、ラテン アメリカ、およびアフリカでもこれから普及が進むため、今後数年で大幅に高まると予想されています。

さらに、サイト デザインにおいてモバイル優先のアプローチを取ることは、情報デザインの練習にもなります。基本的に、このアプローチではモバイル バージョンのサイトで使用できるようにするコンテンツと機能に優先順位を付けてから、サイト レイアウトを段階的に大画面のデバイス用に拡張していきます。このようにすることで、デスクトップ エクスペリエンスの後回しとされることなく、ユーザーはモバイル デバイスで有益なエクスペリエンスを得ることができます。また、より魅力的なビジュアルのエクスペリエンスを提供できる場合には、追加の "2 層" コンテンツへのナビゲーションと同様に、追加の画面領域を利用できます。

ケース スタディ: Microsoft.com のデザイン変更

携帯電話や PC ブラウザーの幅を狭くした状態 (画面幅 540 ピクセル未満) で microsoft.com にアクセスすると、タッチ操作対応でリッチなビジュアルのスライド ショーの一部として 1 画像で 1 つの製品を紹介する単独のメイン画像が表示されます (図 2 参照)。主要製品は [見つける] セクションに特集されています。その他のナビゲーションはスクロールして表示するか、既定で折りたたまれた状態でユーザーがリスト アイコンをタップしたときに展開されるアコーディオン スタイルのメニューに収められています。同様に、検索ボックスは画面領域を節約するために既定では非表示になっているため、ユーザーは検索アイコンをタップすることになります。このように、モバイル レイアウトでは主要製品とリンクを上下に並べて表示し、縦の移動だけを必要とします。スクロールが必要なコンテンツや製品のリンクには上から下へ優先順位をつけます。

図 2. 携帯電話用にデザインされた microsoft.com

ビューポートの幅が 540 ピクセル以上 (携帯電話ではないが、タブレットや低解像度 PC でサイトにアクセスしていると考えられる状態) になると、最初のレイアウトが変わります (図 3)。既定で検索ボックスが表示され、前のレイアウトではリスト アイコンに隠れていたトップレベル ナビゲーションも表示されます。[見つける] セクションの製品は、横幅に収まるようになったため 1 行で表示されます。最も重要なのは、この遷移中、メイン画像が常に画面の幅いっぱいに表示されることです。

図 3. 540 ピクセル以上の場合の microsoft.com

幅が 640 ピクセル以上になると、またレイアウトが変わります (図 4)。これまで同様、メイン画像は画面幅いっぱいに表示されます。[法人のお客様] セクションの個々の項目は横並びのレイアウトになります。画面領域が増えたことで、メイン画像のキャプションが画像上にアニメーションで表示され、非常に目を引くようになります。

図 4.640 ピクセル以上のレイアウト変化

画面サイズが 900 ピクセル以上になると、最後のレイアウト変更が行われます (図 5)。[見つける] メニューが左側に移動し、利用可能な横の空間を活用して、縦にスクロールする必要性を減らしています。

図 5. 画面幅 900 ピクセル以上のレイアウト

最後に、最も重要な点ですが、ページ レイアウト (特にメイン画像) は引き続き利用可能な横幅 (最大 1600 ピクセル) に合わせて拡大され、最も魅力的な外観なるようにされています (図 6)。実際に、200 ～ 1600 ピクセルまでのすべての画面幅に対応し、メイン画像の両側に余白ができることはありません (同様に、[見つける] セクションと [法人のお客様] セクションは相対的なレイアウトは変わりませんが、その画像は画面サイズに比例して拡大/縮小されます)。

図 6. 高解像度の印象を最大限に引き出す

レスポンシブ レイアウト向けのテクニック

では、このようなエクスペリエンスを実装するにはどうすればよいでしょう。一般に、さまざまな画面サイズに対応する Web サイトのレイアウトには、突き詰めれば次の 2 つのテクニックを利用することになります。

• レイアウトを変更する必要がある分岐点を特定する。
• 分岐点の間でコンテンツを均等に拡大/縮小する。

これらのテクニックをそれぞれ見ていきましょう。

分岐点の間でコンテンツを均等に拡大/縮小する

microsoft.com を評価したときに指摘したように、画面サイズが 900 ピクセル以上になると、ホーム ページのヘッダー、メイン画像、ナビゲーション領域、コンテンツ領域の相対的なレイアウトは変わりません。ユーザーが 1280 x 720 のモニターで 900 ピクセル幅の Web サイトにアクセスしても、画面の左右 25% が空白になることがなく有益です。

同様に、サイトにアクセスするのは、480 x 320 ピクセル解像度 (CSS ピクセル) の iPhone 4 ユーザーの場合もあれば、640 x 360 ピクセル解像度の Samsung Galaxy S3 ユーザーの場合もあります。512 ピクセル未満の幅のレイアウトでは、microsoft.com はレイアウトが相対的に縮小され、どちらのユーザーにも余白ができることなくモバイル ブラウザー全体に Web コンテンツが表示されます。また、これはサイト閲覧時のデバイス向きには関係ありません。

これを実装する方法は、 CSS3 流動的なグリッドの提案 (英語) などいくつかあります。ただし、これはまだサポートしていない主要ブラウザーがあります。この機能は Internet Explorer 10 で (ベンダー プレフィックスを使用して) 確認できます。また、MSDN では、CSS3 グリッド実装の例を こちらと こちらで紹介しています。

流動的なグリッド レイアウトを実現するために、当面は、比率を基準にした幅を使用する実績ある手法を使用します。図 7 に示した単純な例を考えます。これには、次のデザイン要件があります。

1. #header は画面幅いっぱいに表示する。
2. #mainContent は画面幅の 60 % に表示する。
3. #sideContent は画面幅の 40% に表示する。
4. #mainContent と #sideContent の間には 20 ピクセルの固定間隔を設ける。
5. #mainImage の画像要素は画像周囲の 10 ピクセルの固定余白を除いて #mainContent 内部の利用可能な幅いっぱいに表示する。

図 7. 流動的なグリッドの設定

このページのマークアップは次のようになります。

<!doctype html>
<html>
<head>
  <title>Proportional Grid page</title>
  <style>
    body {
      /* Note the below properties for body are illustrative only.
         Not needed for responsiveness */
      font-size:40px;
      text-align: center;
      line-height: 100px;
      vertical-align: middle;
    }
    #header
    {
      /* Note the below properties for body are illustrative only.
         Not needed for responsiveness */
      height: 150px;
      border: solid 1px blue;
    }
    #mainContent {
      width: 60%;
      float: right;
      /*This way the mainContent div is always 60% of the width of its parent container,
        which in this case is the  tag that defaults to 100% page width anyway */
      background: #999999;
      }
#imageContainer {
    margin:10px;
    width: auto;
    /*This forces there to always be a fixed margin of 10px around the image */
}
#mainImage {
    width:100%;
    /* the image grows proportionally with #mainContent, but still maintains 10px of gutter */
}
#sideContentWrapper {
    width: 40%;
    float: left;
}
#sideContent {
    margin-right: 20px;
    /* sideContent always keeps 20px of right margin, relative to its parent container, namely
       #sideContentWrapper. Otherwise it grows proportionally. */
    background: #cccccc;
    min-height: 200px;
    }
  </style>
</head>
<body>
  <div id="header">Header</div>
  <div id="mainContent">
    <div id="imageContainer">
      <img id="mainImage" src="microsoft_pc_1.png" />
    </div>
    Main Content
  </div>
  <div id="sideContentWrapper">
  <div id="sideContent">
    Side Content
  </div>
  </div>
</body>
</html>

同様のテクニックが Wikipedia のページで使用されています。利用可能な画面の幅に合わせて記事のコンテンツが常に調整されることがわかります。最も興味深いのは、サイドバー (左側のナビゲーション バーと右側の HTML5 のエンブレムがある列) が固定ピクセル幅になっていて、画面の左右それぞれに "固定" されている点です。テキスト コンテンツのある中央の領域は、画面サイズに合わせて拡大/縮小します。図 8 と 図 9 に例を示します。サイドバーの幅は固定されていて変化しませんが、残りの中央のテキスト コンテンツで利用可能な幅は相対的に拡大/縮小されることに注目してください。

図 8. 1920 ピクセル幅のモニターで表示した Wikipedia

図 9. 800 ピクセル幅のモニターで表示した Wikipedia

サイトの左側に固定ナビゲーション メニューを表示する効果は、次のコードで簡単に実現できます。

<!DOCTYPE html>
<html>
  <head><title>Fixed-width left navigation</title>
  <style type="text/css">
  body
  {
    /* Note the below properties for body are illustrative only.
       Not needed for responsiveness */
    font-size:40px;
    text-align: center;
    line-height: 198px;
    vertical-align: middle;
}
 #mainContent
 {
    margin-left: 200px;
    min-height: 200px;
    background: #cccccc;
}
#leftNavigation
{
    width: 180px;
    margin: 0 5px;
    float: left;
    border: solid 1px red;
    min-height: 198px;
}
</style>
</head>
<body>
<div id="leftNavigation">Navigation</div>
<div id="mainContent">SomeContent</div>
</body>
</html>

分岐点を基準にページ レイアウトを変更する

携帯電話などの小型画面デバイスではすべてのコンテンツを等しく縮小するわけではないため、相対的な拡大/縮小だけでは解決できません。そこで、CSS3 メディア クエリを使用して、段階的にサイト エクスペリエンスを向上し、画面サイズが大きくなるのに合わせて列を追加します。同様に、小さい画面幅に対しても、メディア クエリを使用して優先順位の低いコンテンツのブロック全体を非表示にします。

MediaQueri.es は、分岐点でサイトのレイアウトがどのように変化するのかを確認できる優れたリソースです。Simon Collision の例を図 10 に示します。

図 10. さまざまな画面サイズでの Simon Collision の表示

CSS3 メディア クエリを使用して、これに似たエクスペリエンスを実現できます。図 11 のシンプルな例を見て見ましょう。ここでは、#red、#green、#yellow、および #blue の 4 種類の div を使用しています。

図 11. CSS メディア クエリの例

以下にサンプル コードを示します。

<!doctype html>
<html>
<head>
<title>Break points with media queries</title>
  <style type="text/css">
    /* default styling info*/
/* four columns of stacked one below the other in a phone layout */
/* remember to plan and style your sites mobile-first */
 
#mainContent
{
  margin: 40px;
}
 
#red, #yellow, #green, #blue
{
  height: 200px;
}
#red
{
  background: red;
}
#green
{
  background: green;
}
#yellow
{
  background: yellow;
}
#blue
{
  background: blue;
}
 
@media screen and (max-width:800px) and (min-width:540px)
{
  /* this is the breakpoint where we transition from the first layout, of four side-by-side
     columns, to the square layout with 2X2 grid */
 
  #red, #blue, #green, #yellow {
    width:50%;
    display: inline-block;
  }
}
 
@media screen and (min-width:800px)
{
  /*custom styling info for smartphones small screens;
    All columns are just displayed one below the other */
 
  #red, #yellow, #green, #blue {
    width: 25%;
    display: inline-block;
    white-space: nowrap;
  }
 
}
 
  </style>
</head>
<body>
  <div id="mainContent">
    <div id="red"></div><div id="green"></div><div id="yellow"></div><div id="blue"></div>
  </div>
</body>
</html>

通常、このようなスタイルシートをゼロから記述する必要はありません。結局、Web 開発に既存の豊富なオープン ソース フレームワークを利用しない手はありません。 Gumby Framework (Nathan Smith による実績のある 960 Grid System 上に構築) および Skeleton Framework などの既存のグリッド レイアウト フレームワークにより、利用可能な画面幅に応じてグリッド列数を変更するためのすぐに使えるサポートが提供されています。もう 1 つ、Wikipedia 風のレイアウトを目指す出発点として特に取り組みやすいものに、 CSS Grid があります。CSS Grid は、左側に固定幅の標準的なナビゲーション バーを表示しますが、画面解像度がタブレットやスマートフォン相当になると、ナビゲーション バーは非表示になり、1 列のレイアウトになります。

さらにメディア クエリを活用する

サイト デザインのニーズによっては、CSS を決定する前に、デバイス/ビューポートに関するデータが必要です。メディア クエリを使用してブラウザーの他の属性もポーリングできます。たとえば次のような属性があります。

• デバイスの 幅と 高さ。これは、ブラウザーで利用できる幅だけでなく、デバイス全体の幅も取得できる便利なプロパティで、ここからデバイスのフォーム ファクターを把握できます。
• デバイスの 幅と 向き (縦または横)。
• ブラウザーのアスペクト比と デバイスのアスペクト比。

その他については こちらで定義されています。

ここまで、レスポンシブ レイアウトの 2 つの要素を紹介し、その実装方法を調べてきました。真のレスポンシブ レイアウトはデバイス依存しない、つまり、特定のデバイス幅に最適化するのではなく、2 つのテクニックの組み合わせであることを忘れないでください。

画像と写真

Web では写真のコンテンツにも、スタイル (背景テクスチャ、カスタムの線、影、アイコンなど) にも画像が使用されます。画像によって Web の見栄えがよくなるため、開発者としては確実にサイトをリッチな外観にしてすべてのユーザーを引き付けたいところです。ただし、画像に関する最大の懸念事項は、ユーザー エクスペリエンスの重要な部分、具体的に言えば、パフォーマンスとページ読み込み時間にあることに間違いありません。

帯域幅への画像の影響

Web サイトは、HTML、CSS、JavaScript などのテキストによって成り立っています。通常、これらのファイルのダウンロードはせいぜい 50 KB 程度です。ページの中で最も帯域幅を使用するのは、通常、画像などのメディアです。新しいサイトのホームページの画像は、合計数 MB のコンテンツになります。ブラウザーでは、ページを描画するときにこのコンテンツをダウンロードする必要があります。さらに、すべての画像コンテンツをそれぞれ別のファイルとしてダウンロードすると、各画像ファイルの要求によりネットワークのオーバーヘッドが別々に発生します。これは 3G ネットワークのサイトにアクセスしている人には優れたエクスペリエンスとはいえません。豪華な 8 メガピクセルのパノラマ風景を背景に表示することを考えているならなおさらです。なにより、320 x 480 ピクセルの携帯電話にこのような高品質の画像コンテンツは妥当ではありません。では、携帯電話では反応の早いレスポンシブなエクスペリエンスを実現し、大型デバイスではよりリッチなメディア エクスペリエンスに拡張するにはどうすればよいでしょうか。

以下のテクニックを検討してください。これらのテクニックを組み合わせると、ユーザーの画像ダウンロードを約数百 KB に削減し、パフォーマンスを向上できます。

画像を CSS で代用できるか

Web 開発者は、CSS を活用して、一般的なシナリオの多くで画像を使用しないで済ませることができます。カスタム フォント、影、丸い角、グラデーション背景などをテキストに施すような簡単な効果を実現するために、開発者はこれまで画像を使用していました。

最新ブラウザの大半 (Internet Explorer 10、Google Chrome、Mozilla Firefox、および Safari) は、サイトへのアクセス中にユーザーがダウンロードする画像数の削減に利用できる下記の CSS3 機能をサポートしています。また、以前のブラウザーではこれらの手法の多くは自然にグレードダウンされます (たとえば、Internet Explorer 8 以前では角の丸い境界線が角の四角い境界線として表示されます)。このように、サイトは以前のブラウザーでも機能し、閲覧できます。

• @font-face を使用したカスタム フォント サポート: CSS3 を使用すると、サイトにカスタム フォントをアップロードして (アップロードするライセンスを所有している場合)、スタイルシートでそのフォントを指定できます。ページ タイトルやヘッダーをキャプチャして画像を作成したり、タイトルとヘッダー用に印象強いカスタム フォントを埋め込む必要はありません。
• 背景のグラデーション: 人気のあるサイトの多くはサイトの背景色がグラデーションになっていて、ページがあまり "平坦" な印象にはなっていません。これは、CSS3 を使用して簡単に実現できます ( こちらを参照)。
• 丸い角: CSS3 では、HTML 要素の四隅それぞれに border-radius を宣言によって指定でき、サイト デザインで角の丸い四角形を作成するために 20 x 20 ピクセルの円形の画像をいちいち使用しなくて済みます。
• 2D 変換: CSS3 では、translate()、rotate()、skew() などの 2D 変換を宣言して、マークアップの外観を変更できます。IETestDrive に便利な 機能例があります。回転などの一般的な変換を使用することで、画像のダウンロード数を削減できます。
• ボックスの影と文字の影: 最新のブラウザーでは、 box-shadow と text-shadow がサポートされており、これらを使用してコンテンツを 3 次元のように表示し、重要なコンテンツ (ヘッダー テキスト、画像、フローティング メニューなど) を目立たせることができます。

これらのプロパティには標準実装に加え、ブラウザー独自の実装 (ベンダー プレフィックスを使用) が必要なものがあります。 HTML5Please (英語) は、CSS3 にベンダー プレフィックスを追加する必要があるかどうかの判断に役立つソースです。

公平に言えば、以前のブラウザーでサイトにアクセスしたユーザーは、機能はするものの見映えの劣るサイト コンテンツを目にすることになります。しかし、このトレードオフは、最新のモバイル デバイスで 3G インターネットを使用してサイトにアクセスするユーザーが増加する状況で、反応の早いレスポンシブなサイト エクスペリエンスを提供するために必要なものです。

JavaScript を使用してコンテキストに応じた適切な画像サイズをダウンロードする

サイトのエクスペリエンスが本質的に画像によって左右されるならば、デバイスとネットワーク状態の範囲を判断して、使用しているデバイスのコンテキストに応じた魅力的なエクスペリエンスをユーザーに提供するソリューションが必要です。つまり、高品質の Cinema Display には、高品質の (つまりファイル サイズが大きい) 画像を表示してユーザーを驚嘆させる一方、4 インチの携帯電話画面で従量制の 3G データ接続を利用しているユーザーには、1600 x 1200 ピクセルの写真は表示しないようにします。

特定の画像に複数の画像ソースを指定する方法の提案に W3C が取り組んでいる最中ですが、これを今すぐ実現するにはいくつか新しい JavaScript テクノロジが役に立ちます。

メディア クエリ リスナー

最新のブラウザーでは、 メディア クエリ リスナーがサポートされています。メディア クエリ リスナーがあることで、JavaScript を使用して特定のメディア クエリ条件が満たされているかどうかを検証し、それに応じてダウンロードするリソースを判断できます。

たとえば、Web ページに写真を掲載するとします。開発者として、次の 2 つのことを行う必要があります。

• 高品質 (大画面のエクスペリエンス) または小画面のエクスペリエンスのしきい値 (分岐点) を決め、その決定に基づいて高品質用のリソースまたは低帯域幅用のリソースをダウンロードする。次のスクリプトを読み込み時に含めて、ページに適切なリソースがダウンロードされるようにし、ユーザーに適切なエクスペリエンスを提供します。

var mediaQueryList = window.matchMedia("(min-width:480px)");
//NOTE: for IE10 you will have to use .msMatchMedia, the vendor-prefixed implementation
 //instead
isRegularScreen = mediaQueryList.matches;
//this returns a Boolean which you can use to evaluate whether to use high-quality assets or
//low-bandwidth assets
 
if (isRegularScreen)
{
  //run script to download the high-quality images
}
else
{
  //the condition has failed, and user is on smartphone or snap-mode
  //run script to download low-bandwidth images
}

• 好みにより、メディア サイズの変化を監視するイベント リスナーを追加し、ユーザーがブラウザー ウィンドウのサイズを変更した場合に別のスクリプトを実行して、必要に応じて高品質のリソースを取得する。たとえば、ユーザーが最初にサイトにアクセスしたときに 320 ピクセル幅の Windows 8 のスナップ モードを使用しており、その後、サイトのコンテンツに興味を持ってブラウザーをフル モードで開くとします (HDTV で共有することも考えられます)。このとき、メディアに応じたより適切なエクスペリエンスを提供することが望ましいでしょう。

mediaQueryList.addListener(mediaSizeChange);
function mediaSizeChange(mediaQueryList)
{
  //Executed whenever the media query changes from true to false or vice versa
  if(mediaQueryList.matches)
  {
    //run script to acquire high-quality assets;
  }
else{
  //in this case the user has gone from a large screen to small screen
  //by resizing their browser down
  //if the high-quality images are already downloaded
  //we could treat this as a no-op and just use the existing high-quality assets
 
  //alternatively, if the smaller image shows a clipped version of the high-quality image
  //trigger the download of low-bandwidth images
 
  }
}

カスタム JS ライブラリ

もちろん、役立つカスタム ライブラリもあります。このようなライブラリでは、ユーザーのデバイスのサイズや解像度を特定し、実行時にソース画像を小型化したバージョンをネットワーク配信することで、似た機能を実現します。その例を次に示します。

• Filament Group は、 Boston Globe (英語) のサイトをレスポンシブになるようデザインし直しました。Filament Group のテクニックは こちら (英語) から利用できます。これを利用するには、サイトにいくつか JavaScript ファイルを追加し、サイトの .htaccess ファイルを変更する必要があります。次に、各 <img> タグに標準サイズと高解像度のバージョンを用意すれば、プラグインが残りの処理を行います。

<img src="smallRes.jpg" data-fullsrc="largeRes.jpg">

• 同様のテクニックが AdaptiveImages.com (英語) でも利用できます。このテクニックのメリットは、低解像度と高解像度の画像を指定するマークアップを手作業でコーディングしたり、同一画像の 2 種類のバージョンを手動でアップロードする必要がないことです。

· Tyson Matanich は ポリフィル データベース を作成し、一般に公開しています。これは、先述の microsoft.com でサイズに応じてデザインを変化させる際に使用しているテクニックです。また、Tyson は ブログ記事 (英語) で、ポリフィル ライブラリで使用可能な機能を支える理論を説明しています。Tyson のチームがポリフィル コードベースで行った最適化の一部を紹介します (幅広いブラウザーで機能します。Internet Explorer 6 でも有効です)。

1. DOM の準備完了前に読み込んでおく必要のある画像 (ページ コンテンツに必須の画像) を開発者が指定できる。
2. ページの残り部分の準備完了後に読み込む画像 (10 秒経過後に切り替わるスライド ショーの画像など) を開発者が指定できる。
3. ブラウザーのサイズ変更時に新しい画像をダウンロードして入れ替えるかどうかを開発者が指定できる。

ブログ記事には、ポリフィル API で開発者に公開されているすべての最適化についての説明があります。

テキスト

サイトではテキストを主に 2 つの方法 (具体的には本文とヘッダー) で使用して、ユーザーに構造とコンテンツを伝えます。これらのテキストを異なるコンテキストで拡大/縮小する方法を考えることも重要です。

本文のテキストで特に興味深いのは、記事やブログなど、ユーザーが閲覧する文字コンテンツを大量に掲載する場合です。モバイル ユーザーは、同じ 500 語の記事を、デスクトップ、TV、および 320 ピクセル幅の画面で読めることを望むため、サイト開発者としては、判読性と利便性 (多すぎないスクロール回数) のバランスをとる必要があります。記事本文の幅は画面サイズに合わせて拡大できますが、その他にも、大型画面のユーザーには文字を大きくしたり、行間を広げるなどして、判読性を高めることができます。

テキスト ブロックは、1 行に 33 文字程度が通常最も読みやすいため、サイトに長い記事が多い場合は、文字の大きさをレスポンシブに最適化すると、ユーザーのエクスペリエンス全体を向上できます。

次の例では、CSS3 メディア クエリの max-width を使用して、段落テキストの判読性を段階的に高めています。

/* pack content more tightly on mobile screens to reduce scrolling in really long articles */
p {
  font-size:0.6em;
  line-height: 1em;
  letter-spacing: -0.05em;
}
 
@media screen and (max-width:800px) and (min-width:400px)
{
  /* intermediate text density on tablet devices */
  p
  {
    font-size:0.8em;
    line-height: 1.2em;
    letter-spacing: 0;
  }
}
 
@media screen and (min-width:800px)
{
  /* text can be spaced out a little better on a larger screen */
  p
  {
    font:1em 'Verdana', 'Arial', sans-serif;
    line-height: 1.5em;
    letter-spacing:0.05em;
  }
}

AListApart.com は、レスポンシブに文字の大きさを変えている優れた例です ( ここを参照)。

また、サイトではコンテンツを分けるために見出しを使用して、ユーザーがサイト ページをざっと眺めて情報と機能の構造をすばやく把握できるようにします。見出しには大きな文字を使い、余白や埋め込みを追加するのが一般的です。

HTML のヘッダー (具体的には、<h1>、<h2>、およびこれに類するタグ) には通常、大きな font-size 属性だけでなく、ゆったりとした余白と埋め込みを使用するスタイルを自動的に設定し、見出しが目立ち、コンテンツの流れを分けるようにします。

これに似たテクニックを使用し、利用可能なデバイスの画面領域の機能として、見出しに使用するテキスト サイズ、余白、埋め込みなど、間隔に関する属性のサイズを縮小できます。また、これを実現するために、 FitText などのオープン ソースのソリューションも使用できます。

フォーム フィールドの最適化

サイトでユーザーにフォームへの入力を求める場合、タッチ デバイスを使用しているユーザーの操作を最小限に抑えるようにします。これは、長いテキストの入力を求める場合に特に必要です。

HTML5 では <input> タグの type 属性が拡張され、開発者がテキストボックスにセマンティクスを追加できるようになっています。たとえば、ユーザーが連絡先フォームを入力する場合、電話番号入力は <input type= "tel" />、電子メール アドレス フィールドは <input type= "email" /> とマークアップできます。

最新のブラウザー、特にタッチ対応デバイスのブラウザーは、この属性を認識して、それに応じてタッチ スクリーン キーボードのレイアウトを最適化するようになると考えられます。たとえば、ユーザーが電話番号フィールドをタップした場合にはブラウザーのタッチ キーボードに目立つようにテンキーを表示し、電子メール アドレス フィールドをタップした場合にはタッチ キーボードに @ キーや .com キーを表示して、入力の手間を最小限に抑えるという具合です。これは微調整にすぎませんが、タッチスクリーンの携帯電話やタブレットでサイトにアクセスしたユーザーのフォーム入力エクスペリエンス全体が向上します。

まとめ

今回は、レスポンシブ デザインの最も一般的なシナリオに対応する戦略として、グリッド レイアウト、帯域幅に応じた画像のサイズ変更、およびテキストとフォーム フィールドの最適化を取り上げました。Web 開発コミュニティでは、レスポンシブ デザインで新しく発生する課題を解決するためのテクニックの評価が続けられています。たとえば、W3C の HTML ワーキング グループは、高品質ディスプレイ用の画像選択の処理とダウンロードに関して相反する提案 (具体的には srcset 属性提案と picture 要素提案) を評価しています (たとえば、Retina ディスプレイのノート PC には、これまでの Retina ディスプレイと同じ参照ピクセルを表示するが、多くのハードウェア ピクセル数を使用するなど)。

今回説明したテクニックはすべての最新ブラウザーで機能し、使用しているデバイスに関わらずサイトにアクセスしたユーザーにすばらしいエクスペリエンスを提供します。現在の利用者には、スマート フォン、タブレット、PC、コンソールなど、さまざまな購入の選択肢があり、ハードウェアの状況も常に変化し、進化しています。2013 年以降の最新デバイスからのトラフィックにも対応できるよう、サイトを準備しましょう。

---

この記事は、Internet Explorer チームによる HTML5 技術シリーズの一部です。3 か月間無料の BrowserStack クロスブラウザー テスト ( https://modern.IE) を使って、この記事の概念をお試しください。

---

執筆者紹介

Rahul Lalmalaniは、マイクロソフトでエンジニアとしての勤務経験があり、現在はフリーランスでアプリと Web 開発を行っています。ホームページは RahulJL.com (英語) で、連絡先は @quasirahul (英語) です。