ピクセルディフェンスワードメディアクエリ

Webページのレイアウトに関する出版物を読んでいるときに、メディアクエリでピクセルを使用しないことを繰り返し推奨しています。 たとえば、以下はHabréに関するごく最近の記事からの引用です。



固定サイズを使用する代わりに、相対単位を使用してブレークポイントを定義することをお勧めします。 レイアウトでの相対的なサイズの使用の主題は、すでにハブで繰り返し開示されています。 ここに記事の部分的なリストがあります： here 、 here 、 here 。 最も重要な引数のみを説明します。これにより、ブラウザーはユーザーが設定したズームサイズのレベルに応じてデザインを変更できるようになります。



メディアクエリでピクセルを使用すると、レイアウトに害が及ばないだけでなく、emを使用するよりも利点があると言ったらどうでしょうか。

---

この記事では「ブレークポイント」という用語を使用しています。 プログラマーにとって、彼は耳を傾けます。なぜなら、プログラミングの世界ではそれは完全に異なるものを意味するからです。 フロントエンド開発の英語圏では、これは確立された明確な用語です。 ブラウザウィンドウの幅を意味し、それを超えるとページレイアウトが変更されます。 「メディアクエリ」という用語のように、ロシア語に変形しませんでした。

ピクセルを介したメディアクエリはズームに干渉しません

ピクセルに対する「最も重要な引数」から始めましょう。おそらく、古いブラウザーでページが拡大されると、メディアクエリのピクセル値は機能しません。 これは単なる嘘です。 ピクセルメディアクエリは、すべての一般的なブラウザーでズームを使用すると正常に機能します。 Internet Explorer 8でも！



はい、IE 8 はメディアクエリをサポートしていません 。 ただし、プロジェクトで顕著なRespond.js ポリフィルを使用すると、IE 8はメディアクエリを完全にサポートしてそれを表示します。 そして、あなたは何を知っていますか？ ズームでも正しく動作します。 Ctrlキーを押しながらマウスホイールを回すと、ページレイアウトが再構築されます。 たとえば、IEのズームアニメーションが右側に表示されているサイトでは、次の形式のメディアクエリを使用しました。

