レスポンシブ対応のレイアウトを実装する最新テクニックを解説、モバイルファーストとデスクトップファーストの現状

モバイルファーストとデスクトップファーストの現状、それぞれのワークフローを解説し、今日のレスポンシブ対応のレイアウトを実装するより良いアプローチ方法について紹介します。

ビューポートサイズとは関係ないすべてのデバイスで共通の基本スタイルを優先的に記述する方法、メディアクエリを使用しない方法、モバイルとデスクトップの違いを考慮する必要がない方法など、最新の実装テクニックも解説します。

レスポンシブ対応のレイアウトを実装する最新テクニックを解説、モバイルファーストとデスクトップファーストの現状

The State Of Mobile First and Desktop First
by Ahmad Shadeed

下記は各ポイントを意訳したものです。
※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。

はじめに

実装にモバイルファーストとデスクトップファーストのどちらを採用するか、悩んだことはありませんか?

先日私はどちらを採用しているかTwitterでアンケートをしたところ、その結果は興味深いものでした。

  • モバイルファースト: 33.3%
  • デスクトップファースト: 21.9%
  • 両方のミックス: 24.7%

この記事では、モバイルファーストとデスクトップファーストそれぞれが何を意味するのかを探り、今日でも意味があるかを検証するとともに、今日のレスポンシブデザインの実装に役立つテクニックをいくつか解説したいと思います。

モバイルファースト・デスクトップファーストとは何を意味するのか

モバイルファーストとは、Webサイトを実装する際に、最初にスマホの小さいビューポートサイズ用のCSSを書き始め、次にCSSメディアクエリを使用して大きいビューポートサイズ(タブレットやデスクトップ)用にエクスペリエンスを変更することを意味します。

次のようなCSSを考えてみてください。

スマホで異なるpaddingがあるセクションがあり、ビューポートが大きい場合はpaddingをより大きくし、flexboxのラッパーにする必要があります。

上記のCSSはごく一部ですが、Webサイトやアプリ全体の規模で想像してみてください。

モバイルファースト: スマホ用のCSSを記述してから、デスクトップ用のCSSを記述

今度はデスクトップファーストを見てましょう。CSSは逆になります。

最初に大きいビューポートサイズ用のCSSを記述し、次にCSSメディアクエリを使用して小さいビューポートサイズ(スマホ)用にCSSを変更します。

デスクトップファースト: デスクトップ用のCSSを記述してから、スマホ用のCSSを記述

モバイルファーストのワークフローはどうあるべきか

デスクトップのサイズは考慮せずに、デベロッパーツールを開いて実装をはじめますか? それとも同期してはじめるべきですか? つまり、モバイルファーストでCSSを記述すると同時にデスクトップ用に拡張しますか?

2つのシナリオを考えてみました。

  1. まずスマホ用の全ページを実装する。スマホ用のページをすべて完成した後に、より大きいスクリーンサイズ用に拡張する。
  2. 並行して実装する。つまり、モバイルファーストからはじめて各セクションやコンポーネントを個別に実装する。その後に、サイズを大きくするために拡張する。

みなさんはどのように実装していますか? 私にとっては2番目の方法が優れています。理由としては、各セクションやコンポーネントを個別に処理する方が集中して作業できるからです。また、このプロセスにより、CSSを記述する際のミスを減らすことができます。

モバイルファーストではじめ、その後デスクトップ向けに拡張する場合、タブレット用とデスクトップ用のCSSを書き換える可能性があります。下記のモックアップをご覧ください。

スマホ・タブレット・デスクトップ用のUI

例としてヒーローセクションを取り上げましょう。

スマホではヒーローに背景画像がありますが、デスクトップでは背景は無地で、右端に画像があります。ご覧のとおり、CSSはモバイルファーストでfont-sizebackgroundを除いてあまり上書きはされていません。

ナビゲーションの実装はどうなっているのでしょうか? モバイルファーストのアプローチではどのように見えるのでしょうか? CSSは下記のようになります。

