要素クエリ、およびそれらを今日どのように使用できるか

公開: 2022-03-10

簡単な要約↬しばらくの間、 CSSでできることの限界に直面してきました。レスポンシブレイアウトを作成する人は、CSSだけでは記述できないスタイルを記述できるように、CSSプリプロセッサ、プラグイン、その他のツールに手を伸ばすことを余儀なくされるCSSのフラストレーションと欠点を自由に認めます。それでも、現在のツールが達成するのに役立つものには限界があります。

物理的な構造について少し考えてみてください。弱い材料で大きな建物を建てる場合、それをまとめるために多くの外部サポートが必要であり、頑丈さを保つために物事を作り直す必要があります。 HTML、CSS、JavaScriptからWebサイトを構築する場合、この外部サポートは、フレームワーク、プラグイン、プリプロセッサー、トランスパイラー、編集ツール、パッケージマネージャー、ビルドプロセスのように見える場合があります。

ジャンプした後もっと！以下を読み続けてください↓

スタックの一番上にさらに別のプラグインを追加する代わりに、コア言語の1つであるCSSを拡張することで、Webサイトの構成要素を強化し、外部のサポートやツールをあまり必要としない、より優れた、より強力なWebサイトを開発できるかどうか疑問に思いました。構築する。

要素クエリの現在の状態

CSSプリプロセッサなどのツールを使用して、CSSを省略して記述し、後で完全な形式に拡張します（ブラウザで表示する前に）。プラグインは、影響する要素と一緒にページを操作できますが、スタイルを適用するには、CSSスタイルをHTMLに直接書き込むか、異なるCSSルールを適用するクラス名を切り替えます。どちらの場合も、ページが実際に読み込まれる前に必要なCSSを作成または生成する必要があります。

問題

この方法の問題は、最高のプラグインでさえ、使用する各レイアウトでカスタマイズと構成が必要になることが多いことです。また、JavaScriptがスタイルを記述している場合、コードをリファクタリングまたは再利用するときに、プラグインベースのロジックとCSSスタイルを一緒に維持するのは難しい場合があります。

プリプロセッサのもう1つの問題は、CSSが完全な形式に展開されると、速記で記述されたエラーがすぐにはるかに大きな混乱に膨れ上がることです。プラグインを使用する場合、多くの潜在的な障害点を追加します。複数のプラグインを使用して、CSSがもう少し強力な場合はすべて不要になる可能性のある、いくつかの異なることを実行している可能性があります。これにより、開発者が維持し、ブラウザがレンダリングし、ユーザーがダウンロードするための余分な負担が発生します。

Web開発の将来に希望はありますか？

2013年、Tyson Matanichは、「メディアクエリは答えではない：要素クエリポリフィル」というタイトルの記事を書きました。これは、要素クエリの概念を多くの読者に紹介しました。 CSSの欠点を回避するためにプラグインとポリフィルを構築する方法についての議論が始まりました。

それ以来、CSS機能が進歩するのを待つ間、開発者がいくつかの異なる方法で要素クエリを使用できるようにする多くのプラグインがリリースされました。

要素クエリとは何ですか？

要素クエリはメディアクエリに似ていますが、ルールがブラウザのビューポートのプロパティではなく、実際の要素のプロパティに適用される点が異なります。

EQCSSがどのように生まれたのか

2013年の終わりに、Ruby on RailsWebアプリのフロントエンドで作業していることに気づきました。このアプリは、ユーザーに詳細情報を表示する必要がありました。目標は、電話、タブレット、デスクトップブラウザーで同等に機能するレスポンシブインターフェイスを構築することでした。これにはいくつかの課題がありました。そのうちの1つは、表示される重要なコンテンツの多くがテーブルに最もよく表示されることでした。そうです、実際のtable要素（金融取引、スポーツ記録などを表示するため）。

EQCSSプロジェクトは、要素メディアクエリの研究の結果として生まれました。ついにリリースされ、今日からご利用いただけます。デモを確認してください。

さまざまなサイズのブラウザでtable要素を正しく表示するメディアクエリを使用して、レスポンシブスタイルを作成しました。しかし、これらのレスポンシブテーブルの1つがサイドバーを含むテンプレートに表示されるとすぐに、すべてのレスポンシブブレークポイントがレスポンシブブレークポイントに変わりました。それらは単に200ピクセル幅のサイドバーを考慮していなかったため、物事が重なり合って壊れているように見えました。

もう1つの障害：ユーザー名の長さは3文字から20文字までさまざまであり、含まれている文字数に基づいて各ユーザー名のフォントサイズを自動的に調整できることを望んでいました。各ユーザー名をサイドバーに配置する必要があり、20文字のユーザー名に収まるほど小さいが、視聴者が3文字のユーザー名を見るのに十分な大きさのフォントサイズを選択するのは難しいことでした。

