H5BP Issue #816

Issue #816: Revert mobile-first media queries and remove respond.js – h5bp/html5-boilerplate

gravatar

paulirish opened this issue October 17, 2011

モバイル・ファーストのメディアクエリを元に戻し respond.js を削除する

Milestone:3.0 

No one is assigned

H5BP はモバイル・ファーストのメディアクエリを使用しているので、IE6-8 には、respond.js がそのポリーフィルとして動作する必要がある。

私は以下の点から、モバイル・ファーストのメディアクエリが最善かどうか、確信が持てていない。

  1. 明らかにそれらは、IE であるが故の追加コストとなること
  2. 第2に、開発者にとっては、モバイル・ファーストのスタイル記述が少々厄介なこと

メディアクエリをサポートしていない (現在使われている) モバイルのブラウザはどれか? さらにはそれらの中で、何らかの形で小さなスクリーンサイズにフィットさせるためにコンテンツをスケーリングしないブラウザはあるか?

私はこの方面において、Blackberry / Nokia の製品群を十分には知らない。一方で、モバイル・ファーストのメディアクエリの設定には多大な労力を要するし、努力の割にその見返りが少ないのでは、と感じている。

gravatar

私の意見は、モバイル・ファーストのアプローチは、モバイル・ボイラープレートの方が適しているだろう、ということだ。

gravatar

私は今まで、例えばポートフォリオ・サイトやブログなど、おそらくはモバイル・ファーストなアプローチで出来るであろう数々の JS ヘビーなコンポーネントと様々なレイアウトのサイトを作ってきたが、モバイル・ファーストのアプローチは使ってこなかった。つまり、決してデフォルトのアプローチではない、が私の意見だ。

モバイルに特化しているのだから、モバイル・ボイラープレートに入れるのは OK だ。

gravatar

巷にはモバイル・ファーストで書くことに異議があるのも知っているし、現在の良く出来たデスクトップ用のテストツールでも、モバイル用に書くことをうまく扱えていない。

だから Respond.js の削除に1票だ。もしモバイル版のサイトを作る必要があるなら、自分でメディアクエリをコツコツとやればいいし、(モバイル・ボイラープレートで作った) 適切なモバイル用ページに転送する何かしらの .htaccess を使うという手もある。H5BP の汎用的な性質から言って、ユースケースをあまりに特定し過ぎだ。

gravatar

第2に、開発者にとっては、モバイル・ファーストのスタイル記述が少々厄介なこと

そこまで細かくケアする?

モバイルを利用するインターネットのユーザーは、すぐにデスクトップのそれを超えるよね。現に幾つかの国では既にこのシフトが起こってる。これに慣れるには (我々は、デスクトップ・ファーストに慣れてしまっているので) 少々扱いにくい面があるのは同感だが、モバイル・ファーストが我々の向かうべき方向であるという感じは拭えない。我々は、最終的には数多くのモバイルのフロントエンドに対応しなければならないでしょ。

gravatar

両者のアプローチを切り替えるのは極めて簡単です。max-width を使うメディアクエリのプレースホルダーを min-width に切り替えるだけ。IE6-8 に追加コストが必要になることの問題は、カスタムな Modernizr (おそらく選択的に含ませるかどうかも含めて) から Respond.js を取り去ることに関係してきます。

モバイル狭いビューポート を分けて考えることには意味があるでしょう。H5BP の出発点として私たちが理解しているのは、狭いビューポート・ファースト (既に述べたように、デスクトップ・ファーストに切り替えるのは些細なこと) です。狭いビューポート・ファースト なアプローチの利点の1つは、プログレッシブ・エンハンスメント とのつながりにありますし、最適ではありませんが、コンテンツを確実にアクセスし易くするための簡単な方法を提供していることです。一般に古いブラウザでは、複雑なレイアウトのスタイルがメディアクエリの影に隠れてしまいます。しかし、IE6-8 にも基本的なスタイル以上のことが出来るようにしたいと願う人々がいるので、メディアクエリ (とその他) のポリーフィルとしての JS を追加し、これらの既に時代遅れなブラウザに負荷を負わせることになるのです。これらのブラウザにとって、どのぐらいの負荷になるのか、私には分かりません。

モバイル・ファーストを デザインする ということは、フロントエンドのコードを基盤として本格的にあらゆるデバイスに関する経験を最適化し、狭いビューポート・ファースト の構築に使おうとする試みとは別だということなのです。シンプルなサイトにとっては易しいが、複雑なサイトにとっては極めて難しいことです。広いビューポート を第1に考えて HTML を書くことは、狭いビューポート の視点で CSS を書き始めることに比べ、慎重な扱いが求められます … JavaScript のことを言っているのではありません。それ (デザインすること) は、メンテナンスのし易さの問題や、このアプローチをとるなら通信のバンド幅を押さえるためにしなければならない画像の修正作業などとは別のことなのです。

モバイルのコンテキストでは、非モバイルに提供されるものとは大きく乖離した、オーダーメードのコンテンツとデザインが要求されます。基本的には専用の モバイル・サイト がよろしい。それは H5BP プロジェクトと単にメディアクエリを使うということのスコープを超えています。

しかし、もし私たちが全ての 狭いビューポート・ファースト の項目をデフォルトで外してしまったら、それを有効にする H5BP のボルト・オンを誰かがビルドするようになる、という危険性があるでしょう。過去に持ち上がったそういったものの幾つかは、テストとメンテナンスが適切にされていないのが実情です。それはコミュニティにとって良いことだとは思いません。

だから私は、デフォルトで 狭いビューポート・ファースト のメディアクエリを (単なるプレースホルダーとして) そのままにしておくことには反対しません。シンプルなサイトであれば、このアプローチをうまく使えるでしょうし、大規模なサイトでは、開発者が自ら選択することでしょう。だとしてもおそらく、プロジェクトにそれを含めるかどうかの明確なコントロールをユーザーに与えるために、Respond.js は Modernizr からは外して元に戻すべきでしょう。

私の意見は、モバイル・ファーストのアプローチは、モバイル・ボイラープレートの方が適しているだろう、ということだ。

モバイル・ボイラープレートは、モバイルのウェッブ・アプリ用に、出発点を提供することを主な対象としています。ですから モバイル・ファースト で開発するからモバイル・ボイラープレートに乗り換える、なんてことは現実にはありません。HTML5 ボイラープレートがそのまま使えます。

適切なモバイル用ページに転送する何かしらの .htaccess を使うという手もある。

ブラウザのユーザーエージェント文字列を嗅ぎ分る? それはかなり普通じゃないアプローチでしょう。

H5BP の汎用的な性質から言って、ユースケースをあまりに特定し過ぎだ。

全然、特定し過ぎではありません。私たちが、より複雑なサイトにとっても実用的だと確信していないだけです。

gravatar

CSS のポリーフィルは、経験を積んだ優れた開発者にとってはそれほど問題にはならず、一方、経験の浅い者にとっては多くの問題が生じるということが、通例になりつつある。

性能の観点では、<head> 内の <script> ととてもよく似た状況だ。実際、ほとんどは次のようになる 🙂

  • CSS ポリーフィルは、CSS の解釈時に FOUC (Flash of Unstyled Content)、あるいはページ・レンダリングのブロックを引き起こす。
  • 構文解析は、そのどちらとも独立ではない。スタイルシートのフルテキストは DOM から得られるものではないため、それらは解析のために、ファイル中で再び XHR しなければならない。(訳者注:Respond.js は、CSS 中のメディアクエリをテキストとして解析するために、Ajax で CSS ファイルをリクエストします。詳しくは、Respond.jsHow’s it work にあります。)
    • 特にモバイルでは、余分の HTTP と RTT がバカにならないコストとなる。
  • CSS の構文解析は、仕様に準拠したパーサーでさえ、幾つかの CSS でハングアップを起こすほどトリッキーだ。

私が考える良い経験則はこうだ…。(準備ができるまでページを見せないのではなく) 利にかなった見せ方で、(DOMContentLoaded 以降に) ポリーフィルの初期化を遅延させられるのなら、それが良い。そうでなければ性能上のオーバーヘッドが深刻すぎる。だが、明らかに我々には信頼できるデータが不足している。

gravatar

Todd Parker (フィラメントグループ) によれば、Windows Phone 7 が Respond.js を必要とするな唯一のモバイルデバイスとのことだ (Mango は WP7.5 で、メディアクエリが使える): https://twitter.com/#!/toddmparker/status/126325865561866241

gravatar

WP7 のユーザーは 7.5 にアップグレードできるんでしょうか? あるいは、モバイル版 IE7 がなくなるまで待たなきゃならないんでしょうか?

gravatar

別の側面からの議論…

Rethinking the Mobile Web by Yiibu のスライド 87-101

gravatar

私は君たちのことは知らないんだが、色々なモバイルのブラウジング・テストを行うのに、デスクトップ上のエミュレータを1つ得るのでさえ、かなりのトラブルに見舞われているんだ。おそらくは私の環境が Linux だからだとは思うんだが、トリッキーな問題だらけだ (Android のブラウジングを模擬するデスクトップのテスト環境は、性能が大きな問題となるほどのヘンテコリンな仮想マシンが必要だし、iOS を模擬する方法だって見つかっていない)。

そんなこんなで、H5BP のモバイル・ファーストなアプローチが出来ないでいるし、ブラウザの幅なんかを小さくする馬鹿げた方法で、狭いビューポート でしかやれていないんだ (訳者注:H5BP のモバイル・ファーストと 狭いビューポート・ファースト を違うものと捉えているような書き込みではないかと思います)。

だから、君たちがこの問題に対して、どんな風にアプローチしてうまくやっているのかを聞きたい。どうしたら私なんかが、モバイル・ファーストを効果的に扱えるんだ? (訳者注:原文は疑問形ではありません)

gravatar

PPK (訳者注:オランダの Peter-Paul Koch というモバイル・プラットフォームのコンサルタント) がメディアクエリのサポート状況を Browser compatibility – viewports に挙げている。

  • (Mango 以前の) Windows Phone 7 では IE7 が走るので、メディアクエリをサポートしていない。
  • Blackberry 6.0 以前はメディアクエリをサポートしていない。そんなの取るに足らない、というだろうが、OS の内訳は、Choosing a Target Device OS によれば、こうだ:http://com-blackberry-us-5p.wwwa.com/developers/subs_by_OS.png (訳者注:URL を最新に更新したので、若干割合が上がっています)。
  • NetFront は、驚くほど出来が悪いブラウザだが、もう一息 という所まで落ちてきている。しかしながら、$79 の Amazon Kindle に採用されていて、かなり長い間生き残る可能性を秘めている。また、いくらか若者世代向けのクライアントであるソニーの PSP に採用されていて、実際、そこからのトラフィックもかなりある。
  • 今後のデバイス – これが重要だ。将来のブラウザがもっと良くなることを手を合わせて祈るばかりだが、実際の状況は、当てに出来ないことに変わりはない。ムーアの法則が今も最大限効力を発揮し、安価な Web ブラウジングが出来る “そこそこ” のデバイスが大量に出回っているのだ。