デスクトップ用のCSSと組み合わせたCSSの上書きの量がわかりますか? 量が多すぎて、あまりよろしくありません。

それだけではなく、これはCSSの詳細度の問題も引き起こすかもしれません。例えば、デベロッパーが下記のようなCSSで.nav__itemからborder-bottomを削除したいとします。

この場合、:not疑似クラスの方がより高い詳細度のため、機能しません。

:not疑似クラスを使用するため、より高い詳細度になります。

下記のいずれかを使用した場合にのみ機能します。

デスクトップファーストのワークフローはどうあるべきか

モバイルファーストと同じUIで、今度はデスクトップファーストを見てましょう。

デスクトップファーストの方がモバイルファーストに比べて上書きが少なくなります。これは意外だと思いませんか? その理由はmax-widthメディアクエリを使用して特定のデザインを特定のビューポート幅にスコープしているからです。

モバイルファーストでCSSを記述し、デスクトップ用に上書きするのではなく、その逆をおこなっています。

CSSの量を視覚的に比較してみましょう。
デスクトップファーストの方が量が少なく、上書きも少ないことに注目してください。

上: モバイルファーストのCSSの量
下: デスクトップファーストのCSSの量

スコープのスタイル: より良いアプローチ方法

はい、あります。私の場合、特定のアプローチに固執することはありません。むしろ、両方をミックスするのを好みます。つまり、基本となるスタイルを記述し、それからスマホとデスクトップで何が起こるかを考え始める必要があります。Elad Shechterの記事で、「基本を優先する」という方法が気に入っています。

実際にCSSで見てましょう。

ご覧のとおり、スタイルはビューポートのサイズごとにスコープされています。つまり、上書きする必要はありません。このアプローチはスマホとデスクトップで見た目が異なるコンポーネントの実装に役立ちます。

しかし、<section>などは多くの場合スマホとデスクトップのスタイルが非常に似ているため、ミックスしたアプローチを使用しても意味がありません。

レスポンシブデザインへのアプローチ方法

ある日を境に、モバイルファーストとデスクトップファーストの議論はそれほど重要ではなくなったと感じています。現在のCSSでは、メディアクエリのないCSSを使用してレスポンシブ対応のレイアウトを実装できます。

そうは言っても、モバイルファーストとデスクトップファーストの議論は、ビューポートサイズによって大きな違いがある複雑なコンポーネントを除き、特定のビューポートサイズで特定の要素を表示・非表示にするかどうか(ナビゲーションのトグルボタンなど)だけになると思います。

実際の例を挙げて、このコンセプトを解説します。

よくあるUI

スマホとデスクトップで大きな違いがあるコンポーネントは、ヘッダとナビゲーションです。その他のコンポーネントは若干の違いがあるだけです。ヘッダの実装はmin-widthmax-widthのメディアクエリを組み合わせることで、目的のビューポートサイズに合わせて各デザインのスコープを設定できます。

しかし、ヒーローセクションと記事のグリッドはベーススタイルを持ち、必要に応じてmin-widthを使用します。

このようなデザインは、どのような考え方で作られているのでしょうか? 厳密なことは何もありません。わたし達が手にしているデザインについてです。では、もう少しディテールを見てみましょう。

ナビゲーションのスマホでの表示

モバイルファーストのコンセプトをヘッダとナビゲーションに採用した場合、多くのCSS上書き(別名: 重複)が発生してしまいます。これはよろしくありません。ヘッダとナビゲーションのCSSは下記のようになります。

ヒーローセクションはflexboxを使用して、行と列のスタイルを処理したり、要素の並べ替えや移動をすることができます。

max-widthメディアクエリでスコープを設定して、order: -1;を1度だけ記述していることに注目してください。私は下記のように記述することもできます。

しかし、重複していることがわかりますか? flexboxでorderを使用してしまうと、見た目の順序とHTML内の要素の順序が一致しないので注意が必要です。

このプロセスを説明する視覚的なチャートです。

プロセスを説明する視覚的なチャート

ダブルブレイクポイントのメディアクエリは避ける