このような問題を回避するために、各レイアウトにレスポンシブスタイルを適用するためのよりスマートな方法が必要だったという理由だけで、メディアクエリ全体をコピーして、コードベースの大部分を複製することがよくありました。私は別の一時的な解決策としてJavaScriptに依存し、ページを監視し、CSSが到達できない場所にスタイルを適用するほぼ同一の関数を多数作成しました。しばらくすると、この重複コードすべての追加の負担がコードベースを圧迫し始め、変更を行うのが困難になりました。

より良い解決策が必要だとわかったので、しばらくすると、メディアクエリは必要ありません。必要なのは要素クエリです。

研究開発

2014年まで、ページに表示された要素のプロパティについてCSSに通知するさまざまな方法の実験を開始し、より良いスタイルを適用できるようにしました。 CSSの美しさとJavaScriptの力を組み合わせたスタイルを書けるようなアプローチを見つけたいと思っていました。

私が諦めたいくつかの放棄されたアプローチには、レスポンシブサポートを追加するためにHTMLタグに属性を追加することや、JavaScriptベースのifステートメント内にCSSコードのブロック全体を埋め込んで、JavaScriptからパッチを適用したある種のフランケンシュタインモンスターを生成する方法を見つけることが含まれますおよびCSS。

しかし、物事を簡単にする代わりに、私の失敗したアプローチにはすべて共通点が1つありました。それは、作業が増えたことです。適切なソリューションを使用すると、実行する必要のある作業が簡素化および削減されることがわかっていたので、検索を続けました。これらの実験を通して、私は要素クエリがうまく機能するために必要となる構文のタイプの洗練されたアイデアに行き着きました。

前述のように、HTML、CSS、およびJavaScriptから構築されたWebサイトの場合、外部サポートは、フレームワーク、プラグイン、プリプロセッサー、トランスパイラー、編集ツール、パッケージマネージャー、およびビルドプロセスの形式で提供されます。スタックの一番上にさらに別のプラグインを追加する代わりに、コア言語の1つであるCSSを拡張することで、Webサイトの構成要素を強化し、外部サポートをあまり必要としない、より優れた、より強力なWebサイトを構築できるかどうか疑問に思いました。構築するツール。

構文の誕生

2014年の終わりまでに、必要な構文のより良いビジョンを備えた私は、驚異的なJavaScriptコードゴルファーであるMaxime Euziereに連絡し、実行時にブラウザーでJavaScriptを使用してCSSを拡張する可能性について意見を求めました。彼はそれが可能であると私に知らせただけでなく、私がそれをするのを手伝ってくれると申し出ました！構文には、「要素クエリCSS」の略でEQCSSという名前を付けました。この名前は、CSSが実行できることをすべて超えているため、「過剰」という言葉にもちなんでいます。

必要なもの

構文に対する私の要件は、 CSSにできるだけ近いことでした。構文ハイライターがだまされて、標準のCSSであると思われるほどです。そこで、意味のある要素クエリのCSS構文をマップしました。人々が驚かされるような構文はまだ存在していません。

JavaScriptを使用してCSSのブラウザーサポートを拡張する場合、プラグインは、プラグインを構築するためにjQueryなどのライブラリを使用することを除外して、ジョブを実行するために可能な限り軽量で単純である必要があることを知っていました。今日サポートしなければならないブラウザに将来必要な機能を追加する純粋なJavaScriptライブラリが必要でした。

現時点では、CSSコミュニティでの議論はカスタム@ルールに焦点を合わせており、要素クエリについての話はまだ予備的なものです。このような機能の公式CSS仕様からはまだ何年もかかる可能性があります。仕様が作成された後でも、これらの機能をWebサイトで使用するには、十分なブラウザーサポートを待つ必要があります。

これらの機能がCSSに追加されるのを待つことは、今日Webサイトを構築および修正するためにこの機能が必要な場合には意味がありません。

結果

この調査の結果、高度なレスポンシブ条件の新しいセット、スコープ付きスタイル、ターゲティング要素の新しいセレクター、およびEQCSS.jsという名前の純粋なJavaScriptライブラリを含む構文が作成されました。さらに、Internet Explorer（IE）8のサポートは、オプションの外部ポリフィルで提供されています。プラグインとポリフィルはどちらもMITライセンスの下でリリースされており、誰でも無料で使用できます。

要素クエリのユースケース

プラグイン開発者

UIコンポーネントとウィジェットを作成するとき、開発者はメディアクエリによって制限されることがよくあります。多くの場合、プラグインを使用するユーザーが構成できるさまざまなレイアウトを構築するか、インターフェイスを単純化して、最も適切なソリューションを構築できるようにするかを選択する必要があります。