ここで私は、2番目の点を次のように修正したいと思う:第2に、開発者にとっては、モバイル・ファーストのスタイル記述が 最初は 少々厄介なこと

この、「最初は」 という所が肝心だ。我々は今、デスクトップからモバイルの未来に向かって大きく変わりつつある状況の中にいる。壁にはこう書いてある、「考え方を変える必要がある」。我々は、ウェッブサイトのコントロールを維持するために、作為的に 理想の 幅を作り出した。それは、デザイナーと開発者に都合の良いように決められている。しかしながら、デスクトップ・ファースト のアプローチは、早々に朽ち落ちるだろう。この例を見てくれ:

.section {
    width: 50%;
    float: left;
}
@media screen and (max-width: 600px) {
    .section {
        width: 100%;
        float: none;
    }
}

デスクトップ・ファーストだと、不必要に複雑なコードになることが分かる。次はモバイル・ファーストのバージョンだ。

@media screen and (min-width: 600px) {
    .section {
        width: 50%;
        float: left;
    }
}

ずっといいだろう。デスクトップのスタイルをオーバーライドする代わりに、単に必要な属性を定義すればいい。効果的だし、メンテナンスも容易だ。

私見によれば、モバイル・ファースト は技術的なテクニックというより、ずっと精神的なものなのだ。プログレッシブ・エンハンスメントとも言える。GPS、加速度センサやブラウザのタッチ・イベントは、そのサポートを機械的に決めつけず、使えるかどうかを確かめてから、それに応じて機能させるだろう。それと同じことをスクリーン幅についても適用しなければならない (そして回線のタイプなど、他の都合の良い想定もだ)。(ブラウザを介して見る) Web がモバイルの未来にも生き続けるためには、ユーザーはデスクトップを使っているハズ と決めてかかるのは、今すぐにやめるべきだ。

gravatar

もし間違っていたら正して欲しい。メディアクエリによるモバイル・ファーストのアプローチは、小さいビューポートに大きな背景画像を読み込むのを防止するために考案されたのだと思っている。これはとても妥当な理由だ。

だから、もし背景画像を使わないなら、このアプローチはもはや必須ではない。だが、@bradfrost が言うように、よりクリーンでスマートなコードになることは認める。

今日の Web 開発は、日に日に古いものは急速に廃れ、小さなビューポートがどんどん重要になってきている。大企業のクライアントといえどもそうだ。IE 用のポリーフィル (あるいはハック) を使うのは、今は複雑なソリューションに見えるかもしれない。しかしその結果、すべてのモダンブラウザにとってもより優れたコードとなる。私は、これこそがベストプラクティスだと思う。

メディアクエリを、ビューポートと コンポーネント のどちらのレベルでグループ化すべきか、私にはまだわからない (訳者注:リンク先の Gist には、各クラスに @media を指定する、即ちコンポーネント・レベルのスタイル定義が提案されています)。

コンポーネント・レベルのアプローチが私の好みだが、H5BP にどうやって組み入れるのかは、わからない。