min-widthmax-widthのメディアクエリに同じ値を使用すると、気付きにくい・デバッグしにくい問題が発生します。

こういったメディアクエリをあなたはよく見かけるかもしれません。しかし、このCSSでは重要なブレークポイントである500pxでの検証を忘れています。2つのブレークポイントに1pxのギャップがあります。上記のCSSでは、500pxの時にナビゲーションもトグルも表示されません。

499pxと501pxでは期待通りに表示されるが、500pxでは何も表示されない

この1pxは、デベロッパーツールのモバイルモードで500pxのメディアクエリの値を手動で入力しないとデバッグが困難です。この問題を防ぐには、2つのメディアクエリで同じ値を使用しないようにしてください。

この問題は、私の著書「Debugging CSS」の43ページから拝借しました。

デザイナーにとってのモバイルファースト

私自身もデザイナーですが、さまざまな理由からモバイルファーストでデザインすることは好きではありません。

  • 制限があり、クリエイティブを発揮するのが難しい。
  • 高さが大きいデザインで作業すると、上下にスクロールし続けることになり、イライラする。

その一方、少なくとも私にとっては、デスクトップファーストでデザインする方がはるかに優れています。アイデアをすぐに試すことができますし、上下にスクロールしなくてもデザイン全体を見渡すことができます(モバイルファーストでデザインしている場合)。

デスクトップファーストでデザインを始め、スマホ用にデザインを変更することもできます。それが良い出発点となり、残りのページをモバイルファーストにしても構わないと思います。しかし、新規のプロジェクトでは、モバイルファーストでデザインを始めることは好ましくありません。

モバイルファーストとデスクトップファーストの違いを考慮する必要がないモダンCSS

最近ほどCSSの書き方が上手になったことはありません。レスポンシブデザインをはるかに簡単にする、現在および今後のCSS機能がたくさんあります。

flexboxのラッピング

Geoffreyの記事「How to Make a Media Query-less responsive Card Component」の中で、メディアクエリを使用せずにレスポンシブのカードコンポーネントを実装するテクニックを解説しています。ここではその基本的なコンセプトを説明しますが、詳細は記事をお読みください。

メディアクエリを使用せずにレスポンシブのカードコンポーネント

flex-basisに固定値を定義し、必要に応じてアイテムを拡大および縮小できるようにすると、メディアクエリを使用せずにコンポーネントを実装できます。

スクリーンサイズが小さい場合は、下記のように表示されます。

スクリーンサイズが小さい場合の表示

CSS Gridのminmax()

CSS Gridのおかげで、メディアクエリに依存しないレスポンシブのグリッドレイアウトが可能になりました。下記の例を考えてみましょう。

これは、各アイテムに200pxの最小幅を与えるレスポンシブのグリッドです。CSS Gridを使用しない場合は、メディアクエリを使用してビューポートサイズに応じて幅を変更する必要があります。

minmax()についてさらに詳しく知りたい時は、下記をご覧ください。

ビューポート単位と比較機能

CSSのビューポート単位とCSSの比較機能を組み合わせて使用することで、フォントサイズ、パディング、マージン、一部の要素のサイズなどを変更する必要性を減らすことができます。

コンテナクエリ

Chrome Canaryで、CSSのコンテナクエリが使用できるようになりました。このコンテナクエリを使用すると、メディアクエリを使用せずにさまざまなことができるようになります。

簡単な例を見てましょう。

コンテナクエリの実装例

上記は、コンテナの幅に応じて機能するレスポンシブなページネーションです。メディアクエリは必要ありません。

デモページ(Chrome Canaryでご覧ください)

終わりに

これはほんの始まりに過ぎません。この記事で見てきたようにモダンCSSを使用すると、メディアクエリを使用しなくてもレスポンシブ対応のレイアウトを実装することができます。ですから、モバイルファーストとデスクトップファーストのどちらを選択するかについて、そこまで考える必要があるのかということです。

この記事があなたのお役に立てれば幸いです。
コメントや提案があれば、@shadeed9までお願いします。

sponsors

top of page

©2025 coliss
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy