大きなCSSメディアクエリの間違い

公開: 2017-05-15

あなたの周りのみんながあなたが通常間違っていると思うことをしているとき（または少なくとも理想的ではない）、どういうわけか誰も何らかの理由で何も言いたくないように見えるとき、あなたは奇妙に感じることがありますか？誰もが不幸な観察者の最高の印象を与えているのを見るのは非常に奇妙な気持ちです。あの古い寓話「皇帝の新しい服」を思い出させてくれます。

私はCSSメディアクエリについて常にそのように感じてきました。なぜ誰もが仕事を成し遂げていないように見えるテクノロジーをとても受け入れているのですか？なぜ私たちはコミュニティとして集まって、本当の意味のある方法でそれを改善しなかったのですか？なぜもっと良いものを考え出さなかったのですか？

今日、CSSメディアクエリは、レスポンシブWebデザインの機能の基礎となっています。しかし、それは今日誰もがそれを使用しているもののために設計されたことはなく、その証拠は実際にあります。最初はうまく設計されているように見えるタブレットデバイスを使用しているときに、私はまだWebサイトでつまずくことがよくありますが、それらのペースを試してみると、たまたま見た目も感じもまったく不安定です。

レスポンシブウェブデザインへのこのアプローチには根本的に問題がありますが、まだ適切に対処していません。私は、皇帝に裸でいることを呼びかける数少ない声の1人になりたいと思います。ありがたいことに、この時代では、この代替的な視点を持っていることで火刑に処せられる可能性はほとんどないことを嬉しく思います。

CSSメディアクエリの何が問題になっていますか

CSSメディアクエリは何かのために設計されましたが、それはレスポンシブWebデザインではありません。私の経験に基づいて、Webサイトでの作業にそれらを使用しようとしたときに遭遇した7つの大きな問題を次に示します。

1.直感的ではない：

「CSSメディアクエリは直感的です」と、これまでWebデザイナーは言いませんでした。メディアクエリを定義する方法は非常に簡単ですが、実際のブラウザ、実際のデバイス、および無数のシナリオで物事がどのように実行されるかは必ずしも正確ではありません。

 @media only screen and（min-width：320px）and（max-width：480px）{
    / ** CSSルールはここにあります** /
}

上記のコードは、ビューポートが320〜480ピクセルの場合に適用されます。ただし、デバイスが横向きの操作でタブレットである場合にスタイルルールを適用するなど、より具体的なことを実行したい場合は、正確に決定的[または直感的]ではありません。これを行うためにメディアクエリを設定することは不可能ではありませんが、それは間違いなく直感的ではなく、決定的なものでもありません。

2.限定された条件：

CSSメディアクエリは動的であり、CSSで条件付きステートメントを定義できます。たとえば、ビューポートがこれとそれの間にある場合は、もう一方を実行します。ただし、ほとんどの場合、ビューポートの考慮事項に制限されており、最新のWebデザインで意味のある条件付きシナリオは他にもたくさんあります。

タブバーのモバイルデザインガイドライン

プログレッシブウェブアプリを構築しているとしましょう。 OSに基づいて特定のUI要素のスタイルを変更すると便利な場合があります。たとえば、iOSデバイスの場合は下部にタブバーを配置するのが通例ですが、Androidの場合はその逆です。では、これをCSSメディアクエリでどの程度正確に機能させるのでしょうか。

CSSメディアクエリは、それを可能にする機能を備えて構築されていないため、できません。これに加えて、CSSを介して行う必要のあるカスタマイズが他にも多数ありますが、単純な条件から高度な条件までさまざまな程度が必要な場合、メディアクエリはオプションではありません。

3.ネイティブに拡張可能ではありません：

CSSメディアクエリは、ブラウザに組み込まれている機能です。これは、ネイティブに拡張できないことを意味します。つまり、CSSインターフェイスを介してCSSメディアクエリにネイティブに拡張機能を追加することはできません。

新しいCSSメディアクエリ機能が[長い間苦しんでいる] Web標準プロセスによって承認されたとしても、これらの機能がどこにでもあるために使用可能になるまでにはまだ時間がかかります。さらに、追加されたすべての機能が役立つとは限らないため、必要な機能が得られない場合は、特定の課題を解決するための別の方法を見つける必要があります。

もちろん、CSSを拡張する方法はありますが、JavaScriptを本当によく知っている必要があり、ほとんどのWebデザイナーにとって実用的なプロセスではありません。

4.改造には適していません：

これを信じがたい人もいるかもしれませんが、モバイルデバイスが登場する前は、実際には多くのWebサイトがあり、モバイル対応のWebサイトはありませんでした。その結果、これらのデスクトップ時代のWebサイトをアップグレードする必要がありました。

残念ながら、CSSメディアクエリはこのタスクにはあまり適していません。これらのWebサイトは、モバイルデバイスが関連する前に構築されたため、多くのWebサイトには、レスポンシブWebデザインに適さないデザイン要素があります。たとえば、サイドバー、テーブルベースのレイアウト、タブ付きコンテンツなどです。また、これらのWebサイトのかなりの割合がWordPress、Drupal、Magentoなどのコンテンツ管理システム（CMS）に基づいて構築されており、CSSメディアクエリ[フロントエンド]をバックエンドから効果的に統合することは、調整が非常に困難またはほぼ不可能です。

Magento Enterprise、WordPress、およびColdfusionに基づくカスタムCMSを使用するWebサイトを改造する必要があり、CSSメディアクエリを使用するとすべてのプロジェクトがまったく不可能でした[これは、すべてのクライアントが代替手段を使用する前に試したものです。アプローチ]。

5.コード効率が悪い：

CSSメディアクエリを使用してWebページをレスポンシブにするには、かなりの規模でコードを増やす必要があります。これらのディレクティブが[ブレークポイントで]機能する方法のため、すべてのメディアクエリブロックで個別のスタイルルールを定義する必要があります。

 セクション{幅：960px;}

/ *ポートレート* /
@media only screen and（min-device-width：320px）and（max-device-width：480px）and（-webkit-min-device-pixel-ratio：2）and（orientation：portrait）{
    セクション{幅：100％}
}
/* 風景 */
@media only screen and（min-device-width：320px）and（max-device-width：480px）and（-webkit-min-device-pixel-ratio：2）and（orientation：landscape）{
    セクション{幅：100％;}
}

上記のコードを書くとき、私の当初の意図は、すべてのモバイルデバイスでページの<section>要素を流動的にすることでした[幅100％]。ただし、ネイティブのデバイス検出機能がないため、モバイル指向のCSSメディアクエリブロックごとにスタイルルールを妥協して定義し、関連するすべてのシナリオで新しいプロパティが適用されるようにする必要があります。

これは、スタイルシートカスケードの機能効率と、 Do-not-Repeat-Yourselfの優れた開発原則が後部座席に座らなければならないことを意味します。

6.ワークフローの複雑さを増します：

CSSメディアクエリは、レイアウトのサイズ変更にほぼ完全に焦点を当てたレスポンシブWebデザインの非常に特定の側面のみを処理します。エルゴ、それ以上のことをするためには、違いを補うためにJavaScriptに頼らなければなりません。これにより、コードとツールの追加の学習要件が導入されます。

さらに、[メディアクエリ]がブレークポイントを処理する非決定的な方法は、多くの仮想および/または物理デバイスでWebページをテストして、物事が当初の意図どおりに機能することを確認するために、より多くの時間[およびお金]を費やす必要があることを意味します。また、レイアウトに大幅な変更を加えた場合は、すべてを再テストする必要があります。

CSSメディアクエリを使用するというシンプルで目的のあるアクションにより、最新のWebページを構築するために必要な手順の数を大幅に増やすことができます。

7.パフォーマンスの低下：

CSSメディアクエリの動作方法により、Webサイトをレスポンシブ/モバイルフレンドリーにするために、他の方法よりもはるかに多くのCSSコードが必要になります。 HTTPArchive.orgのデータによると、CSSファイルのサイズは過去5年間で114％増加しています。 HTMLファイルサイズの増加は、同期間に約53％でピークに達しました。

この特殊な状況は、CSSメディアクエリを[レスポンシブWebデザインコンテキストで]実装した後、特に理想的とは言えないモバイルブロードバンドネットワークを使用するモバイルデバイスの場合、これまでよりも遅くなるため、Webサイトのパフォーマンスに影響を及ぼします。

また、ファイルサイズの増加の問題を除けば、CSSメディアクエリには、Webページのパフォーマンスを実際に向上させるための内部メカニズムはありません。そのためには、高度なJavaScript技術を活用して、これらの拡張機能を有効にする必要があります。

なぜまだこれを使用しているのですか？

Webサイトの何パーセントがCSSメディアクエリを使用しているかを尋ねた場合、あなたの答えは何でしょうか？ Webデザイナーが何年にもわたって耐えなければならなかったすべてのストレスを考えると、おそらく今までに採用のこぶを乗り越えたと思うでしょうが、あなたは非常に間違っているでしょう。

Web全体でCSSメディアクエリを使用しているWebサイトの割合は約0.2％です。これを、jQueryを使用しているWebサイトの割合が18％であるのと比較してください。つまり、レスポンシブWebサイトよりもjQueryを利用したWebサイトに出くわす可能性が90倍高いということです[両方のWebサイトは含まれていません]。

特定の人々が複雑で不必要だと考えているコアテクノロジー[JavaScript]に基づくツールキットが、一見それほど複雑ではない[CSS]であり、間違いなくより重要な問題[モバイルフレンドリー]に対処することを目的としたツールキットよりもはるかに優れているのはなぜですか。？明らかに、採用を妨げている深刻な問題がここにあり、対処する必要があります。

CSSメディアクエリは、特定の課題を処理するためのWebブラウザーへの道を見つけましたが、レスポンシブWebデザインの全重量を肩に乗せるように作成されました。これは、3年生のレコーダーのリサイタルの練習のようなものですが、魔法のようにロイヤルアルバートホールに運ばれて、ヘンデルのメサイアのトロンボーンソロを演奏するだけです。ずるいです！

現代のウェブデザインのすべての課題がある中で、私たちがまだこのメディアクエリビジネスに取り組んでいることは非常に驚くべきことです。プログレッシブウェブアプリのデザインなどの新しい分野の新しい問題に加えて、いくつかの重要なレガシー問題に対処するには十分ではありません。そういうわけで、私たちは別の方法を思いついた時だと思います。しかし、それは正確には何でしょうか？

解決策は何ですか？

これらすべての解決策は本当に非常に単純です：JavaScript。さて、あなたがその熊手を手に取る前に、私に説明する機会を与えてください。

JavaScriptは、拡張性が汚い言葉ではないHTML5トリニティの唯一のコンポーネントです。より多くのHTMLを使用してHTMLマークアップを拡張することはできません。また、CSSをCSSでネイティブに拡張することはできません。ただし、JavaScriptを使用してJavaScriptをネイティブに拡張でき、CSSでも同じことができます。

JavaScriptを使用したCSSの操作については、W3CのWeb標準カリキュラムで詳しく説明されています。 document.stylesheets DOMインターフェースを使用すると、HTMLの<link>タグを使用して参照されるすべての外部スタイルシートを含む、Webページに適用されたスタイルシートにアクセスできます。簡単なことではありませんが、可能です。

したがって、最初の答えを拡張する必要があります。これは単なるJavaScriptではなく、 JavaScriptを利用したCSSです。 JavaScriptは、信じられないような機能を備えた素晴らしいプラットフォームですが、CSSはほとんどのWebデザイナーが働く場所です。 WebデザイナーがJavaScript機能を活用するCSSルールセットを作成できる、これら2つの間に何らかの機能的なブリッジを作成できれば、それはWebデザインのゲームチェンジャーになるでしょう。

コードを見せて

過去2年ほどの間、私はrKitと呼ばれる新しいJavaScript支援CSSツールキットに取り組んできました。全体的なアイデアは、レスポンシブWebデザインのCSSメディアクエリを置き換えるだけでなく、最新のWebサイトやWebアプリを構築するときにWebデザイナー/開発者が直面する既知の[および未知の]課題のいくつかに対処するデザイナーフレンドリーなツールを構築することでした。

概念には多くのことがありますが、ここに説明するCSSの簡単なコードスニペットがあります。

 ＃my-element [rk = "if @ viewport.width between 320 and 480"] {background-color：＃0000ff;}

rKitを使用すると、CSSルールは変更された属性値セレクターのように見えます。次に、値セクション内で式を定義できます。この式の構文は、単純で直感的になるように設計されています。

注： rkは定数属性識別子です。

上記のコードは、以下のCSSメディアクエリと機能的に同等です。

 @media only screen and（min-device-width：320px）and（max-device-width：480px）{
    ＃my-element {background-color：＃0000ff;}
}

ただし、rKitでできることは他にもたくさんあります。別の簡単な例を次に示します。

 ＃my-element [rk = "if @ self.width between 320 and 480"] {background-color：＃00ff00;}

エンティティ参照を@viewportから@selfに変更するだけで、基本的に要素クエリと呼ばれるものを設定できます。つまり、 #my-elementの幅が320〜480ピクセルの場合、指定された宣言[ background-color: #00ff00 ]が適用されます。

純粋な宣言の代わりにクラスを使用することもできます。

 ＃my-element [rk = "if @ self.width between 320 and 480 then addClass（c_mobile_320）"] {}
.c_mobile_320 {背景色：＃00ff00;}

ただし、これは氷山の一角にすぎません。 rKitを使用すると、イベント管理、突然変異の観察、数量クエリ、ルーティング、データバインディング[最大7ウェイ]、その他の多くの優れた機能を、すべて純粋なCSSコードを使用して、記述せずに実行できます。 JavaScriptの1行。

rKitは、リリース時に無料でオープンソースになります。また、レンダリングのブロックがゼロになるようにインストールできる特別なパフォーマンスパックを備えているため、Webページはロケットのようにレールにロードされます。

これをまとめるにはかなり時間がかかりますが、まもなく[Godotの前に]ここに来る予定です。Webデザイナー[および開発者]がこれを使って何ができるのか、本当に興味があります。

結論

私がCSSメディアクエリをバッシングしているという理由だけで、この投稿から離れないことを願っています。私は違います。それは、トマトをバッシングしてフルーツサラダにするようなものです。前に言ったように、CSSメディアクエリはレスポンシブWebデザイン用に設計されたことはありません。それは便宜のために採用されました、そして私たちは皆、それを使ってすべての問題を解決しようとするという失敗をしました。

悲しいことに、私たちWebコミュニティは、最初の間違いを大幅に改善したり、より良い代替案を考え出したりして、最初の間違いを修正することはできませんでした。しかし、悲しいかな、ショーは続けられなければならず、ウェブサイトは構築されなければならず、そして進歩が優先されなければなりません。変化の時です。

rKitは1つのオプションと1つの答えにすぎません。それは最初ではありません、そしてそれは間違いなく最後ではありません。しかし、少なくともそれは正しい方向への正しい一歩です。過去のいくつかの問題を修正し、現在および将来の問題を修正するために繰り返す機会。それが現状とどのように一致するかを見るのは興味深いでしょう。

すべてが犠牲になり、間違いを犯すこと自体が目的ではありません。それは学習体験でなければなりません。運が良ければ、次回は適切な仕事に適切なツールを使用する方法を学びます。つまり、舗装された道路で自転車に乗れるからといって、ニュルブルクリンクに自転車を持っていく必要があるわけではありません。ポルシェを持ってきてください！