しかし、プラグインと要素クエリを使用したインターフェイスを設計する場合、ユーザーがどのコンテンツを入れたり、プラグインが表示されたりしても、予想されるすべての状況をカバーするレスポンシブスタイルを簡単に記述でき、真に防弾になります。 150〜2000ピクセル幅のレイアウトでウィジェットのスタイルを設定できるとします。そうすれば、そのウィジェットがWebサイトのどこに表示されていても、常に見栄えがします。

テンプレートビルダー

Webサイトのプロトタイプを作成するときは、ページ上のデザイン要素を再編成し、デザインをモジュラーコンポーネントのコレクションと考えるのが一般的です。 CSSメディアクエリを作成したことがある場合、これは時期尚早の最適化の場合である可能性があります。要素クエリを使用して設計することで、レスポンシブ条件をレイアウトに依存せずに維持し、スタイルをそれほど作り直すことなく、物事をより柔軟に移動できるようになります。

要素クエリを使用して設計またはモックアップした場合に特に役立つことがわかったのは、次のとおりです。

ナビゲーションバー、
モーダル、
サインアップおよびログインフォーム、
フッター、
価格表、
ランディングページ、
テーブル、
タブボックス、
アコーディオン、
サイドバーウィジェット、
メディアプレーヤー、
推薦状のセクション。

どのデザイン要素も「スコープ」してどこにでも移植できます—ページからページへ、またはウェブサイトからウェブサイトへ。

デバイスサポート

モバイルデバイスでWebをサポートするときに直面する問題の1つは、ハードウェアの豊富さです。デバイスの市場はかつてないほど細分化されており、新しいデバイスが毎日登場しています。サポートしているブラウザとデバイスのリストを維持できなくなったため、まだリリースされていないデバイスでも、デザインがどこでも機能することを知っておくことが重要です。

要素クエリを使用することで、より良い方法でWebサイトを設計し、これらのブラウザー間の違いのいくつかを排除できます。

要素クエリの必要性について最近書かれた多くの記事は、多くのユースケースを詳細に示しています。それでは、それらの使い方を始めましょう！

要素クエリの書き方

EQCSSの使用を開始するのは簡単です。 EQCSS構文の使用を開始するために必要なのは、HTMLのどこかにJavaScriptを含めることだけです。

EQCSS.jsのダウンロード

GitHubからEQCSSプロジェクトのクローンを作成する場合は、次のように入力できます。

 git clone https://github.com/eqcss/eqcss.git

npmを使用する場合は、次のコマンドを使用してプロジェクトにEQCSSを追加できます。

 npm install eqcss

HTMLにEQCSS.jsを追加する

EQCSSをダウンロードしたら、 scriptタグを使用してHTMLに追加できます。

 <script src="EQCSS.js"></script>

このファイル（ EQCSS.js ）には、IE9以降を含む現在のすべてのブラウザーのサポートが含まれています。 IE 8をサポートするには、他の多くのポリフィルを使用する必要がありました。 IE 8はポリフィルなしのCSSメディアクエリもサポートしていないことに注意してください。そのため、要素クエリをそこでも機能させることができたのは非常に驚くべきことです。 EQCSSを使用するWebサイトのIE8サポートを含めるには、メインプラグインへのリンクの前に次のリンクを追加します。

 <!‐‐[if lt IE 9]><script src="EQCSS‐polyfills.js"></script><![endif]‐‐>

EQCSSの実行

デフォルトでは、EQCSSプラグインは、ページが読み込まれると、メディアクエリと同様に、ブラウザのサイズが変更されたことを検出するたびに、検出したスタイルを計算します。また、JavaScriptを使用してEQCSS.apply()を手動で呼び出して、いつでもスタイルを再計算できます。これは、ページのコンテンツが更新された後に役立ちます。

要素クエリCSSの記述

EQCSS.jsプラグインは、いくつかの異なる方法でスタイルを読み取ることができます。 HTMLページの任意styleタグにEQCSSを含めることができます。また、外部のCSSスタイルシートにEQCSSを書き込むこともできます。

EQCSSを利用したコードをCSSから分離したい場合は、タイプがtext/eqcssに設定されたscriptタグを使用してEQCSS構文をロードできます。このようなタグにスタイルをインラインで追加するか、 <script type=“text/eqcss” src=styles.eqcss></script>を使用して外部の.eqcssスタイルシートにリンクすると、 styles.eqcssという名前のファイルが読み込まれます。。

要素クエリの構造

スタイルスコープ