おっと、これでは質問の答えになっていないナ (-: 。

gravatar

記録のために残しておくが、全リソースをダウンロードしてしまうという WebKit 534.6.0 のバグは、2011年8月にフィックスされた (訳者注:例えページで使っていなくても、スタイルシートに定義された背景画像の類を全て読み込んでしまうという WebKit のバグ のことを指しています。Paul Irish は、ココ とか ココ とかに似たような書き込みをしています)。

これは、Safari 5、iOS 4.3 と Android 3.0 がまだフィックスされていないことを意味している。Safari 5.1 は OK だ。モバイルのサファリは分からない (もうすくフィックスされると思う)。

バグのリンク:https://bugs.webkit.org/show_bug.cgi?id=24223

gravatar

Jeremy Keith が次の記事で投稿しているように、もし主要な問題が IE6-8 の Respond.js によるオーバーヘッドだというなら、なぜそいつを削除して、IE / IE モバイルに効くコンディショナル・コメントを使わないんだい?

http://adactio.com/journal/4494/

前の議論を蒸し返していたり、明らかに何かを見逃しているなら、どうか許してくれ。コンディショナル・コメントを嫌う人がいるのは分かっている。しかし開発とパフォーマンスの観点では、このアプローチ以外はないと思う。

gravatar

やぁ Brad、ブラウザの詳しいサポート状況をありがとう。これらのブラウザのうち、どれが JavaScript を実行できず Respond.js のポリーフィルが役に立たないんでしょうか?

モバイル・ファースト は技術的なテクニックというより、ずっと精神的なものなのだ。

デザインの観点では全く同感です。しかし開発の観点では独特の緊張感があり、それは単にやり方を変えるということを心理的には超えているんだと思います。

(ブラウザを介して見る) Web がモバイルの未来にも生き続けるためには、ユーザーはデスクトップを使っているハズ と決めてかかるは、今すぐにやめるべきだ。

今やそういった決めつけは、だいぶなくなってきていると思います。それは 広いビューポート・ファースト のアプローチで、メディアクエリをサポートするか、JavaScript のポリーフィルを走らせることができる 狭いビューポート のブラウザに適応する開発とは異なります。そういった開発は、ある環境では良い結果をもたらしません。しかし、モバイルで見ることを全く無視したり、デスクトップのブラウジングと決めつけてかかることと同じではありません。

(フロントエンドの全てに渡って) かなり複雑なサイトでは、モバイル・デバイスに適したエクスペリエンスまたはコンテンツが、時にはより優れた形で専用に最適化されたウェッブサイトから提供されることがあります。メンテナンス上の事項も重要になるでしょう。こういったケースでは、ただ1つのフロントエンドのコードベースで、全てのエクスペリエンスを提供しようとすることは、賢くないし実践的でもありません。

しかしこれらのケースでも、(狭いビューポート用の) 基本スタイル・ファースト でないと始められないということではありません。これが、より広いビューポート用に構築するためのメディアクエリをデフォルトとしてキープしておきたいと思う理由です。もし開発者が逆にしたいと思えば、簡単にできます。しかし Respond.js をより明示的にして含めることは、(どんな理由にしても) モバイル用に制作したいと思わない人に有用で助けになるし、IE6-8 にスタイルシートを読み込ませる不必要な XHR の使用を負わせることも避けられるのです。

もし主要な問題が IE6-8 の Respond.js によるオーバーヘッドだというなら、なぜそいつを削除して、IE / IE モバイルに効くコンディショナル・コメントを使わないんだい?

これは、Respond.js が IE6-8 に何をさせる必要性があったかに関わることでしょう。加えてコンディショナル・コメントを使うと、<html> クラスなしでボイラープレートを使う人は、ダウンロードのブロッキングを防ぐため、空のコンディショナル・コメントを <head> の先頭に含める必要があることを意味しています。

gravatar

しかしこれらのケースでも、(狭いビューポート用の) 基本スタイル・ファースト でないと始められないということではありません。

それこそが、私たちが推奨すべき グッド・プラクティス ではないかと私は思います。私はまた、(IE8 を含む) メディアクエリを理解できないブラウザのために、それをそこに残しておくべきだと思うし、そうすればユーザーは、 IE 用の良いソリューションを使うかどうかを決められると思います (あるいは h5bp-ui にスニペットとして提供するとか)。

私たちは、開発者に何よりもまず、この 基本スタイル・ファースト を考えてもらう必要があると思っています。そうすれば、(使い勝手が良くなくても) 少なくとも多くのブラウザが読めるサイトになるでしょう。

gravatar

コンディショナル・コメントを使うと、<html> クラスなしでボイラープレートを使う人は、ダウンロードのブロッキングを防ぐため、空のコンディショナル・コメントを <head> の先頭に含める必要があることを意味しています。

うわっ、そうなんだ 🙁 。

(IE8 を含む) メディアクエリを理解できないブラウザのために、それをそこに残しておくべきだと思うし、そうすればユーザーは、 IE 用の良いソリューションを使うかどうかを決められると思います (あるいは h5bp-ui にスニペットとして提供するとか)。

うん、それはいい感じだと思う。IE に対処する方法は幾つかあるのだから、開発者にその選択肢を知らせてあげれば、最も適したソリューションを使うことが出来るってことだよね?

gravatar

これらのブラウザのうち、どれが JavaScript を実行できず Respond.js のポリーフィルが役に立たないんでしょうか?

Brad が示してくれたブラウザの多くは問題を含んでいます。6.0 以前の BlackBerry は、ブラウザのバージョンに依存してまともではありません (v.4.6.1 以前は完全に使い物になりません) し、NetFront も似たようなものです (古くからあり、また最近のデバイスでは Kindle に搭載されました)。

主な問題は、JavaScript のサポート の アリ/ナシ ではありません。そのポリーフィルが各ブラウザで徹底的にテストされるまでは (その具体的な証拠を見つけることが出来ないのですが)、そこに挙げられた全てのブラウザでポリーフィルをベースとした JavaScript のサポートが十分だと仮定するわけにはいかないと思っています。この点から見れば、Nokia の S40 WebKit のブラウザと新しい S40 プロキシ・ブラウザだけでなく、そのリストに S60/S^3 のほとんどを加えるのが賢明でしょう。

今の段階では、メディアクエリのポリーフィルは削除し、開発者自らが特定のシナリオにとって何がベストかを決めてもらうことを勧めます。私たち (yiibu) は、モバイル・ファーストのすべてを開発し、コンディショナル・コメントを連結して IE の全てのバージョンを処理しています。この方法はこれまでのところ非常にうまくいっていて、今日の多種多様なブラウザがあるという現実に、とてもうまく対処できています。

ブラウザは改良され続ける (そしてサポートが広がるにつれ、特定のテクニックは冗長になっていく) わけですが、Amazon の最新の製品リリースは、私たちが期待してもよい、ブラウザやデバイスの多様性の優れた例となっています。私たちは、このような多様性に対応するポリーフィルのようなアプローチを乗り越え、より将来の親しみやすい考え方と技術を目指して努力する必要があると思います。

gravatar

議論の元ネタに…

チームやアプリが大規模になるにつれ、モバイル・ファーストはその利点よりメンテナンスのコストの方が重くなってきている。モバイル/ウェッブ/タブレット (あるいは必要なだけ) のビューをただ複製することで、それぞれ専用のバックエンド・デザインを作ることに意味があるかどうか、私には分からない。しかしより大規模な場合、それぞれのサイトのバージョンごとにモジュラー式ビューの断片を作り続ける方が、メディアクエリを変えるために絶えず 上書きする 作戦より、ずっと単純な戦略である場合がある。どんな場合にも (ルーティングとかコントローラーとかは別にして)、少なからず無駄はあるものだ。

H5BP がグッド・プラクティスの一部を担うというのなら、我々は、アプリケーションのアーキテクチャを教育する手助けをしたいのだろう…上記の戦略を宣言しないのはどんな状況において正しいが、多くのアプリケーションにおける機能 (あるいはデザイン) は、モバイルとデスクトップとでそのギャップが、率直に言ってあまりに大きすぎるのだ。明らかに H5BP はバックエンドを選ばないよう意図されているので、私としては、ドキュメントか幾つかの空のビュー・フォルダを置く方法を推す。

gravatar

IE6-8 には、モバイル・ファーストと Respond.js に起因する追加コストがある。そう、FOUC はあるが、やがては IE6-IE8 のユーザーを超えるだろうモバイル・ユーザーとのトレードオフからすれば、それだけの (訳者注:つまり、FOUC があっても) 価値はある。

モバイル・ファーストは、開発者にとって最初は扱いにくいものだ。しかし、レスポンシブ Web デザインに対するアプローチとしては正しい方法だ。モバイル・デバイスに、結局はより少ないリソースを提供することになるし、デスクトップからデザインするより、少ない CSS の記述で済むことになるだろう。私の経験では、適切なメディアクエリを元に少し調整するだけで、モバイルのスタイル上にタブレットやデスクトップ用のスタイルを構築することができる。私が最初に作ったレスポンシブ・サイトは、デスクトップから書き起こしたのだが、結局はメディアクエリの間を行き来するのに多くの時間を無駄に費やしたし、多くの CSS を書く必要があった。今はモバイル・ファーストのアプローチをとっているので、それが少しの調整でできる。

gravatar

より大規模な場合、それぞれのサイトのバージョンごとにモジュラー式ビューの断片を作り続ける方が、メディアクエリを変えるために絶えず 上書きする 作戦より、ずっと単純な戦略である場合がある。どんな場合にも (ルーティングとかコントローラーとかは別にして)、少なからず無駄はあるものだ。

その通りですネ。しかし H5BP のユーザーの大多数が、そういうアプリケーションから始めているのか、私には確信がありません。それを知るには、調査が必要だと思いますね。

H5BP がグッド・プラクティスの一部を担うというのなら、我々は、アプリケーションのアーキテクチャを教授する手助けをしたいのだろう…上記の戦略を宣言しないのはどんな状況において正しいが、多くのアプリケーションにおける機能 (あるいはデザイン) は、モバイルとデスクトップとでそのギャップが、率直に言ってあまりに大きすぎるのだ。明らかに H5BP はバックエンドを選ばないよう意図されているので、私としては、ドキュメントか幾つかの空のビュー・フォルダを置く方法を推す。

これには複数の問題が潜んでいると思います。その1つはスタイル、特に CSS 中のメディアクエリ関することで、コンテンツやサイトの全体的なアーキテクチャについてのことではありません。それらは大きな問題であって、明らかにベスト・プラクティスの定義と、おそらく h5bp-ui の一部として取り組みたいと思っている何かがが欠けているんだと思います。

gravatar

Respond.js を使わずに、メディアクエリをサポートしないブラウザを扱う方法がある – Techniques For Gracefully Degrading Media Queries | Smashing Coding

幾つかのユースケースでは、Respond.js でさえ十分なポリーフィルになってないことが分かる。これは開発者に任されるべき類いのことだと思うし、それぞれのサイトのターゲットユーザー次第だ。

gravatar

@necolas: すべての Windows Phone 7 ユーザーはアップデートできる。2月の Node アップデートであったような問題がないとは言えないが。今年の終わりには、すべてのユーザーが最新版に更新できていると思う (必ずしも彼らがそうするという意味ではないが)。実際、Mango 上の IE9 はすばらしい (私が今のところ知る限り)。

モバイル・ファーストに1票。(H5BP ではないが) このアプローチで幾つか仕事をしたし、少したった今では、それが自然な感じに思える。

ところで、モバイル ボイラープレートと分けることが実際に必要なんだろうか?

gravatar

これには複数の問題が潜んでいると思います。その1つはスタイル、特に CSS 中のメディアクエリ関することで、コンテンツやサイトの全体的なアーキテクチャについてのことではありません。

2つの問題が異なるという意見には反対だ。アーキテクチャと CSS の定義は互いに排他的ではない。今日のアプリ構築にとって、CSS の最小化と結合は (コストが) 安い。関連する項目を選択してインライン CSS とすることは、メディアクエリ化することより合理的かもしれない。私は最近、大掛かりに結合され (キャッシュされ) た共通ファイルを使うやり方を見直し、少量の最小化された CSS スニペットをインライン化することに興味をもってやってきた。

PoS サーバ (スピートが最優先) で動作している新バージョンの AE.com ページから、(製品ページで使っている全スタイルの) 例を挙げる。

<!-- Common styles -->
<style>html{background-color:#f3eddd;color:#616159}a{color:#616159}.inverted{background-color:#0b1720;color:#f3eddd}.inverted a{color:#f3eddd}.lighter{background-color:#fff5e4}.darker{background-color:#eae2d2}.darkest{background-color:#e1dbc1}.bordered{border-color:#bebfaf;border-width:1px;border-style:none}.darkBorders{border-color:#616159}html,body,form{padding:0;margin:0}ul,li,h1,h2{padding:0;margin:0;font-size:1em;font-weight:normal}li{list-style:none}a{color:inherit;text-decoration:none}img{vertical-align:top;border:0}body{font:normal 10px sans-serif;width:770px;margin:0 auto 60px}.clearer{overflow:hidden;height:0;width:0;clear:both}.gridded{float:left;margin:0 10px 20px}.smallGridded{float:left;margin:0 5px 10px}.content{width:638px}.header{padding:0 10px 20px}.header h1,.header .brandLink{display:block;float:left}.header .brandLink{overflow:hidden;height:0;padding-top:31px;width:89px;background:url(/Images/lookbook/logo_brands.jpg) no-repeat 0 0}.header .b_web{background-position:0 0}.header h1 .b_web{background-position:0 -31px}.header .b_aerie{background-position:-89px 0}.header h1 .b_aerie{background-position:-89px -31px}.header .b_77kids{background-position:-178px 0}.header h1 .b_77kids{background-position:-178px -31px}.siteSearch{float:right}.siteSearch *{vertical-align:middle;font-size:12px;text-transform:uppercase}.siteSearch .question{margin:0 0 0 10px;width:172px;height:27px;line-height:27px;border-left-style:solid;border-bottom-style:solid;border-right-style:solid}.siteSearch .bttn{margin:0;border-bottom-style:solid;border-right-style:solid}.nav li{width:170px}.nav a,.nav .noLink{display:block;padding:6px 10px;text-transform:uppercase;cursor:pointer;zoom:1}.nav .menu a,.nav .menu .noLink{padding:6px 20px}.rootLink{border-style:solid;text-align:center}.nav .menu{display:none}.rootMenu{border-left-style:solid;border-right-style:solid}.flyout .rootMenu{display:none;position:absolute;z-index:10}.topNav .expanded .rootMenu,.rootMenu .expanded .menu{display:block}.rootMenu li{width:168px;border-bottom-style:solid;vertical-align:top}.rootMenu li li{border-top-style:solid;border-bottom-style:none}.sideNav{border-top-style:solid}.icons{float:right;margin-left:10px}.rootMenu .arrow,.rootMenu .minus{display:none}.rootMenu .expanded .plus,.rootMenu .emptyCat .plus{display:none}.rootMenu .expanded .minus{display:inline}.rootMenu .emptyCat .arrow{display:inline}</style>
<!-- Product page -->
<style>.pdpContent{border-style:solid}.imgViewer{float:left;width:299px;text-align:center}.imgViews{padding:6px}.imgView img{border:3px solid transparent;margin:2px}.imgViews .selected img{border-color:#000}.pInfo{float:left;border-left-style:solid;padding:20px}.pInfoInner{float:left;width:208px}.minHeightShim{float:right;width:0;height:460px}.pName,.pMarketing,.pColor,.price,.sale{margin-bottom:20px}.pName{font-size:20px;text-transform:uppercase}.tinyPrice{text-decoration:line-through}.price,.sale{font-size:20px}.sale{color:#a30320}.pColor{text-transform:uppercase;padding:6px 0;border-top-style:solid;border-bottom-style:solid}.swatches{padding-top:3px}.swatches img{margin:2px;border:3px solid transparent}.swatches .selected img{border-color:#000}.equity{border-top-style:solid}.equity li{width:206px}.equity .menu{border-top-style:solid;padding:10px;width:186px;overflow:auto}.equity .menu li{border:0;width:auto!important}.equity .menu .linePadding{margin-bottom:10px}.equity .menu a{display:inline}.equityTip{display:none!important}</style>

…5つの小さな CSS ファイルを結合・最小化して、2つの CSS スニペットにしている。かなり特殊で単純化されたユースケースではあるが、外部へのリクエストをなくすことで性能の改善を図り、さらにはスタイルシートの読み込みがタイムアウトする可能性などを排除している。

このような断片をインライン化することは、X のケースや Y のケースには適していないし、おまけにもう1つ過ちを犯しているという反論が多数来るだろうことは百も承知だ (訳者注:もう1つの過ちとは、サイズ削減のためにクラス名をキャメルケースで定義していることかな?)。しかし、こういうことは現実では至って普通のことだ。おそらく H5BP は、人々をこういう習慣に向かわせるべきではないと思う。1つですべてをまかなう ことをプロデュースするより、教育やコンフィグレーションの方が重要だからだ。

ここに HTML5 ボイラープレートの README を引用する。

特定の開発方針やフレームワークを押しつけたりはしません。あなたが望む方法でコードを設計して結構です。

この言葉が私に思い起こさせてくれる短い話をさせて欲しい…

画像の CSS スプライトが優れていることは誰でも知っている。それはリクエスト数を減らしてくれるし、ダウンロードする合計の画像サイズを減らしてくれることもある。そして時には、(同じ PSD にすべてを維持することで)サイト全体に渡る画像を統一し、メンテナンスの複雑さをも軽減してくれる。

ある日、我々のチームの一人がサイトの国際化に着手した。彼は、選択されている国の隣に小さな国旗を表示するよう実装した。他の優れた開発者がやるように、彼は美しいグリッドに小さな国旗をすべてスプライト化した。ほどなく、私はこれをみて考えた。フム、実際、誰がそうたびたび言語を変えるだろうか? もっと重要なことは、ユーザーは同時にこれらすべての国旗を見る必要があるかどうかだ 答えは (どのユーザーも) 1回ぜんぜん だった。これは明らかにこのケースにおいてスプライト化は誤りだったことを気付かせてくれた (今では各ユーザーは自分の国旗だけを読み込めばよい)。我々はメディアクエリに立ち戻り、そういったことを考え直す必要があると思う。ユーザーは、同じデバイスに1つ以上のエクスペリエンスを必要とするだろうか? 答えは 滅多にない だと思う。

我々は ユーザー のために開発しているのだということを思い出して欲しい。そして、ユーザーは自分が使っているデバイス用にデザインされたサイトで、ベストなエクスペリエンスを得るべきだということは、皆、同意できると思う。H5BP を活用するサイトのほとんどは、レスポンシブ・デザインは、複数の 適切な サイト・バージョンを ユーザーが選択する 手間を割愛し、代わり1つの 柔軟な バージョンを彼らに与えるものだと言える。我々は、理論的には人々の生活を楽にし、理論的には最高のユーザー・エクスペリエンスを与えることになるので、開発者はあらゆるプロジェクトで、これらを自問することを忘れてはならないのだ。

gravatar

ところで、モバイル ボイラープレートと分けることが実際に必要なんだろうか?

モバイル・ボイラープレートは、主としてモバイルのウェッブアプリ用です。

gravatar

@jswartwood、君は重要な問題に触れている。我々が導入しているこれらすべての技術は、現実の人々にとって重要な意味をなす必要がある。多くのレスポンシブ・デザインは、小さなスクリーンに対応することに力を費やすが、そうすることで多くのオーバーヘッドが生じている。その結果、サイトを利用するユーザーに少しも真の価値を提供していない、不必要に複雑なデザインとなっている。デザイナーが実際にモバイル・デバイスでそのサイトを利用するつもりがあるのか、あるいは単にそうすべきだからやっているのか、疑いたくなることがある。

ほとんどの場合、http://mediaqueri.es/ のようなサイトから飛んでくる開発者や人々が、紹介されているサイトをグシャッと潰してスケーリングをしているだけだ。Blackberry Bold のポートレート・スタイルのユーザーには、レイアウトがレスポンシブかどうかなんて関係がない。本当に重要なことは、どれだけ速くゴールに達し、すべきことに取りかかることができるかだ。どんなポリーフィルや凝った仕掛けも、(特に既存のデスクトップ用サイトをより小さなフレームに押し込もうとするなら) 柔軟なシステムが要求されるが、複雑になるほどパフォーマンスとユーザビリティに影響が及んでいる。

Luke Wroblewski が LukeW | Why Separate Mobile & Desktop Web Pages? で強調しているように、@necolas は、モバイル用のテンプレートを分けた方が有効な場合があるという事実に触れている。(画像やビデオなんかのような) メディア要素とそのソース順序は、レスポンシブなサイトを制作する時に直面する最大の難問だ。

それは最終的にはプロジェクトに依るし、異なるデバイスのフォーム・ファクターに応じてどの程度、エクスペリエンスを変えたいかに依って決まる。例えテンプレートを分けて使ったとしても、それら両方は可能な限り柔軟であるべきだ。

H5BP に関する限り、私はどう変えたら良いか正確には分からないが、より単純かつ普遍的なスタイリングから始め、その後、より大きなスクリーンへの対応やより複雑なスタイリングに向かうべきだと思う。

gravatar

このプレゼンテーションがとてもいい:Crap! It doesn’t look quite right, or, how I learned to stop worrying and set my mobile web sites free

私たちは間違ったやり方をしています。
レイアウトを制御しようとする私たちの間違った考えは、現在の普及したデバイスで営む他の要素と相まって、実際 Web を非常に困難なものにしています。

(訳者注:上記引用の原文には、lifelike とした誤字があります)

モバイル・ファースト のアプローチの主たる問題は、多くのデザイナ達が (画像や複雑なインタラクション、多くのコンテンツに依存しているので) 柔軟に適応できていないことであり、さらには期待値が高すぎることも問題だ。それはすばらしいコンセプトだが、(前に誰かが指摘したように) 技術的な難しさやタイトな締め切りのために、まだ多様なプロジェクトにうまく適合できているようには見えない。

私はこれから先のプロジェクトでは、このアプローチに従いたいと思うが、ただ、多くの人がすぐに適応できるかどうかは分からない。ここでの議論は非常に良いものなので、各々の技術の長所/短所を広く人々に知ってもらうために、正しいアプローチかどうか、それぞれの人が考えられるよう、この議題に関する情報をドキュメントに加えるべきだと思う。私は、大半の人がこのアプローチに従うようになったら、デフォルトとすべきだと思う (それほど長い時間はかからないハズなので)。

Future Friendly というサイトには、役に立つリソースや記事、そしてマニュフェスとへのリンクがあることを紹介しておく。

gravatar

私にはお手上げだ。私は、今まで一度も モバイル・ファースト でサイトをデザインや作成をしたことがないことを認めよう。レスポンシブなサイトを作ることになっても、デスクトップのレベルから始めて必要に応じてダウンサイジングすることになるだろう。しかし、@bradfrost の次の言葉は正しいと思う。

ほとんどの場合、http://mediaqueri.es/ のようなサイトから飛んでくる開発者や人々が、紹介されているサイトをグシャッと潰してスケーリングをしているだけだ。Blackberry Bold のポートレート・スタイルのユーザーには、レイアウトがレスポンシブかどうかなんて関係がない。本当に重要なことは、どれだけ速くゴールに達し、すべきことに取りかかることができるかだ。

私にとっては、頭の上に釘を打たれた感じだ。そんなのは、どのプロジェクトにも適していない。ボイラープレートをダウンロードする際の、カスタム・ビルドの一部として選択できるようにしておけば良いと思う。

gravatar

開発者に決めてもらう上で…

ここにあるようなスレッドの議論から引き出せることは、開発者がどのアプローチを採用するか決めるには、それはまだ十分ではないということだ。

ベストプラクティスは強力だ。なぜなら、信用が得られるし、開発者が選択肢を毎回探す時間と金を浪費しなくて済むからだ。正に HTML5 Boilerplate が評価されている理由だ。それは、背後に多くの裏付けデータを持ち、Web 開発者のベースラインとして十分と思うデフォルトを素早く導きだすものだ。

幾つかのケースでは、審判が必要である。しかしほとんどのケースでは、開発者にとって最も推奨される方法を導きだす幾つかの質問にまとめる事が出来ると思う。そしてこれらのアプローチは、それが正しいことを裏付けるデータが必要だと強く感じている。

そこで…

ここでの皆の議論に感謝すると共に、これまでの事実をまとめてみたいと思う。最初に…

  • 狭いビューポート (つまりモバイル) と広いビューポートを分ける、理にかなう幾つかの閾値がある。そのような閾値 は、ブログとウェッブアプリの連続線上にある。
  • メディアクエリをサポートしない既知のモバイル・ブラウザは、Kindle、S60/S^3、Nokia S40 WebKit と新しい S40 プロキシーのブラウザ、そして古いフィーチャーフォンである。
  • jQuery モバイルは、モバイル・ウェッブアプリのフレームワークとブラウザのサポートという点で最も包括的であるが、メディアクエリのないブラウザをサポートしていない。
  • WebKit には 「背景画像がカスケード的に指定された場合、最後の指定だけでなく、全ての画像が読み込まれる」 というバグが存在する。
    • ただしその問題は、広いビューポートのメディアクエリと背景画像を指定する場合に、相殺する必要があるというだけだ。

狭いビューポートのメディアクエリ用テクニック

  1. Respond.js によって、狭いビューポートのメディアクエリが使えるが、パフォーマンス上のコストが著しい。
    • クロス・ドメインはダメ、em が使えない、@import も使えない。
    • Scott、休暇中の君には悪いが、私は君のプロジェクトが好きになれそうもない。
  2. コンディショナル・コメントでファイルを分ける
    • ブロッキングの振る舞いを防止するために、空のコンディショナル・コメントを必要とする事を意味している。
    • おそらく次のうちの1つで出来る。

コンディショナル・コメントでファイルを分ける

<link rel="stylesheet" href="global.css">
<link rel="stylesheet" href="desktop.css" media="all and (min-width: 700px)">
<!--[if (lt IE 9)&(!IEMobile 7)]>
<link rel="stylesheet" href="desktop.css">
<![endif]-->

あるいは

<link rel="stylesheet" href="global-including-desktopstyles-inMQs.css">
<!--[if (lt IE 9)&(!IEMobile 7)]>
<link rel="stylesheet" href="just-desktop.css">
<![endif]-->

あるいは Nicolas Gallagher の Mobile first CSS and getting Sass to help with legacy IE

なぜ、狭いビューポート・ファーストなのか?

  • (メディアクエリを持たない) 古いモバイル・ブラウザは、デスクトップ向けにデザインされたページを表示できない事がある。
    • 私はこれらのブラウザが実際 Web ページをどのように表示するのか見た事がない。賢いスケーリングの事は覚えている。
    • 誰か、幅が 960px ぐらいのレスポンシブでないメジャーなサイトが、上記でどのように見えるか示してくれないか。
    • また、これらのマーケットでのシェアがどのぐらいか、私は懐疑的だ。
    • また、これらの ページビューのシェア はさらに疑わしい。人々は実際、そういったデバイスでブラウザを使ってるのか?
  • なぜ、デスクトップ用のスタイルを相殺するのか、もっとシンプルなスタイルを届ける事が出来るのに!
    • 理にかなっている 🙂
  • WebKit の背景画像をダウンロードする際のバグ
    • もはや誰が背景画像を使うのか! ましてやモバイルに… 恥じるべきだ!

加えて、zomigi の最近の記事 Essential considerations for crafting quality media queries も良い記事である。

gravatar

もし、

  • 貧弱なモバイル・ブラウザは捨てておき (これは上記質問の回答を保留していることと同じ)、
  • Respond.js も捨てたら (Scott、再度ゴメン!)…

モバイル・ファーストは、(古い IE の為に) 2つのファイルが必要となるが、デスクトップファーストであれば、1つで済む。

  • オーサリング面での呼び出しの難しさ
    • デスクトップ・ファーストは、我々のツールにちょうど良い
    • モバイル・ファーストは、このスレッド参加者の理にはかなってる
  • パフォーマンス面
    • 次のような質問に行き当たる:モバイルでは決して使わない CSS のダウンロードがどのぐらい必要か
    • そしてそのサイズは、HTTP リクエストの追加より価値があるのか
    • その答えを得るために、あるトライをした が、解決策を確認するだけの良い方法とはなっていない。
gravatar

それら両方の側面があってもなお、レスポンシブなレイアウトデザインを押し進めるのか? それは H5BP が望んでいる グッド・プラクティス なのか?

イヤ、意見ではなく、単なる質問なんだが…

gravatar

そうだ。H5BP は、レスポンシブでありたいし、それを正しくやりたい。

そして人々が、デバイスではなく、コンテンツにおけるブレークポイント近傍でメディアクエリを書くベストな方法を学ぶ場所でもありたい。しかし、それらコンテンツを見るであろう、数々のスクリーンサイズには注意すべきだ。これは私がまだ十分にクリアに出来ていない、オーサリングの詳細だ (Scott はこの件について書こうとしていたが、オフラインだし…)。ともかくこれは、このチケットの主題から外れている。

しかし、我々は何よりもまず、ベストプラクティスな実装を見出す必要がある。

gravatar

IE6 (と、おそらく IE7 も) は、複雑なメディアクエリのルールを無視する (訳者注:この Dev.Opera の記事は既に情報が古いそうです)。だから、メディアクエリを使う事が出来るし、IE も相変わらず (大雑把に) スタイルを得る事が出来る。しかし IE8 は、複雑なメディアクエリのルールに対するサポートが追加されず、フィックスされてしまった。

私は、「IE8 のメディアクエリを IE6 の様に振る舞わせる」 ということを探求していたが、成功していない。しかし、(JavaScript もコンディショナル・コメントも使わず) モバイル・ファーストのメディアクエリを定義した1つのスタイルシートで済ませられる事が分かる。IE6-8 のデスクトップ用スタイルを適切に与えながらだ。きっと天使があなたの名前をコーラスする事だろう!(訳者注:もしできれば、神の祝福ありますヨ、ってな感じでしょうか)

gravatar

まさにそこがポイントなんだよ、Oli。Paul は今朝、メディアクエリをサポートするブラウザが、Opera の記事にある複雑なクエリを 常に 解析するということを指摘し、私の夢を打ち砕いたのだヨ 🙁 。(訳者注:この人の夢が一体何なのか、不明です (;^_^)

gravatar

@paulirish 曰く

私はこれらのブラウザが実際 Web ページをどのように表示するのか見た事がない。賢いスケーリングの事は覚えている。

これらのブラウザがする事は高く評価できますが、大多数は、単に全てのブラウザがする事をします。出来る限りの HTML を解釈し (div のスープはこれを困難にしますが… セマンティックなマークアップなら容易です)、スタイルを適用しようとし、サポートしている限りに機能します。特別なスケーリングがあるのは稀な方です。それ故、固定化されたピクセル値が使われれば、コンテンツはビューポートをはみ出て水平スクロールバーを出現させるか、切り取られてしまいます (例えば、Blackberry は広過ぎる画像やデータテーブル、その他の要素を切り取ります)。

過去のブラウザの幾つかは、いわゆる サムネイル・ビュー のアプローチを実装していました。それは全体が描画されたページの縮小版で、その上でマーカー (大抵は赤い四角) を操作してズームしたい場所を示すことができます。その他のブラウザは、単にズームするだけでした。

もっと古いブラウザは、こういった機能さえ持たず、単に通常のドキュメントの指示に基づき、出来る限りのことをするだけです。

ですから一般的には、ユーザーが表示するには (どんな理由でも) 広すぎるレイアウトを、ちょっとした UI で手助けするだけなので、通常のブラウザの振る舞い以上は期待しないのがルールです。

誰か、幅が 960px ぐらいのレスポンシブでないメジャーなサイトが、上記でどのように見えるか示してくれないか。

後で確かめてみようと思います。デバイスが古くなるほど、スクリーンショットを撮るのが難しく (時には不可能に) なりますが、何とかできるでしょう…しかし実際、デスクトップと同じように見えると思います…レンダリングや動作のいくつかがサポートされていない場合はこの限りではありませんが。そしてもちろん、レイアウトが複雑になるほど、失敗する可能性も増えます。

また、これらのマーケットでのシェアがどのぐらいか、私は懐疑的だ。

マーケットでのシェアは膨大です。モダンなスマートフォンのシェアは、最も小さな部類です (この状況はもちろん変化していますが、現実的にはあと何年もかかるでしょう)。次の Gartner のレポートは、良い例を提供しています。これによれば、スマートフォンは 無料 OS のデバイス に分類され、全出荷数の高々 26% であることが示されています。その 26% の中では、Android がリードしていて、iOS、Symbian、RIM (これらは皆、似たような数字です) が続きます…もちろん常にこれはシフトしていますが。

Gartner Says Android to Command Nearly Half of Worldwide Smartphone Operating System Market by Year-End 2012

モダンなスマートフォンは、当然もっと使い勝手の良いブラウザを搭載していますし、相当数、無料のデータアクセスを行っています。しかし多くのマーケット (UK や、他の EU 諸国を含む) では、メディアクエリをサポートしていない、あるいは問題の解決を補助するためのポリーフィルに頼れないほどの貧弱な JavaScript を搭載したデバイスからのトラフィックが相当量あります (これらがフィーチャーフォンだけではないことを認識することが重要です。これらのデバイスは、スマートフォンより若干古く、また安いのです)。

ここに、私が披露できる幾つかのサイトの例を挙げます (NDA のため、2つは名前を明かすことができません)。

  1. EU で広く知られたブランド、マスマーケット製品に基づいたEコマース。トラフィックの 50% 以上が iOS だが、ロングテールで 30-40% が Android デバイス (スクリーンサイズは 240 から仮想タブレットサイズまで)。その半分が Blackgerry と Nokia のスマートフォンで、10-15% が初期に売られたスマートフォン (例えば初期の Samsung/LG のタッチデバイスで、とてもベーシックな OS あるいはブラウザを搭載し、導電タイプのタッチスクリーンで、解像度はとても低く、メディアクエリがサポートされないとても非力なデバイスです)。サイトに来るフィーチャーフォンのトラフィックは非常に少数かつ複雑であり、おそらく、古いデバイスでは全く計測されていません。
  2. UK で広く知られたブランド、コンテンツ・ヘビーで高いトラフィック。トラフィックの 50% が iOS だが、ロングテールの Android デバイス (500-600の異なるスクリーンサイズがあることから、Web を見るアプリが使われている模様) も相当数ある。続いて、例1同様の第1世代のタッチデバイス。最も人気のあるスクリーンサイズは、240×320 で、$100 かそこらの Android デバイスでしょう。古い Sumsungs 同様、非力で解像度が低く、Android のバージョンがちょっと古い。
  3. http://browser.nokia.com/ – レスポンシブなデザイン、かつサーバーサイドとクライアントサイドでの適応を組み合わせた (クライアントサイドの負荷を最小化するため) モバイル・ファーストなサイト。サイトのビジネス目標がブラウザの更新を促すことなため、出来るだけ数多くの Nokia デバイスをサポートするのが任務となります。サイト・トラフィックの大多数は、100以上の異なる Nokia デバイスで、きっと放り出したくなることでしょう。多くの Android と140を超える国々からのグローバルなトラフィック (EU と US からのヘビーなトラフィックを含む。最近の Nokia のマーケットシェアから想像される、経済振興国やインドからではありません) があります。プロジェクトの詳細は、Pragmatic responsive design にあります。(訳者注:数多くの端末に対応するためには、モバイル・ファーストでもデスクトップ・ファーストでもダメ的なことが書いてあって、このスライドは面白いです)

これらの ページビューのシェア はさらに疑わしい。人々は実際、そういったデバイスでブラウザを使ってるのか?

上で述べた Nokia サイトは、これらのデバイスからの閲覧がほとんどです。彼らは特定の統計を公表していませんが、Facebook と Twitter でも同様だと思います。見るべきは、前者の Facebook のマーケットでしょう。例えば、インドネシアが上位5位に入っています (そして、しばしば2-3位になる)。インドネシアのモバイル市場の状態を考えれば、全てのトラフィックが、ハイエンドのスマートフォンからであるとは限らないのです。同様の数字は、Twitter でも聞いたことがあります。多くの進展国で、Facebook がゼロを付けている理由でもあります (即ち、無料の 0.facebook.com ドメインでアクセスのコストを助成している)。モバイルデバイスは、多くのユーザーの主要なアクセスポイントであり、これらの人々は間違いなく iPhone は持っていないのです。

他の良い例は常に、Opera Mini の統計です。そのプロキシー化されたページ・ビューの大部分は、フィーチャーフォンとローエンドのスマートフォンからのものです。モバイルサイトの統計については、Opera: State of the Mobile Web report に掃いて捨てるほどのデータがあります。それ故、この場合の答えは Yes であり No です。彼らはネイティブのブラウザを使う代わりに、彼らのデバイスにインストールしたより適切なブラウザを使っているのです。

しかし全体としては、サイトを最適化するほど、元々は期待していなかった他のデバイスからのトラフィックが増えるということに気付きます。多くの人々は単にログをちょっと見ただけで、iOS に注目し、それがすべてだと思ってしまいます。これが、人々が訪問したときに貧しい経験をし、そして二度と戻ってこないという明らかな悪循環を引き起こします。サイトの情報が、実際に人々が単に欲しているものではなく、必要としているものの場合、どのようにトラフィックが広がるかを見ても面白いでしょう (例えば、医療情報、政府/税金/年金関連のコンテンツ、預金/保険やニュース速報など)。もちろん、必要 VS 欲求は主観的、一時的なものですが、モバイルのトラフィックがあっという間に成長している理由でもあるのです。

残念なことに現時点では、Google Analytics は、モバイルか通常のスクリプトかの選択次第で、提供されるデータが大きく異なります。これには正当な理由があります (例えば、クライアントサイドのクエリでは提供することの出来ない要素のために、モバイル版は UA 文字列から知識を引き出します) が、それらに何が出来て、何を追跡できないのかに関して、多くは表層的で成り行き任せです (例えば、Android デバイスの区別は決してログには現れず、全体として Android のプラットフォームであることが分かるだけ)。次期 Google Analytics では、その問題が解決することを願っています。

次のような質問に行き当たる:モバイルでは決して使わない CSS のダウンロードがどのぐらい必要か、そしてそのサイズは、HTTP リクエストの追加より価値があるのか

私の経験では、追加の HTTP リクエストは、ごくわずかです。ユーザー利益のために注意深く選択されたものは、常に価値があるものです。

最も良い例は、例えば Facebook ウィジェットのような 3rd パーティーのリクエスト、アナリティクス、コメントのホスティングを行うユーティリティー・サービス、さらには特定のポリーフィルなど、制御できない全ての HTTP リクエストとの対比をしてみることです (Pragmatic responsive design の26-34ページを見てください)。(訳者注:Facebook の Like ボタンが 84KB で10個もの HTTP リクエストを必要する事実を指していて、それに比べれば…ということです)

私は何も HTTP リクエスト数を無視することを推奨しているわけではありませんが、CSS と関連するファイルをどのように構成するかを決めることは、その後に出来ることの全てに決定的なインパクトを与えます。それは、将来のデザインの決定に重要なインパクトを与えるばかりか、多くはパフォーマンスにも影響を与えるのです。1つの HTTP の追加を心配するあまりに独断的な決定をすることは、本当に恥ずべきことで、最終的には完全に逆効果となります。このことは、次の最後の点にもつながります…

そうだ。H5BP は、レスポンシブでありたいし、それを正しくやりたい。
そしてこれらのアプローチは、それが正しいことを裏付けるデータが必要だと強く感じている。

現時点で不幸な事実は、これらの問題に誰も正解を答えられないことです。モバイル・ファーストの RWD (あるいは、各要求元のデバイスの能力が既知であることを仮定しない先進的な考え方による開発) は、数多くのローエンドデバイスをターゲットとした場合に、利点があることが証明されています。単にスタイルシートの配置で終わる話ではなく、自分たちのプロジェクトにとって何がベストなのかを決めなければならないことなのです。私はそれを責任回避だとは思わないし、私たちがますます直面することになる現実であり、そしてそれは実際に良いことなのです。例えば、ログを注意深く観察し、トラフィックが実際にどこから来ているのかを理解しなければならない点が挙げられます。Brad が述べているように、ある巨大なグローバル・ブランドでは、例えば SONY PSP のような普通ではないデバイスさえサポートしています。そうしなければ、IE と同じぐらいのトラフィックを失うことになるからです (そんなことはしたくないと誰もが知っているのです)。こういったことは、ボイラープレートには入れられないでしょう。

gravatar

@paulirish:

次のような質問に行き当たる:モバイルでは決して使わない CSS のダウンロードがどのぐらい必要か、そしてそのサイズは、HTTP リクエストの追加より価値があるのか

もし私の理解が正しいなら、ワイドなビューポートをターゲットとしたメディアクエリの中で @import を使うことが出来る。これは Opera Mobile / Mini と最近の Webkit (おそらく他も) は、追加の HTTP リクエストを発生させない。メディアクエリが適用された時にだけ外部のリソースをダウンロードするのだ。これは、ワイドなビューポートをもつデバイス (即ちデスクトップ) の時だけ、HTTP リクエストが発行されるのであり、コストはそれほどではない。古い Webkit のバージョンとおそらく他のブラウザは、使う/使わないに関わらず全てをダウンロードする – 分からないことが大きな問題だが。

君の話していることは、こういうことなんだっけ? 🙂

@stephrieger

彼らはネイティブのブラウザを使う代わりに、彼らのデバイスにインストールしたより適切なブラウザを使っているのです。

参考情報だが、Opera Mini はメディアクエリ (と viewport) をサポートしてはいるが、ポートレートとランドスケープを切り替える際、再計算されたメディアクエリのリフレッシュを要求するのだ。

@tchalvak

私は君たちのことは知らないんだが、色々なモバイルのブラウジング・テストを行うのに、デスクトップ上のエミュレータを1つ得るのでさえ、かなりのトラブルに見舞われているんだ。

Opera Mobile Emulator は試してみたかい? Linux 上でもうまく動作するはずだヨ。

gravatar

@anderasbovens

もし私の理解が正しいなら、ワイドなビューポートをターゲットとしたメディアクエリの中で @import を使うことが出来る。これは Opera Mobile / Mini と最近の Webkit (おそらく他も) は、追加の HTTP リクエストを発生させない。メディアクエリが適用された時にだけ外部のリソースをダウンロードするのだ。これは、ワイドなビューポートをもつデバイス (即ちデスクトップ) の時だけ、HTTP リクエストが発行されるのであり、コストはそれほどではない。

Andreas、君がそれを知っていることは分かる。しかし、コミュニティーの利益のために忘れずに書いておく。狭いビューポートのリクエストは必ずしも高コストではないし、広いビューポートでも必ずしも低コストでもない。ここではそれを モバイル と呼んでいるが、狭いビューポート、広いビューポートと言うときには、単にビューポートの幅のことを言うのであって、それ以外のつながりのことは指していないのだ。

gravatar

@sturobson、私たちは、IE6-8 のために Respond.js を外そうと言っているのではありません。それが含まれていること自体が第1の理由です。元の考えは、Respond を Modernizr から外し、それを含むならより明示的に、削除する場合も、よりオープンにすることだったはずです。しかしともかく私たちは、デフォルトで Respond を外すのが良さそうですネ。

私は最初のコメントで、メディアクエリに関する議論の文脈で実際重要な モバイルビューポート を区別するべきだと言いました。しかし、レスポンシブ/アダプティブなデザイン はビューポートのサイズやデバイスに関することだけではありません。それはプロセスであったり、柔軟かつアダプティブにコンテキストを閲覧させる最終製品を包含する、とても広範な用語なのです。

gravatar

@necolas、自分の書いたことの大部分を撤回する。44時間で2時間の睡眠がそれを物語っている。そのコメントに加え、曖昧な可能性のある4つの文章に関することも削除したし、君が反対する件も分かった。何よりも私は疲れ過ぎている。

gravatar

たぶんオレは何か大きな点を逃している。一体全体、なぜオレたちは IE6-8 のためにメディアクエリをケアしなくちゃならないんだ? オレの経験上、デスクトップ用のメディアクエリをコンテンツに、ie < 9 & not mobile* という1つのコンディショナル・コメントを貼付けるだけで十分だ。オッと、空のコンディショナル・コメントが先だ。

モバイル・ファーストにしろ、レスポンシブ Web デザインにしろ、ブラウザのウィンドー・サイズを変えたときに、自分自身で再配置するサイトだけがメディアクエリの肝心な点ではない。それはコンテキスト上の変化であり、ブラウザのウィンドーサイズの変化ではない。便宜上、サイズを通して変えているに過ぎない。そしてセクシーに、ウェッブをもっと生き生きとさせるものだ (もっとも、開発者にとってだと思うが)。

もし、アプリケーションが静的な冊子のようなポートフォリオ・ページ/サイトなら、メディアクエリだけで十分だろう。しかし、事はもっと複雑で、ウィンドーのリサイズに反応しない JavaScript のレイヤーがあることだ。それには特徴の検出か、ユーザーエージェント文字列による嗅ぎ分けを使うことになるだろう。

なぜ IE9 未満でメディアクエリを機能させることに価値があるのか、オレには理解できない。

モバイル・ファーストは、始めは違和感があるが、最初の段階からコンテキストの置き換え考えることは、CSS を追加するに値する。加えて、キャッシュ化と最小化だ。

オレは、議論の理由すべてを掘り起こせると思うが、ボイラープレートでは、やみくもに実装されることもあるだろう。コメントを探してみれば、製品版のソースには未編集の項目が見つかるだろう。

今日はハッピー・チューズデイだ。愛を込めてハグしよう。

* Mobile Windows 7 じゃなければいいのに! その次は新しい Mango のホットな IE9 モバイルか?

gravatar

@sturobson、:( 私が反対するとかどうかは問題ではありません (そうはしないでしょうし、私が間違っているかもしれません!)。あなたの考えを聞くのことは喜ばしいことです。

gravatar

@necolas、ありがとう。ともかく私はまず眠った上で、Comment を押す前に書いたことを良く確かめることにするヨ。

gravatar

@lewisnyman – 悲しいことにね 🙁 。 我々は、君が何かデカイことをしていると思っていた。誰かが IE6-7 の振る舞いをエミュレートする IE8 用のハックを見つけること を願うよ。

@folktrash – IE6-8 は単純なメディアクエリはサポートしているが、IE6-7 は複雑なメディアクエリのルールを 無視する。もし この振る舞いを IE8 に拡張する方法 を見つけることができれば、古い IE にメディアクエリのスタイルを相も変わらず公開すれば、モバイル・ファーストのスタイルシートただ1つで済む。現在 IE6-7 と IE9+ に対してはメディアクエリを適切にサポートすることが出来るが、IE8 がストッパーなのだ。現在の最小限の選択肢 は、ちっとも良くないのだ。

gravatar

@oli、そのアプローチは理にかなってると思う – デスクトップ用コンテンツのメディアクエリを含む ie.css はコンディショナル・コメントで、モバイル・ファースト用は style.css で。ウィン・ウィンだ。追加の HTTP リクエストがいるって? Respond.js だってそうじゃないか。加えて、破綻しない。それらはデスクトップ用バージョンを得るからだ。そして、IE6-8 はデスクトップのコンテキストでしかあり得ない。

どんなハックを使ったメディアクエリよりも、これ以上のものはないんじゃない? 思わず興奮しちゃうよ。

デスクトップのコンテキストしかあり得ないユーザーエージェントに、メディアクエリをサポートするのは理解しがたい。ウィンドーがリサイズされた時に、柔軟にサイズを変えられるから? まさか、それはあり得ない。

コンディショナル・コメントのアプローチは、全データを与えるベストなアプローチに見える。単純だし、性能も問題ない。ボイラープレートにはぴったりだ。今後もすべてうまく行くし、そうあるべきだ。

Respond.js の追加された複雑さ (そして CSS のアレコレに注意する) が、単純な CSS ファイルベースの解決策に比べて、どれぐらい良いのか、オレには全く見えない。

加えて、スクリプト好きなら ie.css を自動的に生成すればいいじゃないか!

これが問題になるのか理解していないだけだから、オレを疎まないでくれ!

オレの1票:もちろん Respond.js を削除。そしてモバイル・ファーストを続けよう!

gravatar

おっと、オレとしたことが、すっかり舞い上がっちまったぜ。もう一度、まとめるよ。
何がいいかって? メディアクエリのハック? そんなのごめんだネ。
コンディショナル・コメントはエレガントで、単純で、優秀だ。そして、コンピュータのスクリプトを通して生成することも出来る (コピー&ペーストがいい)。

IE6-8 だけがデスクトップのコンテキストで存在する。これで問題になるかい?

まったく木曜日だっていうのに、オレとしたらインターネットに恋しちまって、イヤになっちゃうゼ!

gravatar

@folktrash、議論を続けるように努力してください。約束します。私たちはは決して馬鹿ではありません 🙂 。私たちはただ、選択肢について話し合っていて、他の議論と同様、いろいろな意見があることが重要なのです (良い面/悪い面が明らになり、たとえそれが満足できなかったとしてもです)。

追加の HTTP リクエストがいるって? Respond.js だってそうじゃないか

Modernizr か、ビルド処理で結合された head 中の他のスクリプトに含まれているなら、そうではありません。

そして、IE6-8 はデスクトップのコンテキストでしかあり得ない。

IE7 のレンダリング・エンジンは、Windows Phone 7 にも使われているのです。

Respond.js の追加された複雑さ (そして CSS のアレコレに注意する) が、単純な CSS ファイルベースの解決策に比べて、どれぐらい良いのか、オレには全く見えない。

追加された複雑さなどありません。CSS をモダンブラウザ用に記述すれば Respond.js が IE をケアしてくれるだけです。

私たちは、数少ない選択肢を見出し、最も問題が少なく、最も将来にわたって有効な解決策をバランスよく検討しようとしています。議論とアイディアを出し続け、テストケースを考え続けることが大事なのです! たくさんの人が経験と専門性を共有することはすばらしい事です。

gravatar

おっと、間抜けだったぜ、その通り、まったくだ。

  • 結合しておけば、追加の HTTP リクエストは不要だ。
  • IE7 (と8のハイブリッド) Windows モバイルのエンジンは、Mango になっても変わらないだろ? それと、問題は !mobile のコンディショナル・コメントで解決できる、だろ?
  • そうだ、オレは Respond.js が CSS でつまずいたように思い違いをしていたんだ。

最も問題が少なくて将来も保証された、コンディショナル・コメントでの ie.css ファイルのアプローチに1票だ。

ナイスでいてくれてありがとう。オレは、H5BP をかけ離れちまっていたけど、そこに Respond.js があることに驚いてたんだゼ。

gravatar

Mango になっても変わらないだろ? それと、問題は !mobile のコンディショナル・コメントで解決できる、だろ?

その通り!

そうだ、オレは Respond.js が CSS でつまずいたように思い違いをしていたんだ。

正に完全じゃない事が、ボイラープレートのデフォルトから外す理由の1つです。そして CSS による方法が、見苦しいが、確実な方法です。

gravatar

オレたちは今、デートしてるような気分だ。そしてこのプロジェクトにはとても興奮させられる。インターネットでつながってるってことは、幸せだネ。

gravatar

ここに、モバイル・ファーストがなぜ優れているかの記事がある:Athena – MediaWiki (訳者注:スマホ、タブレット、デスクトップに完璧に対応する Wiki のスキン Ahena の紹介記事です)

gravatar

まだコンセンサスが得られたとは思えないんだが…

この問題は、1つですべてのサイズにフィットする 解決策に関することではないと思う。狭いビューポート広いビューポート の問題を後回しにするよりも、たぶんいくらかの CSS を書いてみるべきでは? でも何か意見があるなら聞きたい。

それにしても、なんてすばらしいスレッドなんだろう!

gravatar

すばらしい議論だね。

Respond.js の必要性をなくす ie.css のアイディアのことだけど、理解できるし、1つの CSS ですべてのブラウザに対応しようというゴールは評価できる。私は今まで Respond.js を使ったモバイルファーストのアプローチを実践してきた。だけど、ここで議論している選択肢である、Respond.js を落とし、古い IE にはデスクトップ用のスタイルをコンディショナル・コメントで用意するという単純な方法が良いと思う。

私の理解が正しいかどうか、確認させてもらいたい。

  1. Respond.js へのリンクを張る代わりに、IE6-8 かつ !mobile ... のコンディショナル・コメントがあればよい。
  2. メインのスタイルシートの後に、コンディショナル・コメントで IE6-8 のスタイルシートを配置する。このスタイルシートには、メインのスタイルシートで IE6-8 が解釈できないメディアクエリの代わりに、デスクトップ用のスタイルだけを定義する。

もし私の理解が正しいのであれば、これには長所と短所がある:

  • IE6-8 用は、Respond.js の JavaScript 実行のオーバーヘッドをなくす代わりに HTTP リクエストが1つだけ追加される。
  • メインのスタイルシートに (リセットやタイポグラフィ、その他の)基本的なスタイルが定義され、次いで、デスクトップ用スタイルが後に続く。
  • IE6-8 のいずれかのバージョンをサポートするには、IE 用のコンディショナル・コメントと IE 用のスタイルシートを使う (もし IE6 が不要であれば、IE7-8 だけのコンディショナル・コメントを使えばいいし、その場合 IE6 は、メインのスタイルシートに定義された基本のスタイルを使うだけだ)。

合ってるかな?

gravatar

待てよ、私は、これまで議論された Jeremy Keith の記事 Adactio: Journal—Windows mobile media queries に従っているだけだ。

彼の解決方法は、上記よりもっとエレガントだ。2つのファイルを使って、

  • global.css で、モバイルファーストなスタイルを含めすべてのブラウザ用の基本スタイルを定義。
  • layout.css で、広いビューポートを持つブラウザ用のレイアウトを定義。

次に彼は、layout.css を提供するために、必要に応じてメディアクエリとコンディショナル・コメントを使う。

  • モダンな広いビューポートを持つブラウザにはメディアクエリを
  • IE6-8 にはコンディショナル・コメントを

彼のコードに私のコメントを付けるとこうなる。

<!-- Base styles for all browsers -->
    <link rel="stylesheet" href="/css/global.css" media="all">
<!-- Layout for wide browsers -->
    <link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!-- SAME layout file for IE 6-8 -->
    <!--[if (lt IE 9)&(!IEMobile)]>
        <link rel="stylesheet" href="/css/layout.css" media="all">
    <![endif]-->

この方法の利点は明らかだ。つまりこのアプローチは、

  1. すべてのブラウザに基本のスタイルを与え、
  2. 狭いビューポートを持つブラウザの要求に応えるために、CSS レイアウトファイルを賢く使い、
  3. (分離したファイルにコピー&ペーストすることなく) ただ1つの layout.css ファイルだけで済む。

加えてこのアプローチは、レイアウトをサポートしたい IE のバージョンだけをコンディショナル・コメントで調整できることだ。例えば IE6 用のレイアウトを望まなければ、次のようにすれば良い:

<!-- layout file for only IE 7-8, excluding IE 6 -->
    <!--[if (gt IE 6)&(lt IE 9)&(!IEMobile)]>
        <link rel="stylesheet" href="/css/layout.css" media="all">
    <![endif]-->

さらに、(タブレットのような) 中ぐらいの幅のデバイスや超幅広のモニター用にもっと詳細なメディアクエリを望むなら、このアプローチをちょっと変えることでそれらのケースを簡単にカバーできる。タブレット幅のレイアウトは global.css のメディアクエリに入れるのが簡単だし、Mongo 幅のレイアウトは layout.css のメディアクエリに指定すればいい。

gravatar

君はおそらく スモールスクリーン・ファースト を言いたいのだろう。私の見解では、デザインの前にメディアクエリを設定するのは悪い考えだ。そしてまた、デザインは 最初に メディアクエリありきでされるものでもない。スモールスクリーン上では一般にリキッドなページがうまく働く。次に デザイン上の分岐点にメディアクエリを使う。デバイスの分岐点ではない。モバイル・ファーストとは、そういうことなんだが、最適化は常に考えられなければならない。

gravatar

@scottkellum

君はおそらく、スモールスクリーン・ファーストを言いたいのだろう。

この議論の 最初の方のコメント でそれは既に述べています。

私の見解では、デザインの前にメディアクエリを設定するのは悪い考えだ。

それも既に議論されています。H5BP はデザインの必要性に応じて、カスタマイズすべきプレースホルダーとしてのメディアクエリを入れ込んでおきたいだけです。

デザインは最初にメディアクエリありきでされるものではない。

これは既に H5BP が採用している方法です。

次にデザイン上の分岐点にメディアクエリを使う。デバイスの分岐点ではない。

既にこれも勧めたし、Paul の コメント を含め、あらゆる issues で議論していることです。

gravatar

@davidcochran、Jeremy Keith の記事 Windows mobile media queries と君の説明によれば、「global.css は、モバイルファーストのスタイルを含み、すべてのデバイスに基本的なスタイルを提供する」 一方、「layout.css は広いビューポート用のレイアウトを提供する」 ことで、メディアクエリを解釈しないブラウザ用に使うと言うんだね。だとすれば、私の理解が正しければ、どこにもメディアクエリが使われないことになる。

質問:
メディアクエリを解釈しないブラウアが、どうやってメディアクエリを使ってスタイルシートをダウンロードするんだ? メディアクエリを解釈できるブラウザがダウンロードしたファイル (layout.css) 中の CSS で、よりクリーンかつエレガントにメディアクエリを定義でるんじゃあないのか?
IE が理解できないメディアクエリは、IE 専用のスタイルシートで定義するのがより美しいのではないか? この方法は、9未満の IE (IE8 は続けるべきかな?) へのサポートをやめる日までにすればよく、CSS とコンディショナルな宣言文回りをただ削除すれば良いだけではないか?

@necolas の記事 “Mobile first” CSS and getting Sass to help with legacy IE – Nicolas Gallagher は、もっとクリーンで簡単に扱う方法を示唆している。ただ SASS を使うのが条件だが。ただこれら全ての @import がパフォーマンスに及ぼす影響は分からないが。

core.css
正規化、タイポグラフィ、そしてグリッド (あるいはグリッドレス、フレームレスなども良い) のスタイル。メディアクエリは使わない。
layout.css
@media (min-width:320px) { @import "320-up"; }
@media (min-width:480px) { @import "480-up"; }
@media (min-width:780px) { @import "780-up"; }
@media (min-width:960px) { @import "960-up"; }
@media (min-width:1100px) { @import "1100-up"; }
ie.css
@import "320-up";
@import "480-up";
@import "780-up";
@import "960-up";

みんな、これはどう思う? 何も問題がないと思うんだが!

gravatar

@matteolc

@necolas の SASS を使った方法もすばらしいし、類似の方法である LESS のユーザーも同じように出来るだろう。

しかし H5BP は、だれもがこれらの技術を使っているという前提や、CSS が SASS や LESS と同様に機能するよう作り替えられる (なったらすごいことだ!) という前提には立てない。

SASS / LESS を使っていないユーザーにとっては、2つの CSS ファイルによる解決策が、次の点でとても簡単で良い。第1に、全てのブラウザを対象としたグローバルなスタイル (狭いビューポートのブラウザにも必要な全て) という点、第2に、IE6-8 に必要な一切のデスクトップ用スタイルという点だ。

なぜなら、古い IE はメディアクエリを単に無視するだけだし、これらの2つのファイルは、メディアクエリを解釈できるブラウザ用にも等しく使うことが出来るからだ。タブレット用のレイアウトを global.css に、また巨大なスクリーンサイズ用のレイアウトを layout.css のメディアクエリに詰め込むことが出来る。IE6-8 はこれらがそこにあるということすら知らないのだ。

もちろん、IE6-8 に不可欠なことがメディアクエリの中であってはならない。当たり前だ。

以上から、次のような、比較的すっきりとしたことが言える。

  • 開発者に SASS か LESS の使用を強いてはならない
  • メンテしなければならないファイルは2つだけとする
  • IE6-8 に必要なファイルはすべて、Respond.js という負荷なしに、至って普通の方法で与える
  • もちろんモダン・ブラウザに必要なメディアクエリも忘れてはならない

これでみんなのニーズを満たし、できるだけ IE6-8 (こいつらがいつまで持つかは勝手だが) にも負荷をかけずにできる。

gravatar

@matteolc

君のをもう一度良く読んで考えてみたんだが — 誰かが君のやり方にならい、製品化の前に CSS のインポートをインライン化する新しい H5BP のビルド・スクリプトと組み合わせるとすると…

そいつはものすごくエレガントだ。それぞれ場合分けされたメディアクエリのスタイルを1つにまとめて読み込むための core.css にかかる HTTP リクエスト以外はね。

こんな風になるんじゃないかな。

modern.css — モダン・ブラウザに必要な一切

  • core.css をインポート
  • 全メディアクエリのスタイルをインポート

legacy.css — IE6-8 に必要な一切

  • core.css をインポート
  • 960 基準のスタイルをインポート

利点

  • ビルド・スクリプトの助けを借りれば簡単にできる
  • CSS ファイルを特別に分ける必要がなく、それらを別々にインポートするだけ
  • Respond.js で IE6-8 に負荷を与えない
  • モダン・ブラウザにも古い IE にも、ただ1つのスタイルシートを与えることになる (どちらの場合も HTTP リクエストは1つ)
gravatar

@davidcochran、君は私よりうまく利点を強調してくれたネ! 🙂

  • それらを別々にインポートするだけ。エレガントだよネ?
  • Respond.js で IE6-8 に負荷を与えないで済む。そう、そう、そうなんだ。標準に準拠しないブラウザに対応するために追加の JS を使うのは、個人的には反対なんだ。

そして、そうだね。製品ファイルが、インラインのインポートで作れるなら、何も言うことはないね。

具体的に言えば、

-# Layouts for MQ-capable browsers
= stylesheet_link_tag "modern", :media => "(min-width: 320px)"

-# Serve a stylesheet without @media declarations for the oldies, and skip serving it to IE mobile
/[if (lt IE 9)&(!IEMobile)]
= stylesheet_link_tag "legacy" 

が、次のようになる。

modern.sass

@import "core"
@media (min-width:320px) { @import "320-up"; }
@media (min-width:480px) { @import "480-up"; }
@media (min-width:780px) { @import "780-up"; }
@media (min-width:960px) { @import "960-up"; }
@media (min-width:1100px) { @import "1100-up"; }

legacy.sass

@import "core";
@import "320-up";
@import "480-up";
@import "780-up";
@import "960-up";

順調でしょ?

君が言ってた @import で製品時にインライン化すれば、私が元々言っていたものに比べ、1リクエストが節約できるね。

gravatar

もう一度戻ってみようと思う:

/ Core layout (no media queries)
= stylesheet_link_tag "core"
/ Layouts for all viewports (with media queries)
= stylesheet_link_tag "responsive", :media => "(device-width: 320px)"

/ Serve a stylesheet without @media declarations for the oldies,
/ skip serving it to IE mobile
/[if (lt IE 9)&(!IEMobile)]
= stylesheet_link_tag "static" 

これが IE8 で responsive.css をダウンロードしてしまう理由だ。このように static.css にあるのと同じように @import を置くならば、重複が生じてしまう。

実際には :media => "(device-width: 320px)" は、全く必要ないかもしれない。

gravatar

Juriy Zaytsev が Profiling CSS for fun and profit. Optimization notes. で、使っていない CSS セレクタがパフォーマンスに与える影響 を実験している。それによると、古い IE に読み込まれたセレクタは (Note 13 とそのサマリーを見よ)… (訳者注:それぞれのクラスに IE 用の定義を.ie7 などのセレクタで追加すると、IE 以外のブラウザにその解釈で余計な負荷を与えてしまうという内容。IE 用はまとめて1つにファイル化し、コンディショナル・コメントで読んだ方がパフォーマンス上は良いというのが結論)

これで 2つのスタイルシートのアプローチ を勧めない方がおかしい。メディアクエリを解釈できないレガシーなブラウザ用のスタイルを別なスタイルシートに分けるというアプローチだ。– 典型的には IE6-8 にコンディショナル・コメントで与える。

2つのスタイルシートのアプローチ をもっと簡単に扱うために、例えば SASS か ANT のビルド・スクリプトのようなツールを使った良い方法を構築できれば、さらなるメリットを確実に得ることができる:Respond.js の代わりに、より整然としたスタイルシートを使って、よりキビキビとしたウェブ・アプリが約束されるのだ。

gravatar

デフォルトでは何の解決策を提供しない (なぜなら、そんなものはないから) … という解決策を提案します。

  1. H5BP の Modernizr パッケージから Respond.js を削除する。
  2. Wiki ページを作り、モバイル・ファースト にアプローチする一般的な方法を記述する (そのうちのどれかが IE の古いバージョンの要求を満たす)。そうしておけば、各自がプロジェクトの要求に合う解決策を決める時に参照できる。
  3. これはオプションだが、デフォルトの CSS からメディアクエリのプレースホルダーを削除する。
gravatar

@necolas、そのソリューションに +1、リストの最後の項目にも。

gravatar

@necolas、そのWiki ページは、ここで議論されたグレーな議論を明瞭に表現するすばらしい方法だと思う。最後の点に関しては、デバイス固有のサイズを含むのは間違えなく危険だと思うが、構文理解を助け、優れたテクニックに対する認知を広げていくためには、例題を入れることは依然としてメリットがあると思う。デバイスに依存しない、例えば em ベースのサイズ (min-width: 35em ?) か何かに変更すれば、おそらく正しい方向に向かうだろう。

gravatar

@bradfrost、コンテンツの要求に応じて修正できるようなプレースホルダーの設置について、私たちは既にコメントの中で述べています (それらのコメントで明らかだと思ったのですが)。

ただし、em を使うかどうかは別問題だと思います。多くのサイトで (未変更の) style.css がその基本 CSS として使われているのを私は見てきましたが、空のメディアクエリがそこに何もせず放置されています。コード中、他の箇所でそのメディアクエリを使っているにも関わらず、です。ダミープレースホルダー のコードは、できればどこか別の箇所に移した方が良いと私は思います。すぐにはクロスブラウザな働きをしない重要なコードの場合は、尚更です。

gravatar

@necolas、そうだね、もし君がそれらを修正せずそのままそこに放置しているケースをたくさん見てきたのなら、それらをすっかり削除するのが賢明だね。ただ、もしそのままにするなら、固有のデバイスを思い起こさせるモデルとしないためにも、480px と 768px をもう少し曖昧なサイズに変更することを勧めたい。

gravatar

@necolas、px ベースのメディアクエリを em ベースに変えることに関して、私は全面的に @bradfrost に賛成だ。バカの1つ覚えのように繰り返された、曖昧さとデバイス特有のブレークポイントに関する Brad の最後の文章がその理由だ。

Wiki に関しては、すばらしいアイディアだ 😀 。

gravatar

オレは、CSS 中のデフォルトのメディアクエリはすばらしいツールだと思う。もし人々がボイラープレートの CSS を無修正でただ使うのなら (そして CSS の他のブロックに分けて修正しているのなら)、ただのオーバーヘッドとなるだけなので、使っていないメディアクエリのブロックはコメントアウトすれば良い。しかしそれらを完全に削除し、外部のドキュメントで伝えることをデフォルトにしてしまったら、それは大きな後退だ。

P.S. 選択肢を提示する以前に、(我々が生きるこのクレイジーなブラウザー環境の中では、たとえそれがどんなものであろうとも) 機能する解決策を取り外しちゃうのは、本末転倒だと思う。だからまず最初に Wiki ページから始め (まだないよネ)、確実にそれらを得られるようにしてから、共存できるツールを取り外そうじゃないか。どうだい?

gravatar

gravatar necolas Respond を削除するために Modernizr を更新。メディアクエリのプレースホルダーを変更。

af98e6f
Closed

gravatarnecolasclosed the issue in af98e6fJanuary 24, 2012

gravatar

私は、ここで議論したすべての問題のバランスを取るようにしました。手助けをしてくれた、そしてこの問題に意見やアイデアを投稿することに時間をとってくれた皆様に感謝します! これからも、提案や情報で手助けしてくれれば幸いです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

海外からの投稿は受け付けていません