web-dev-qa-db-ja.com

Emベースのメディアクエリへの切り替え

WebKit page-zoom bug が 修正済み になったので、ピクセルベースのメディアクエリではなくemベースのメディアクエリを使用する主な理由は何ですか？

バウンティ

非常に多くの著名な [〜＃〜] css [〜＃〜]frameworksandwebdevelopers そうするのに十分な理由があるに違いないと確信しているemベースのメディアクエリを使用します。

私が知っている1つの利点は、ユーザーがブラウザのデフォルトのフォントサイズを変更すると、コンテンツが squeezepage-zoom修正によって解決された問題と同様の方法で 。ズームではなくデフォルトのサイズを実際に変更したことを示すデータはありますか？

注

私の質問をより集中するために、2つの周辺アイテムを削除しました。 元の投稿 は、@ nwaltonの素晴らしい answer に視点を追加します。

cssresponsive-designmedia-queries
62
cantera

  1. 最新のブラウザでは、ブラウザがズームを正しく処理する場合、emベースのメディアクエリとピクセルベースのメディアクエリに違いはありません。 実際、あるプロジェクトでemベースのメディアクエリに問題がありました。メディアクエリの1つでベースフォントサイズが変更され、他のすべてのメディアクエリが台無しになったためです。それはばかげた間違いだったかもしれませんが、あなたはアイデアを得る。ピクセルを使います。 以下のアップデートを参照してください。ズームは最新のブラウザには影響しませんが、基本フォントサイズは影響します。

  2. 62.5％のテクニックとremで遭遇する可能性がある最大の問題は、それを理解していないブラウザーに遭遇する場合です。心配な場合は、対応能力の低いブラウザにフォールバックを追加し、最新のブラウザにremを設定できます。

    html { font-size: 62.5%; }
body { font-size: 14px; font-size: 1.4rem; }
h1   { font-size: 24px; font-size: 2.4rem; }

  3. ブラウザがpxとemを処理する速度に違いがある場合、それは目立ちません。ブラウザは、CSSを非常に高速に計算します（JSよりもはるかに高速です）。したがって、おそらく心配する価値はありません。

測定の長所、短所、および用途

px

過去にメディアクエリにpxを使用したのは、信頼性が高く、あなたが言うように、うまくズームできるからです。 Update：ただし、ユーザーがデフォルトのスタイルシートを変更すると、メディアクエリは無効になります。

  • CSSカスケードに依存しない
  • ほとんどの場合、非相対測定（ブラウザがフォントピクセルを測定する方法によって異なります）
  • 最新のすべてのブラウザーでズーム可能

em

Emは、柔軟なグリッドと測定を行うのに最適です。たとえば、emsでコンテナの幅が指定されている場合、1つの宣言でメディアクエリのコンテナとそのコンテンツのサイズを比例的に変更できます。

  • CSSカスケードに応答する
  • コンテナのフォントサイズに関連
  • 最新のすべてのブラウザーでズーム可能

この例では、フォントのサイズを変更すると、それに比例してコンテナのサイズも変更されます。

h1.title {
  font-size: 2em;
  width: 20em;
  background-color: #baff1e;
}

@media (min-width: 400px) {
  h1 {
    font-size: 2.5em
  }
}

レム

私は実際にremをあまり使用していませんが、多くの人がそれを好む理由を見ることができます。相対的なユニットのパワーはありますが、CSSカスケードを投入するときに発生する可能性のあるクレイジーなことに対処する必要はありません。

ブラウザのベースフォントサイズに基づいてサイズを調整することは、Web標準のことのように思えます。これは、最適なベースフォントサイズが16ピクセルではないブラウザを許可するためです。しかし実際には、それは一種の別の方法で機能します。私が見たものから、ブラウザは16pxが基本フォントサイズとして誰もが期待するものであり、そのCSS測定の実際のサイズをブラウザで適切に見えるように設定します。

  • CSSカスケードに依存しない
  • ベースフォントサイズに相対的
  • 最新のすべてのブラウザーでズーム可能

62.5％テクニックに関するメモ

これはかなり前からありましたが、今は使用しない理由はわかりません。 2007年のA List Apartの記事 があり、そこでいくつかのテストを行い、ベースフォントが100%およびテキストのサイズはemでした。しかし、そこにリストされているブラウザーの制約のいずれかが本当に関連している場合、私は驚くでしょう。基本フォントサイズを10px、しかしそれはおそらく個人的な好みです。

更新

いくつかのテストを行った後、メディアクエリにピクセルを使用するという習慣を逆にしています。私は今emを推奨しています：

  1. ユーザーは基本フォントサイズを変更します。 Mozillaサポートネットワーク上の1つのスレッド "ブラウザのデフォルトのフォントサイズを増やすにはどうすればよいですか？" には5,000以上のビューがあります。そして、 同様のスレッド には15,000を超えています。 別の調査 デフォルトのフォントサイズが「中」より小さいまたは大きいユーザーの割合（0.3％）が見つかりました。ユーザーが実際に変更する頻度は無関係と思われます（ a previous SO answer ）を参照してください。

  2. EMSは将来性が高いと思われます。これらは、最適なデフォルトのフォントサイズがnot16px（およびそのフォントサイズ）であるすべてのデバイスで機能します。

  3. 私を最も確信させたのは、それが実際に動いているのを見ることでした。 これはコードペンのデモです。ブラウザのズームはおそらく違いがないことに注意してください（Chromeでテストしました）。しかし、実際にブラウザの設定に進み、デフォルトのフォントサイズを「中」から他のサイズに変更した場合、幅はかなりずれています。私の意見では、これは受け入れられません。