要素クエリを記述するための@mediaの構文は、CSSメディアクエリのフォーマットと非常に似ていますが、@ mediaの代わりに、 @elementでクエリを開始します。提供する必要のある他の情報は、これらのスタイルを適用する必要がある少なくとも1つのセレクターだけです。 <div class=“widget”>という名前の要素の新しいスコープを作成する方法は次のとおりです。

 @element '.widget' { }

引用符の間の要素（この場合は.widget ）は、任意の有効なCSSセレクターにすることができます。このクエリを使用して、 .widget要素に新しいスコープを作成しました。スコープの応答条件はまだ含まれていないため、このようなクエリのスタイルは常にスコープ要素に適用されます。

（ページ全体ではなく）1つ以上の要素にスタイルのスコープを設定する機能がなければ、レスポンシブクエリをそれらの要素だけに適用することはできません。その要素レベルのスコープを作成すると、EQCSS構文のより高度な機能（たとえば、 $parentメタセレクターなど）の使用が簡単になります。これは、JavaScriptに、スコープのparentNodeなどを計算するための参照ポイントがあるためです。エレメント。これは巨大です！

確かに、CSSには、指定された要素の直接の子である要素を選択できる>を備えた直接子孫セレクターがすでに含まれています。しかし、CSSは現在、家系図を逆方向に移動して、親要素と呼ばれる別の要素を含む要素を選択する方法を提供していません。「CSSセレクターレベル4」仕様には、jQueryの:has()セレクターと同様に機能する:has()セレクターが含まれるようになりましたが、現在、ブラウザーのサポートはありません。スコープ付きCSSを使用すると、別の種類の親セレクターが可能になります。

.widget要素のコンテキストでスコープを開いたので、その観点からスタイルを記述して、それ自体の親要素をターゲットにすることができます。

 @element '.widget' { $parent { /* These styles apply to the parent of .widget */ } }

任意の要素クエリで使用できる特別なセレクターの別の例は、前の兄弟要素と次の兄弟要素を表す$prevおよび$nextセレクターです。 CSSは.widget + *のようなセレクターを使用してウィジェットの次の兄弟に到達できますが、CSSには、後方に到達して別の要素の直前にある要素を選択する方法はありません。

 <section> <div>This will be the previous item</div> <div class="widget">This is the scoped element</div> <div>This will be the next item</div> </section> <style> @element '.widget' { $prev { /* These styles apply to the element before .widget */ } $next { /* These styles apply to the element after .widget */ } } </style>

要素クエリ

開発者は、ブラウザのビューポートの高さまたは幅に基づいてスタイルを適用することにより、レスポンシブデザインにCSSメディアクエリを最も頻繁に使用します。 EQCSS構文は、多くの新しいタイプの応答条件をサポートします。ブラウザの幅と高さだけで作業する代わりに、要素に含まれる子要素の数や、要素に現在含まれている文字やテキストの行数など、要素自体のプロパティに基づいて要素に適用されるスタイルを記述できます。。

これらのレスポンシブ条件をスコープスタイルに追加することは、メディアクエリをフォーマットする方法と似ています。チェックする条件ごとand (condition: value)ます。この例では、 .widget要素がページ上に少なくとも500ピクセル幅で表示されているかどうかを確認します。

 @element '.widget' and (min‐width: 500px) { /* CSS rules here */ }

要素クエリの構文は次のように分類されます。

要素クエリ@要素@element selector_list [ condition_list ] { css_code }
セレクターリスト" css selector [ "," css selector ]* "
条件リストand ( query_condition : value ) [ "and (" query condition ":" value ")" ]*
値number [ css unit ]
クエリ条件min-height | max-height | min-width | max-width | min-characters | max-characters | min-lines | max-lines | min-children | max-children | min-scroll-y | max-scroll-y | min-scroll-x | max-scroll-x min-height | max-height | min-width | max-width | min-characters | max-characters | min-lines | max-lines | min-children | max-children | min-scroll-y | max-scroll-y | min-scroll-x | max-scroll-x
css単位% | px | pt | em | cm | mm | rem | ex | ch | pc | vw | vh | vmin | vmax % | px | pt | em | cm | mm | rem | ex | ch | pc | vw | vh | vmin | vmax

別の例として、 .widget要素の幅が500ピクセルに達したときにbody要素を赤に変えるクエリを作成する方法を次に示します。

 @element '.widget' and (min‐width: 500px) { body { background: red; } }

.widget要素自体ではなく、 .widgetが特定の幅に達すると、 body要素が変更されることに注意してください。

要素のクエリ条件

以下は、EQCSSがサポートする応答条件の完全なリストです。

幅ベースの条件

ピクセルのmin-widthのデモ、パーセンテージのデモ
ピクセルのmax-widthデモ、パーセンテージのデモ

