メディアクエリ:幅とデバイス幅

多くの場合、人々はデバイスの幅(width)とデバイスの幅(device-width)の違いを理解していません(さらに、デバイスの最小(min-device-width)と最大幅(max-device-width)を使用した例もあります) CSSメディアクエリ この誤解により、コードの記述が不十分になり、開発者の作業が大幅に増えます。 この質問は、SitePointフォーラムでは非常に一般的であるため、すべてを詳細に説明します。 この記事ではこの問題に対処します。また、レスポンシブサイトを作成する際にどのオプションを使用する必要があるかについても詳しく調べます。



キー定義



「デバイスの幅」と「幅」に基づいてメディアクエリについて話すときの意味を判断しましょう。 次の引用は、メディアクエリに関するMDNの記事から引用されたもので、「幅」の定義があります。



環境プロパティ「幅」は、出力デバイスの表示面の幅を説明します(たとえば、ドキュメントウィンドウの幅またはプリンターのページウィンドウの幅)





そして、これがMDNが「デバイス幅」を定義する方法です。



出力デバイスの幅を説明します(ドキュメントウィンドウなどの表示領域だけでなく、全画面またはページを意味します)




それで、これは本当に何を意味するのでしょうか? 簡単に言えば、「幅」と「デバイスの幅」は、表示領域の幅全体ではなく、デバイスの幅を指します。これはまったく異なる概念である場合があります。 関心があるのは、デバイスの幅に関係なく、表示領域の幅だけです。



この場合、幅とデバイスの幅の主な違いは、デバイスの幅が特定のデバイスの表示領域に常に対応するとは限らないことです。



ほとんどのタブレットとモバイルデバイスには、1ピクセルのCSSごとに1ピクセルのデバイスがあるとは限りません。 たとえば、iPhone 4の標準表示領域は640×960であることを知っておく必要があります。 つまり、この例では、iPhone4のデバイス幅は320×480です。 実際のところ、Appleはすべてのサイトがレスポンシブに作成されているわけではないことを理解しており、すべてのユーザーに適していると考えています。 つまり、表示領域にメタタグがない場合、iPhone4はサイトを取得し、幅980pxであるかのように表示し、320pxの幅で画面に押し込みます。その結果、ユーザーの観点から、サイトは縮小表示されます。



はじめに



まず、サイトをレスポンシブに変換し、メディアクエリを使用するすべての場合と同様に、サイトのセクションにメタフィールドタグを配置する必要があります。 基本的な標準バージョンを以下に示します。



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







このスニペットがページに表示されるとすぐに、異なるデバイスでページを表示すると、異なるメディアクエリがトリガーされます。 これがないと、特定のデバイスでページを表示するときに、ページの小さなバージョンとして表示されます。 デバイスは、サイト全体を320ピクセル幅の画面に圧縮しようとします。 そして、これはあなたにとってもユーザーにとっても良くありません! ユーザーは、コンテンツを見るためにサイトを増やすことを好みません。そして、彼らは間違いなくそれを前後にスクロールしたくありません。



たとえば、標準の表示領域の幅が980pxのiPhone 4を見てみましょう。 メタタグがないと、メディアクエリを使用しようとしても何も起こらず、デバイスは標準の表示領域に正しくアクセスできません。 ほとんどのメディアクエリの評価は500ピクセル以下です。 これは通常、単純なmax-widthメディアクエリを使用して行われます。 メタタグがないと、iPhone 4は980px幅のバージョンのサイトを引き続き表示するため、このリクエストの効果は得られません。 以下の例を見てみましょう。



 body { background: white; } @media screen and (min-width: 980px) /* Desktop */ { body { background: red; } } @media screen and (max-width: 979px) /* Tablet */ { body { background: blue; } } @media screen and (max-width: 500px) /* Mobile */ { body { background: green; } }
      
      







iPhone 4を使用して作成された2つのスクリーンショットが下に添付されています。両方のページには上記のCSSがありますが、1つはメタビューポートタグを使用し、もう1つは使用しません。



img








上記のページにはメタタグが含まれていないため、背景は赤で表示され、500pxモバイルメディアリクエストを使用する代わりに、980px幅の標準表示領域をシミュレートします。



