レスポンシブ

レスポンシブ画面への対応

スマホとパソコンの両方への対応

一般的なホームページの閲覧環境としては、今やスマホが主役の時代、ホームページの作り方もそのトレンドに対応せざるを得ない。もちろん、「PC専用」をコンセプトとして "シンプル・イズ・ビューティフル" も結構、それぞれに個性的なホームページも歓迎だが、八方美人的な画面作りを追求したい自分としては、スマホを切り捨てることは忍びない。

ここで、今まで取り組んできた自分なりのレスポンシブサイトの作り方を整理しておきたい。特殊な、例えば横長のカレンダーのようなものは、端からスマホ対応を諦めているが、そのような事情の無いページについては極力スマホ対応することとしたい。

対応デバイス

レスポンシデザインの対応デバイスとしては次のものを想定している。

・スマホ

・タブレット

・パソコン

・テレビ

・プリンター

タブレットについては、画面構成によって位置付けが微妙に変わる。パソコン、あるいはスマホと一緒に扱っても問題ない場合が多いと思うが、タブレットの存在感を存分に発揮できる画面もある。そんなときは、@mediaの階層をわざわざ3階層としてタブレット専用のCSSを用意したりする。

テレビは今のところはパソコンの延長線に位置付ければ良いとは思うが、今後、テレビに特化した画面デザインや機能が開発されると、インターネットにアクセスする媒体としてのテレビのポジションが変化する可能性がある。

プリンターについては、カレンダーの印刷を対象としている。カレンダーは画面で見る時と紙媒体に印刷して壁に貼る時を比較すると、暦としてのデターは同じでデザインが全く異なるという特殊な状況になる。これは同一のHTMLから異なった媒体に異なったデザインで表示するというテーマにピッタリな素材だと思う。

画面幅については、最大値を1000px程度とし、最小値を320pxとしている。最小値については、320pxより狭い表示域の場合は、デザインの乱れにつながる折り返しが発生するリスクが高まるものの、その場合でも最低限の可読性は維持されるようにしている。

HTMLの共用

デバイスの違いを画面幅だけではなくて、画面のアスペクト比、操作性や閲覧時の体勢などの特性にまで着目し、それぞれにベストのにデザインを追求すると。HTMLから別々に設計するのが良いと思う。その方が目的に照らして合理的と思えるからだ。

しかし、そこまでデバイスタイプの個性を追求するのではなくて、どのデバイスにおいても同様のコンセプトのもと、使い勝手を統一することを重視すると。おのずとHTMLを共用し、CSSにおいてそれぞれのデバイスタイプの個性を表現する方法に落ち着くものと思われる。最新のCSSはデザインに対する摘要範囲が広く、同一のHTMLから思い切ったデザインの変更に対応することができる。自分の経験では、HTMLを別にしたいと感じたことはない。

CSS切換えのブレークポイント

@mediaを使って画面幅に対応してCSSを切り替える場合、ブレークポイントをどの様に設定するかについては固定的な値はなく、コンテンツの制作者それぞれの考え方によって設定されているように思う。CMSを使う場合などは、もしかしたら基本的な設定値として推奨される値があるのかもしれない。CSSを使用しない自分にはわからないことだが...

自分の場合は、2階層、3階層の場合を含めて主に480px、600pxなどを基本とし、ページごとに適切な値を設定している。ページによって、ブレークポイントにあまり左右されないものもあり、場合によっては1つのCSSのみで320px~1000pxまで対応できるようなページもある。一方で、文字情報を含む画像ではサイズの増減に対する耐性に限界があり、CSSを切り替えるポイントがおのずから定まる場合がある。そんなときは、基本にとらわれずにそのページに最適なポイントでCSSを切り替えるようにしている。

CSS階層の記述方法

最近は、モバイル向けのCSSを最初に記述し、続いて、そのCSSに対する変更部分をパソコン向けCSSとして記述する、いわゆるモバイルファーストの記述方法が多いようだ。後段に差分のみ記述することによって、全体の行数を削減することができる。

ただ、この記述方法では、モバイル向けのCSSを変更した場合、それが後段のパソコン向けCSSにどのように影響するかを評価して、それに対する対策をとらなければならない。つまり、多くの場合両方のCSSを修正しなければならないわけで、それなりの作業負担となる。後段のパソコン向けの修正のみであればモバイルに影響はないので、修正の頻度を考慮してモバイルファーストかPCファーストかを決める必要がある。

このような事情をシンプル化する方法として、自分は後続のCSSに差分を記述するのではなく、すべての項目を記載するようにしている。例えばモバイルファーストの場合、最初にモバイル向けCSSを記述し、検証が終了して動作に問題ないことを確認できれば、そのまま全行をパソコン向けCSSとして後段にコピーし、その後パソコン向けに修正を行って完成させている。後日、修正が発生した場合は、必要に応じてモバイル向け、パソコン向けの双方を修正する。このようにすることによって、それぞのCSSを独立したものとして管理できる。行数は増えるものの管理負担ははるかに少なく、CSS修正の連動ミスによるもらい事故をほぼ完全に抑制することができる。

※掲載記事及び写真に係る著作権は著者に帰属します。著作権を侵害するような利用を禁止します。掲載記事及び写真の全部または一部を複製、蓄積、出版、送信、頒布および改変する等、著者の権利を侵害する利用をすることはできません。