@media (min-width: 401px) { #header-first { float: left; width: 47.82609%; margin-right: 4.34783%; }}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

より古いIEは手元にありませんでしたが、それは問題ではありません-ロシアでのIE7のシェアは0.7％のみで、IE6-0.1％であり、それは大部分が国家機関によるものです。



そのため、メディアクエリでピクセルを拒否する主な理由と呼ばれる問題は、単に存在しません。 どうやら、これは口コミで盲目的に伝えられる単なる伝説であり、フロントエンドの第一人者の有力な出版物やブログの出版物に定期的に入ります。



UPD 2013-10-31 ：Safariメディアクエリがズームで機能しないことがわかりました。 ただし、どの測定単位を使用しても機能しません。 KrylCWは、これがSafari 7にも当てはまることを確認するのに役立ちました。さらに、データによると、Yandex.Browser for MacOS（現在のバージョン1.7.1364.22074（0b6c012））でズームするとメディアクエリが機能しませんが、ズーム後に更新すると機能しますページ。



WindowsでYandex.Browserを試しました（現在のバージョンは13.10.1500.8765（e504cce）です）。 そこには別の方法があります：ピクセルベースのメディアクエリは正しくズームしますが、相対的なものはそうではありません！ ページをズームすると、メディアクエリが正しく機能します。 これがステップ175％→200％で発生するとします。 次に、反対方向にズームすると、200％→175％ステップでのメディアクエリは機能しませんが、100％→90％ステップで機能します。 そして、ズームを前後にすると、各サイクルとのギャップが大きくなります！



試してみたい人のために、彼らは自分自身でテストをリベットしました： ピクセル 、 ems 。

基本フォントサイズを変更すると、emsで設定されている場合、すべてのブレークピオンが「移動」します

この状況を想像してください。 チーフまたはクライアントがあなたに電話して言います。 妻は何も読めません、大きくしてください。」 議論するのは無意味です。 悲しいことに息を吸って、デザイン部門のドアを見て、CSSコードを開いて、ベースフォントサイズを13pxから16pxに増やします（そうです、とにかくベースフォントサイズはピクセル単位で設定されます）。



どうしたの？ emsで指定されたすべてのブレークポイントがシフトされます。 現在、タブレットでは、サイトは1つの列に表示されています。これは、電話でのみ表示されていた方法です。 これは次のようになります （ウィンドウの幅を900px未満にし、恐ろしくします）。 これは嬉しいですか？ このような状況に陥った場合、急いですべてのメディアクエリを書き直そうとするか、プロジェクトでプリプロセッサを使用しない場合は完全な声で誓うと主張する準備ができています。



はい、 コンテンツファーストのイデオロギーを認識しています。どのイデオロギーに応じて、消費に適したコンテンツの規模に応じて、ブレークポイントをシフトする必要があります。 これにより、CSSコードでブラウザーを備えた数十億のさまざまなサイズのデバイスを考慮する必要性から逃れることができます。 代わりに、フォントサイズに関連する単位でブレークポイントを設定し、コンテンツが混雑しすぎたり、広すぎる場合にサイトを強制的に再構築します。



しかし、自分に嘘をつかないでください。 商用プロジェクトを実行するには、最も人気のあるデバイスで厳密に定義されたレイアウトが必要です （またはクライアントが必要です）。 たとえば、ポートレートモードのiPadの1列の携帯電話に表示されるサムネイルは、3列のグリッドに変わります。 フォントサイズを変更しても壊れないようにします。 デザイナーがiPadに横向きモードのサイドバーを配置することを決定した場合、サイトで使用されているフォントサイズに関係なく、サイドバーを配置する必要があります。 狭いサイドバーのフォントが大きすぎる場合は、サイドバーを取り除くよりもフォントを減らす方がいいでしょう。



はい、コンテンツ指向のサイトの場合、テキストの列の幅は快適な制限を超えてはなりません。 しかし、最初に、この幅にはかなり広い範囲があります。 45〜75文字の推奨事項を知っています。つまり、列の幅を最大66パーセントポイントまで簡単に変更できます。 第二に、なぜそのような幅が標準と見なされるのですか？ 光沢のある雑誌を開くと、15文字幅のテキストの列に出くわすことが非常に多く、これが悪いことは誰にも起こりません。 たとえば、満員のメトロカーで雑誌を読んでみると、雑誌を巻くのにとても便利です。 また、Habréでは、テキストの列の幅は75文字から約115文字であり、Habrの訪問者の大多数は、テキストがちょうど115文字の幅であると考えています。



ところで、ここで概念の代替に気づきましたか？ ピクセルベースのメディアクエリを使用して、最適なテキスト幅を作成することもできます。



そして最後に、すでに完成したプロジェクトのすべてのフォントのサイズを、他のすべてを再設計することなく、どのくらいの頻度で変更する必要がありますか？ また、すべてのフォントがem'ahにあり、クライアントがメインテキストのみフォントを増やすことを要求した場合はどうでしょうか。 申し訳ありませんが、最後の質問は記事のトピックには適用されません。

emsで定義された隣接メディアクエリは重複しています

一方の最大幅が他方の最小幅と一致する場合、一対のメディアクエリを「隣接」と呼びます。 天井から取った例を挙げましょう。

 .container { color: black; background-color: white; }} @media (max-width: 40em) { .container { color: red; }} @media (min-width: 40em) { .container { background-color: red; }}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

正確に40em幅のブラウザでこのサイトを開くと、「ラッキー」な人が訪問者にどのように表示されると思いますか？



オーバーラップは1ピクセルのみですが、そうです。 サイトの訪問者が突然このような画面の幅を見つけた場合、ページとデザインのレイアウトは、完全に読めないほどに歪む可能性があります。