img








この場合、メタタグが配置され、iOSは必要に応じてページを正しく表示します。320pxの幅に基づいており、メディアクエリが期待どおりに機能できるようにします。



デバイス幅を選択する理由



正直なところ、この記事のタイトルは、最初はデバイス幅を使用しないことを意味します。 ただし、device-widthには代わりがあります。 特定のデバイス用のサイトを構築している場合、はい-デバイス幅を使用する必要があります。



CSSとRWDの観点から見ると、良いサイトとは、実際には「デバイスにとらわれない」サイトであり、個々のデバイスの幅にふさわしくないサイトです。 さまざまな「タイプ」のデバイス(タブレットや携帯電話など)の個々のコントロールポイントをターゲットにするには、表示領域の特定の幅でコンテンツがどのように表示されるかに注目し、メディアクエリを適切に変更します。 したがって、コントロールポイントを指示するのはデバイスではなく、レイアウトとコンテンツであり、最終的にこれは、ユーザーの観点とユーザーの観点の両方から最適な結果につながる可能性があります。



これが、非常に多くの人々がレスポンシブデザインの作成に問題を抱えている理由であり、それが難しいと不平を言う理由です。 しかし、個々のデバイスのデザインを作成しようとすると、意図的に負けた戦いに巻き込まれます:(すべてをカバーするために)考慮しなければならないデバイスの数が多すぎて、単にすべてを不良コードに減らします。 また、デバイスの幅を使用することにした場合は、方向(縦または横)に個別のルールも設定する必要があります。デバイスを横にしただけではデバイスの幅は変わりません。 これにはさらに多くのコードが必要です。これはさらに頭痛の種です。



ただし、別の可能なオプションを見てみましょう。



「幅」はどうですか?



私は、多くの経験豊富な開発者と同様に、すべての可能な画面サイズから期待どおりに動作する完全にレスポンシブなページが、すべてのデバイスで最も効果的なレイアウトを取得する最も簡単で最も収益性の高い方法であると考えています。



完全にレスポンシブで柔軟なページを作成するには、開発者はすべての表示領域が考慮され、必要に応じてコンテンツとデザインに従ってページの構造とサイズが変更されることを確認する必要があります。



完全にレスポンシブなページに必要なのは、柔軟性のあるWebサイトと、標準範囲のモバイルデバイス、タブレット、コンピューター+表示領域を対象とするいくつかの思慮深いメディアクエリだけです。 FoundationのMedia Queriesを使用することを好みます。これは最も正確で、必要なすべての表示領域をカバーします。



もちろん、開発中の他のすべてと同様に、幅ベースのクエリのみを使用することは、すべてのレイアウトの問題の解決策ではありません。 むしろ、さまざまなバグや奇妙な表示を求めてモバイルデバイスでテストする必要があります。 ただし、さまざまなモバイルデバイスですべてがどのように表示されるかを確認できるのは、ブラウザウィンドウのサイズを変更するのと同じくらい簡単です。



テストには、Chrome Responsive Web Design Testerの拡張機能を使用します。 特定のデバイスを選択できます。 デバイスのサイズと、そのようなデバイスでのページの表示方法が表示されます。



言及したいもう1つの小さな利点は、幅ベースのクエリを使用すると、将来のデバイスでサイトが完全に表示されることです。 特定のデバイスではなく、よりグローバルなもの(表示領域の合計サイズ)に導かれるため、これはかなり有望なアプローチです。



結論として



メディアクエリでデバイス幅を使用する予定ですか? 与えられた議論は十分に説得力がありませんでしたか? デバイスの通常の「幅」と表示領域を使用すると、レスポンシブデザインが簡素化され、最終的にはほぼ常に使用する必要がある最適なオプションになります。



Habré読者向けの便利なPaystoソリューション:
今すぐクレジットカードで支払いを受けましょう。 サイト、IPおよびLLCなし。

オンライン企業からの支払いを受け入れます。 サイト、IPおよびLLCなし。

サイトの会社からの支払いを受け入れます。 ドキュメント管理とオリジナルの交換。

法人との販売およびサービス取引の自動化。 計算の仲介なし。






All Articles