高さベースの条件

ピクセルのmin-heightのデモ、パーセンテージのデモ
ピクセルmax-heightのデモ、パーセンテージのデモ

カウントベースの条件

ブロック要素の最min-charactersデモ、フォーム入力のデモ
ブロック要素max-charactersデモ、フォーム入力のデモ
min-linesデモ
max-linesデモ
min-childrenデモ
max-childrenデモ

スクロールベースの条件

min-scroll-yデモ
max-scroll-yデモ
min-scroll-xデモ
max-scroll-xデモ

要素クエリでこれらの条件をいくつでも組み合わせて、真に多次元のレスポンシブスタイルを作成できます。これにより、要素のレンダリング方法をより柔軟に制御できます。たとえば、表示可能なスペースが600ピクセル未満の場合に、15文字を超えるヘッダーのフォントサイズを縮小するには、 max‐characters: 15とmax‐width: 600pxの条件を組み合わせることができます。

 h1 { font‐size: 24pt; } @element 'h1' and (min‐characters: 16) and (max‐width: 600px) { h1 { font‐size: 20pt; } }

メタセレクター

レスポンシブ条件でスコープスタイルの記述を開始すると発生する可能性のある問題の1つは、同じセレクターの複数のインスタンスがページ上にある場合、要素クエリでそのセレクターを使用すると、上のセレクターのすべてのインスタンスにスタイルが適用されることです。それらのいずれかが条件に一致する場合のページ。前の.widgetの例を見て、ページに2つのウィジェットがあり（1つはサイドバーにあり、もう1つは全幅で表示されている）、次のように要素クエリを記述したとします。

 @element '.widget' and (min‐width: 500px) { .widget h2 { font‐size: 14pt; } }

これは、ページ上のいずれかの.widget要素の幅が少なくとも500ピクセルの場合、スタイルが両方の.widget要素に適用されることを意味します。これはおそらく、ほとんどの場合、私たちが望んでいることではありません。これがメタセレクターの出番です！

要素クエリを構成する2つの部分は、セレクターとレスポンシブ条件です。したがって、セレクターとレスポンシブ条件の両方に同時に一致するページ上の要素のみをターゲットにする場合は、メタセレクター$thisを使用できます。最後の例を書き直して、スタイルがmin‐width: 500px条件に一致する.widget要素にのみ適用されるようにすることができます。

 @element '.widget' and (min‐width: 500px) { $this h2 { font‐size: 14pt; } }

多くの新しいセレクターは、通常のCSSにはないEQCSS構文でサポートされています。完全なリストは次のとおりです。

$thisデモ
$parentデモ
$rootデモ
$prevデモ
$nextデモ

これらのセレクターは、要素クエリでのみ機能します。

JavaScriptとCSSの間のポータルを開く