ピクセルを使用する場合、問題は基本的で完全に信頼できる方法で解決されます。

 @media (max-width: 600px) { /* ... */ } @media (min-width: 601px) { /* ... */ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

多数意見に盲目的に従い、emsでメディアクエリを作成し、重複を見つけたとき、同じ方法で問題を解決しようとしました：（ (min-width: 20,1em)



。 オーバーラップはギャップに置き換えられました。特定のウィンドウ幅では、どちらのメディアクエリも適用されません。 私は20.01を試し、次に20.001を試しました...大砲のフォークを使用して、小数点以下の残りの値を見つけることができました。



私はすぐに、このバランスを取り戻すだけでは十分ではないことに気付きました。 基本的なフォントサイズごとに、残りは異なります。それ以外の場合は、間違いなくギャップまたはオーバーラップがあります。 しかし、SASSの優れたコマンドを持ち、emsの任意の値の正しい残りを選択してmixinを作成できるため、私は驚かされませんでした。 入力でいくつかのemを取得し、ベースフォントサイズで乗算し、1を追加し、ベースフォントサイズで除算します。そして、出力で安全な値を取得します。



この場所では、この道がどういうわけか...間違っているという漠然とした感じがするはずです。 少なくともそれは私に生じました。 私は側から状況を見てみて、質問をしました：私は実際に何をしていますか？



そして、これは次の議論に私たちをもたらします：

メディアクエリのEmは、2つのピクセル値の間の中間です：ベースフォントサイズとブラウザーウィンドウの幅

前述のように、基本フォントサイズは常にピクセル単位で指定されます。 それ以外の場合、ブラウザはどのフォントサイズが1 emに等しいと見なされるかを単純に知りません。 基本フォントサイズが指定されていない場合、通常のブラウザは16ピクセルを使用します。 em'ahで指定されている場合、ブラウザは同じ16ピクセルを乗算します。 同じことが他の相対単位にも当てはまります。1ptは4/3 pxで、1センチメートルのピクセル数がOSに書き込まれます。



メディアクエリの最小幅と最大幅は、ウィンドウの幅にマッピングされます。これは、ブラウザでは、整数の仮想ピクセルで指定されます。 たとえば、4番目のiPhoneの場合は320×480で、iPhone 5の場合は320x568です。



emsでメディアクエリを設定することにより、最初にピクセルからemへの変換を頭の中で行い、次にemからピクセルへの変換を行って、このブレークポイントに実際に到達する画面の幅を把握します。



そのように自分を拷問する必要はありません。 ピクセルを使用するだけです。

ピクセルベースのメディアクエリを使用しても、「コンテンツファースト」アプローチを放棄することにはなりません。

メディアクエリでピクセルを使用するという事実は、メディアクエリを設計する際にコンテンツから派生する能力を奪うものではありません。



インターネットでメディアクエリを適切に実行する方法に関する記事は多数ありますが、このトピックはこの記事の範囲外です。 したがって、私は自分自身をいくつかの推奨事項に限定し、サブタイトルの論文を強化しようとします。



この時点で、記事の客観的な部分が終了し、控えめな個人的な意見が始まります。他の方法が間違っていることを意味するものではありません。



まず、各画面幅に個別のCSSファイルを使用しないでください（IEサポートはポリフィルで提供できます）。 サイトページで使用されるモジュールに従ってコードを構造化し、モジュールごとにメディアクエリを個別に配置します。 これにより、各モジュールの制御が容易になり、コードサポートが簡素化されます。



第二に、レスポンシブレイアウトを設計するときは、コンテンツに基づいて構築します。 この方法は非常に単純です（私が発明したのではありません）。 最初に、最小画面幅に焦点を合わせてモジュールを構成します。 もちろん、モジュールは「ゴム」でなければなりません。 次に、モジュールがお粗末に見えるまでブラウザウィンドウを拡大します。 この時点で、ブレークポイントを設定し、その幅に反転します。 サイトの最大幅に達するまで繰り返します。



ところで、サイトの最大幅を980ピクセルの狭い列に制限しないでください。 大型モニターを使用している場合は、1920ピクセルの幅でサイトがどれだけ豪華に見えるかを確認してください。 小さいモニターを使用している場合は、神のために5000ルーブルをこすり落とし、大きなものを購入してください。 これはあなたのプロフェッショナルツールです！



第三に、プリプロセッサを使用します。 プロジェクトにプリプロセッサを実装することは、特に初心者にとっては簡単ではありませんが、非常に多くの手間を省くことができます。



任意のプリプロセッサで対応できますが、 Sassを強くお勧めします。 Sass言語自体の方が優れているからではなく、機能がほぼ同等であるためではなく、ライブラリのエコシステム全体があるためです。 一般に「 コンパス拡張」と呼ばれるライブラリは、機能が非常に豊富であり、互いに効果的に相互作用します。



第四に、多数の多様なメディアクエリに埋もれないようにするために...

画面サイズスケールをスライスにスライスする

メディアクエリを操作するタスクを容易にするために、 Breakpoint Slicer拡張機能を構築しました（これは、 Breakpointを使用します -これは、メディアクエリを操作するための非常に強力で汎用的な拡張機能です）。



ブレークポイントスライサーのアイデアは非常に単純です。 たとえば、400px、600px、800px、1050pxなどの短い間隔でブレークポイントを設定します。 モジュールは、これらのスペースに順番に番号を付けます。

1. 0〜400
2. 401-600
3. 601-800
4. 801-1050
5. 1051 —∞

次に、Sassコードで、メディアクエリを挿入するのに必要な間隔を指定します。

• at(2)
  
  
  
  -同等(min-width: 401px) and (max-width: 600px)
  
  
  
  
• from(2)
  
  
  
  -同等(min-width: 401px)
  
  
  
  
• to(2)
  
  
  
  -同等(max-width: 600px)
  
  
  
  
• between(2, 4)
  
  
  
  - (min-width: 401px) and (max-width: 1050px)
  
  
  
  

これにより、範囲ごとにモジュールのスタイルを迅速かつ効率的に配布できます。 多数のギャップを使用することで、過剰な特異性に陥ることなく、すべてのクラスのデバイスをカバーできます。



Breakpoint Slicerの使用について質問がある場合は、バグトラッカーで遠慮なく質問してください（英語を知っている場合は、英語の方が良いでしょう）。