56
nwalton

基本フォントサイズを変更するユーザーに関する具体的なデータはまだ見つかりませんでしたが、自分が何をしているのかを知る必要のある人々によって設計されたWebサイトをチェックインしました。メディアクエリの指定にpxを使用したかemを使用したかを具体的に調べました。これは質問に完全には答えないかもしれませんが、議論に興味深い次元を追加すると思います。

いくつかの主要なプレーヤー

このリストは決して網羅的でも決して測定されたものでもありません。ただし、ウェブ開発の最前線にいると思われる、またはレスポンシブデザインの実践に何らかの形で貢献していると思われる個人やグループの名前が含まれています。

注意すべき興味深い点の1つは、最後のエントリであるNicholas Gallagherが、メディアクエリ行を HTML5 Boilerplate CSS に追加した人であることです。そのコードでは、彼はemを使用していますが、彼の個人サイトではメディアクエリはpxに設定されています。そのコミットに関する議論を探しましたが、見つかりませんでした。

少数のサイト

繰り返しますが、散らばったリストが少しありますが、いくつかのサイトが含まれています。これらのほとんどは、前のリストの人々によって完全または部分的に構築されています。

HTML5ボイラープレートに関する興味深いメモ、メインプロジェクトのCSSはemを使用しますが、プロジェクトのモバイルバージョンはpxを使用します。

メガサイト

Webで最も人気のあるサイト がメディアクエリをまったく持っていないのは、実に驚くべきことでした。メディアクエリを使用するユーザーは次のとおりです。

結論

決定的ではありません。

人々は両方の方法を成功裏に使用しているように見えますが、ベストプラクティスについては意見が一致していないようです。

より進歩的なデザイナーの何人かがemに移行しているような気がしますが、それがそうであるように「見える」以外にはデータがありません。上記のサイトの一部は他のサイトよりも古く、emベースのメディアクエリに移行し始めてから更新されていないことも事実です。その面で適切な結論を導き出すのに十分なデータを実際に取得することは困難です。

ただし、世界最大のサイトのいくつかがpxを使用しているという事実から、このアプローチは しなければならない まだ技術的に健全かもしれません。それに大きな問題があった場合、より大きなサイトがユーザーやテストからそれを聞いて、視聴者に役立つ技術的に実行可能なものに移動したと確信しています。

31
nwalton

EMベースのメディアクエリを使用する主な理由が1つあります。
ユーザー（ベース）フォントサイズの設定を尊重
レイアウトを壊さずに！

ピクセル単位のフォントサイズ（要素の幅/高さ）も定義しないでください！
ユーザーがあなたのサイトを見るのに好きなフォントサイズを決めましょう。

したがって、アクセシビリティの問題です。

ピクセル値を使用している場合、特定の（ベース）フォントサイズを想定する必要があります。これは「通常」16ピクセルです。しかし、常にではなく、それがポイントです。そのため、ユーザーが小さい（または大きい）フォントサイズを選択した場合、レイアウトは崩れます。

または、デスクトップシステムでは、ユーザーがブラウザのズーム機能を使用すると、水平スクロールバーが表示されます（これはほとんど望ましくありません）。

これはすべて、EMsのような相対単位を使用することで回避できます。また、欠点もありません。

また、実際のベースフォントサイズの設定、およびモバイルブラウザー（タブレットやsamrtphonesなどのタッチデバイス）のズーム機能は、デスクトップのものとは異なる動作をすることにも言及する価値があります。モバイルブラウザバージョンでは、フォントサイズの設定はデスクトップブラウザのような重要な役割を果たしません。ただし、EMベースのメディアクエリを使用しても問題はありません。そして、これは可能な限り「将来的に保証された」ものです。

また、「62.5％テクニック」も簡単に使用できます。
新しい「ルートem」フォントサイズは、（ページの）ルート要素のフォントサイズに依存し、html要素ではなくbody要素であることに注意してください。

アクセシビリティを損なうことなく「62.5％テクニック」を使用します。

html {
    font-size: 62.5%; /* with the standard base font size of 16px this will be equal to 10px */
}

body {
    font-size: 160%; /* 160% of 10px ~ 16px, understood by all browsers */
    font-size: 1.6rem; /* 1.6 * 10px ~ 16px, understood by all major browsers and IE9+ */
}

したがって、rem（10で割った値）であるかのようにpxを使用できます。
しかし、ユーザーの設定に害を及ぼさずに！

ユーザーが選択した基本フォントサイズに関係なく、フォント比率は常に変更されません。
そしてレイアウトも！ ;-)

最後の発言：
常にmin|max-widthメディアクエリで、決してdevice-width！要するに、コンテンツに応じてブレークポイントをレイアウトおよび設定し、デバイスの解像度には決して依存しないからです！

したがって、レイアウトとフォントサイズに相対単位（EMsなど）を使用することで、デザインは実際に "応答性"になります。絶対単位（PXなど）を使用することではありません！

21
Netsurfer