eval(')デモ

EQCSSの最後の最後の機能は、すべての中で最もワイルドな機能です： eval(') 。この出入り口には、CSSからアクセスできるJavaScriptのすべての機能があります。 JavaScriptは要素にスタイルを適用できますが、現在、 :beforeや:after疑似要素など、いくつかのものに到達するのに苦労しています。しかし、CSSが他の方向からJavaScriptに到達できるとしたらどうでしょうか。 JavaScriptでCSSプロパティを設定する代わりに、CSSがJavaScriptを認識できるとしたらどうでしょうか。

ここでeval(')が登場します。CSSでJavaScript変数の値を使用するかどうかに関係なく、任意のJavaScriptにアクセスして評価し、JavaScriptのワンライナーを実行できます（ eval('new Date().getFullYear()') ）、JavaScriptが測定できるブラウザやその他の要素（ eval('innerHeight')など）に関する値を確認したり、JavaScript関数を実行してCSSスタイルで返される値を使用したりします。 2016を<footer>要素で出力する例を次に示します。

 @element 'footer' { $this:after { content: " eval('new Date().getFullYear()')"; } }

eval（ '）内で$ itを使用する

JavaScriptを評価している間、 eval(')は、アクティブにスコープされた要素のコンテキストからも機能します。これは、 $thisのスタイルが適用されるのと同じ要素です。 eval(')で記述されたJavaScriptの$itは、コードの構造化に役立つ場合はスコープ要素のプレースホルダーとして使用できますが、省略した場合も同じように機能します。たとえば、「hello」という単語が含まれるdivがあるとします。次のコードは「hellohello」を出力します。

 <div>hello</div> <style> @element 'div' { div:before { content: "eval('$it.textContent') "; } } </style>

ここで、 $itは、現在スコープが設定されているセレクターであるため、 divを参照します。 $itを省略して、同じものを表示する次のコードを記述することもできます。

 @element 'div' { div:before { content: "eval('textContent') "; } }

eval(')は、CSSがページの読み込み後にページで発生する測定値やイベントを認識しない場合に役立ちます。たとえば、YouTube動画の埋め込みに使用されるiframe要素には、指定された幅と高さがあります。 CSSで幅をautoに設定することはできますが、ビデオが利用可能なスペースを埋めるために拡大するときに、幅と高さの正しいアスペクト比を維持する簡単な方法はありません。

スケーリング中にレスポンシブアスペクト比を維持するための一般的な回避策は、アスペクト比を維持する必要のあるコンテンツをラッパーに配置し、維持する幅と高さの比率に基づく値でラッパーにパディングを追加することです。これは機能しますが、すべての動画のアスペクト比を事前に知っておく必要があります。また、応答性の高い埋め込みを行う動画ごとに、より多くのHTMLマークアップ（ラッパー要素）が必要です。レスポンシブビデオを掲載しているすべてのWebサイトでこれを乗算します。これは、CSSが少し賢い場合は、そこにある必要がない多くの問題です。

おそらく、レスポンシブアスペクト比へのより良いアプローチは、パディングなしで各ビデオをラッパーに配置し、次に、検出した各ビデオのアスペクト比を計算し、各ラッパーに正しい量のパディングを適用するJavaScriptライブラリを作成することです。

しかし、CSSがこれらの測定値に直接アクセスできるとしたらどうでしょうか。さまざまなアスペクト比のCSSを1つのルールに統合できるだけでなく、ページが読み込まれたときにCSSを評価できれば、将来提供する動画のサイズを変更する1つのルールを作成できます。そして、ラッパーなしですべてを行うことができました！

これが真実ではないように思われる場合は、これをチェックしてください。 EQCSSでラッパーフリーのレスポンシブなサイズ変更iframe要素を作成するのは簡単です。

 @element 'iframe' { $this { margin: 0 auto; width: 100%; height: eval('clientWidth/(width/height)'); } }

ここで、 widthとheightは、HTMLのiframeのwidth=“”およびheight=“”属性を参照します。 JavaScriptは(width/height)の計算を実行できます。これにより、アスペクト比が得られます。任意の幅で適用するには、iframe要素の現在の幅を比率で割るだけです。

これには、CSSの簡潔さと読みやすさ、そしてJavaScriptのすべての力があります。追加のラッパー、追加のクラス、追加のCSSは必要ありません。

ただし、 eval(')には注意してください。過去にCSS式が危険だと考えられていたのには理由があり、私たちがそのアイデアを試した理由もあります。ページ上でそれらを適用する要素の数やスタイルを再計算する頻度に注意しないと、JavaScriptは必要以上に何百倍も実行してしまう可能性があります。ありがたいことに、EQCSSを使用すると、 EQCSS.apply()またはEQCSS.throttle()を呼び出してスタイルを手動で再計算できるため、スタイルがいつ更新されるかをより細かく制御できます。

危険地帯！

条件やスタイルが競合するクエリを作成すると、他の問題が発生する可能性があります。 EQCSSは、CSSと同様に、特異性の階層を使用して上から下に読み取られます。 CSSは宣言型言語ですが、いくつかの高度な機能が含まれています。プログラミング言語としてのチューリング完全であることからほんの数歩です。これまでのところ、CSSのデバッグは非常に簡単なことでしたが、EQCSSは、CSSを単なる解釈型の宣言型言語から、CSSとブラウザー間の解釈の追加レイヤーを備えた動的なスタイルシート言語にシフトします。この新しい領域には、さまざまな潜在的な新しい落とし穴があります。

これは、EQCSSの相互ループの例です。これは、通常のCSSメディアクエリが設計上影響を受けないものです。

 @element '.widget' and (min‐width: 300px) { $this { width: 200px; } }

私はこれをjekyll: hide; CSS。しかし、1つのスタイルが継続的にそれ自体をトリガーすることに加えて、互いにトリガーする複数のクエリを作成する可能性もあります。これは、すべての中で最も厄介な「二重反転相互ループ」と呼ばれます。

 @element '.widget' and (min‐width: 400px) { $this { width: 200px; } } @element '.widget' and (max‐width: 300px) { $this { width: 500px; } }

理論的には、その不幸なウィジェットはループに陥り、時間の終わりまで200〜500ピクセルのサイズに変更され、幅を決めることができなくなります。このような場合、EQCSSは、評価された順序でルールを計算し、勝者を表彰して次に進みます。これらのルールが表示される順序を並べ替える場合、それらが同じ特異性である場合、後者のスタイルが常に優先されます。

ループ（または二重反転逆ループ）を作成する機能は設計上の欠陥であると言う人もいますが、ループが発生しないようにするには、EQCSSの能力を制限してほとんどの部分を削除する必要があります。構文が提供する値。一方、JavaScriptで無限ループを作成するのは非常に簡単ですが、それは言語の欠陥とは見なされていません。その力の証拠と見なされています。要素クエリでも同じです。

要素クエリのデバッグ

現在、要素クエリのデバッグは、ページ上で計算されたスタイルを表示するWebインスペクターなどのツールを使用する前に、メディアクエリをデバッグするのと少し似ているように感じることがあります。今のところ、要素クエリのデバッグと開発では、開発者がどのような応答動作が発生するかについてのメンタルモデルを維持する必要があります。将来的には、EQCSS対応の開発者ツールを構築できる可能性がありますが、現時点では、すべての主要なブラウザーの開発者ツールは、EQCSSがページ上の要素にすでに適用しているスタイルのみを認識しており、認識していません。 EQCSSが監視している応答条件。

要素クエリを使用して設計する方法

要素クエリを利用する最も簡単な方法は、メディアクエリを使用する既存のデザインを要素クエリに変換し、要素とそのレスポンシブスタイルを1つのレイアウトから「解放」して、そのコードを他のページやプロジェクトで簡単に再利用できるようにすることです。次のメディアクエリと要素クエリは同じことを意味する可能性があります。

 footer a { display: inline-block; } @media (max‐width: 500px) { footer a { display: block; } }

 footer a { display: inline-block; } @element 'footer' and (max‐width: 500px) { $this a { display: block; } }

違いは、元の例では、フッターリンクが表示のままであるということです。ブラウザーの幅が少なくとも500ピクセルになるまでdisplay: blockします。要素クエリを使用する2番目の例は、 footer要素が全幅である場合にのみ同じように見えます。

このスタイルを元のメディアクエリから解放した後、フッターを任意の幅のコンテナーに配置できるようになり、フッターにレスポンシブスタイルを適用する必要がある場合（つまり、500ピクセルより狭い場合）にフッターが確実に適用されるようになります。適用。

EQCSS.jsが宛先ドキュメントのHTMLに存在することを確認してください。
CSSで@mediaを@elementに置き換えます。
各@elementクエリのスコープにCSSセレクターを追加します。
オプション：要素クエリでスコープ要素のオカレンスを$thisに置き換えます。

変換するデザインコンポーネントが元々ブラウザのビューポートの全幅を使用して表示するように設計されていない限り、要素クエリに変換した後にブレークポイントを微調整する必要があります。

ロックインの回避

EQCSSスタイルのオーサリングの経験は、通常のCSSの作成の経験と似ています。お気に入りのCSSプロパティとテクニックはすべてそのままですが、新しい方法で連携するのに役立ついくつかの追加機能があります。 EQCSSは標準のCSSをブラウザに出力するため、ブラウザにサポートが組み込まれているCSS機能は、EQCSSで使用すると機能します。要素クエリやスコープスタイルなどの機能がCSSで指定され、ブラウザでサポートされている場合は、ブラウザがサポートしていない他の機能をEQCSSに依存しながら、EQCSSコードでそれらをすぐに使用できるようになります。まだネイティブにサポートします。

EQCSS構文は、CSSでも独自のスクリプトでも、 text/eqcssタイプで直接使用できるため、CSSがネイティブ要素クエリの構文を開発した場合でも、EQCSSをスクリプトとしてロードして競合を回避できます。。

将来的には、ブラウザー開発者が現在実験しているソリューションの1つはHoudiniです。これにより、プラグイン開発者は、ブラウザー自体にサポートを追加するなど、新しい方法でCSSを拡張できます。いつの日か、EQCSS構文を解釈し、現在のJavaScriptライブラリで許可されているよりも直接的でパフォーマンスの高い方法でこれらの機能をブラウザに提供する、より効率的なプラグインを作成できるようになるかもしれません。

それで、私たちはまだメディアクエリを使うべきですか？

はい、要素クエリはスタイルで要素をターゲットにする多くの新しくエキサイティングな方法を提供しますが、メディアクエリ（制限はありますが）は、JavaScriptに依存して計算するスタイルよりも常にブラウザで高速に実行されます。ただし、CSSメディアクエリは、画面のHTMLをスタイリングするだけではありません。 CSSメディアクエリは、印刷ベースのクエリや、Webサイトが情報を表示するその他の方法もサポートしています。 EQCSSは、印刷スタイルなどのメディアクエリと組み合わせて使用できるため、要素クエリも使用できるようになったという理由だけで、メディアクエリを廃止する必要はありません。

^20⁄20_ビジョンでの設計

CSSの将来のために私たちができる最善のことは、今日、これらのアイデアを可能な限り実験することです。これらの機能についてブレーンストーミングや理論化を行うことは、実際にそれらを実装して使用し、それらを有用で強力にする手法を発見することほど有用ではありません。

EQCSS.jsは、要素クエリのソリューションを提供するだけでなく、CSSを拡張する他の実験のプラットフォームとしても機能することを願っています。コードで使用する新しいレスポンシブ条件、新しいCSSプロパティ、または新しいセレクターのアイデアがある場合は、EQCSS.jsをフォークし、アイデアを含めるように変更することで、ほとんど労力をかけずにそこに到達できます。

モジュール設計

In designing layouts using element queries, the biggest shift is learning how to stop viewing the DOM from the top down and from the perspective of only the root HTML element, and to start thinking about individual elements on the page from their own perspectives within the document.

The old paradigms of “desktop-first” and “mobile-first” responsive design aren't relevant any longer — the new way of building layouts approaches design “element-first.” Using element queries enables you to work on the individual parts that make up a layout, in isolation from one another, styling them to a greater level of detail. If you are using a modular approach for your back-end code already but have so far been unable to package your CSS with your modules because of the difficulties of styling with media queries alone, then element queries will finally allow you to modularize your styles in the same way.

Thinking Element-First

Element-first design is in the same spirit as the atomic design principle but looks different in practice from how most people have implemented atomic design in the past.

For example, let's say you have some HTML like the following, and the desired responsive behavior can be explained as, “The search input and button are displayed side by side until the form gets too narrow. Then, both the input and the button should be stacked on top of each other and displayed full width.”

 <form> <input type=search> <input type=button value=Search> </form>

Desktop-First Approach

In a desktop-first mindset, you would write styles for the desktop layout first and then add responsive support for smaller screens.

 input { width: 50%; float: left; } @media (max‐width: 600px) { input { width: 100%; float: none; } }

モバイルファーストアプローチ

In a mobile-first mindset, you would design the mobile view first and add support for the side-by-side view only when the screen is wide enough.

 input { width: 100%; } @media (min‐width: 600px) { input { width: 50%; float: left; } }

Element-First Approach

In the first two examples, the media breakpoint was set to 600 pixels, and not because that's how wide the inputs will be when they switch. Chances are, the search input is probably inside at least one parent element that would have margins or padding. So, when the browser is 600 pixels wide, those inputs might be somewhere around 550 or 525 pixels wide on the page. In a desktop-first or mobile-first approach, you're always setting breakpoints based on the layout and how elements show up within it. With an element-first layout, you're saying, “I don't care how wide the browser is. I know that the sweet spot for where I want the inputs to stack is somewhere around 530 pixels wide.” Instead of using a media query to swap that CSS based on the browser's dimensions, with element-first design, we would scope our responsive style to the form element itself, writing a style like this:

 input { width: 100% } @element 'form' and (min‐width: 530px) { $this input { width: 50%; float: left; } }

The code is similar to that of the two previous methods, but now we are free to display this search input anywhere — in a sidebar or full width. We can use it in any layout on any website, and no matter how wide the browser is, when the form itself doesn't have enough room to display the inputs side by side, it will adapt to look its best.

Resources For Getting Started

EQCSS-Enabled Template

 <!DOCTYPE html> <html> <head> <meta charset="utf‐8"> <title></title> <style></style> </head> <body> <!‐‐[if lt IE 9]><script src="https://elementqueries.com/EQCSS‐polyfills.min.js"></script><![endif]‐‐> <script src="https://elementqueries.com/EQCSS.min.js"></script> </body> </html>

デモ

Responsive Aspect Ratio
Sticky Scroll Header
Blockquote Style
カレンダー
Content Demo
Counting Children Demo
Date Demo
Zastrow-style Element Query Demo Demo
Flyout Demo
Headline Demo
Media Player Demo
Message Style Demo
Modal Demo
Nav Demo
Parent Selector Demo
Pricing Chart Demo
Responsive Tables Demo
Scroll-triggered Blocker Demo
Signup Form Demo
Testimonials Block Demo
Tweet-Counter Demo
JS Variables Demo
Responsive Scaling Demo
Geometric Design Demo
Responsive Order Form
Element Query Grid
JS Functions in CSS
Responsive Content Waterfall

参考文献

You can find the EQCSS project on GitHub, demos, documentation and articles on the EQCSS website. An ever-growing number of Codepens use EQCSS, and you can create your own pen by forking the batteries-included template that comes hooked up with EQCSS. You can also play with the EQCSS tool that I built to preview if your EQCSS code is working as expected.

ハッピーハッキング！