Enduring CSS 07
ECSSの適用
-- WIP --
この章では、次のトピックについて説明します。
論理モジュールにECSSを適用する。
ビジュアルモジュールにECSSを適用する。
モジュール、コンポーネント、命名ファイルの整理。
CMSから生成されたコンテンツを操作する
ECSSとグローバルなスタイル。
ECSSは複雑なWebアプリケーションに適しています。最初に、大規模アプリケーションのロジックにECSSを適用する方法を検討しましょう。
論理モジュールへのECSSの適用
通常、Webアプリケーションでは、ある種のプログラミング言語（JavaScript / TypeScript / Ruby /など）が「もの」を生成します。
そのことのファイル名を、生成されるモジュール（またはモジュールのコンポーネント）の名前として使用することはしばしば実用的で望ましいことです。したがって、ファイルが 'Header.js'と呼ばれ、ヘッダーのコンテナを生成する場合、そのヘッダーの任意のコンポーネント部分に応じて名前を付けることができます。たとえば、ECSS用語では、企業登録番号がsw-Header_Regそのクラスとして取得される可能性があります。拡張子では、ヘッダ内の検索ボックスコンポーネントは、sw-HeaderSearch_Input（HeaderSearch.jsファイルによって作成された入力ボックスのような）クラスを持つことができます。
実例
より具体的な例を考えてみましょう。JavaScriptクライアント側アプリケーションを作成しており、「ShoppingCartLines.js」というJavaScriptコンポーネントがあるとします。その作業はショッピングカート内の線をレンダリングすることで、「ShoppingCart.js」というモジュール内に表示されます。'ShoppingCart'モジュールは、ショッピングカート自体と何かをレンダリングします。これまでのところ、まっすぐ進む。
ショッピングカートがいくつかのシナリオではモーダルビューで、通常のドキュメントフローではページの一部として機能することを示唆して、想像したシナリオを少し複雑にしましょう。
この例では、「ShoppingCart」というモジュールと、「ShoppingCartLines」というモジュール内に常駐するコンポーネントがあります。それぞれのノードには独自の子ノードがあります。モジュールとコンポーネントには、モーダルとページの2つのビューがあります。コンテキストの切り替えがアプリケーションロジックによって処理されることも想像してみましょう。
私たちの定数はモジュール自体であり、名前空間を使ってコンテキストを提供することができます。ECSSをアプリケーションロジックに適用する場合、アプリケーションモジュールまたはコンポーネントのフルネームを常にECSSスタイルセレクタのモジュールセクションとして使用することが理にかなっています。これは、DOM内のすべてのHTMLクラスを、その起源と目的について自己説明的にする利点があります。
モジュールまたはコンポーネントの最も外側のコンテナのクラスに名前を付けるときは、クラス/セレクタに子の拡張を追加しないでください。モジュールまたはコンポーネントの子部分のみがノード拡張を取得する必要があります。
これで、セレクタはスタイルシートで次のように指定できます：
code:ecss07_01.css
.mod-ShoppingCart {} /*Modal*/
.page-ShoppingCart {} /*Page*/
.mod-ShoppingCartLines {} /*Modal*/
.page-ShoppingCartLines {} /*Page*/
このようにして、モジュールとコンポーネントは、名前空間スイッチによって分離された2つのコンテキストを持ちます。私たちは、それぞれがスタイルの潜在的な漏れがないと考えているように、それぞれスタイルを自由にしています。これは、コンポーネントとモジュールが抽象化と再利用のためにHTMLクラスを共有するときに典型的に遭遇する正確な種類のシナリオです。
このシナリオの歪みを考えてみましょう。コンテキストをアプリケーションロジックで切り替えることはないとしましょう。代わりに、私たちはメディアクエリとスタイルの切り替えを持っています。小さなビューポートではモーダル実装、大きなビューポートでは通常のドキュメントフローではページスタイルが使用されます。
この例では、たとえば、sc-ShoppingCart（私はsc-コンテキストを 'ShoppingCart'に指定するために使用しています）、CSSでメディアクエリを使用して視覚的な変更を行うなど、単一の名前空間を持つことができます。
例えば：
code:ecss07_02.css
.sc-ShoppingCart {
/*Modal styles for smaller viewports*/
@media (min-width: $M) {
/* Page styles for larger viewports */
}
}
.sc-ShoppingCartLines {
/* Modal styles for smaller viewports */
@media (min-width: $M) {
/* Page styles for larger viewports */
}
}
モジュールまたはコンポーネントの子ノード
前述のように、モジュールまたはコンポーネントには、独自の子ノード要素があります。これらのセレクタには子拡張子を付けて名前を付ける必要があります。例えば：
code:ecss07_03.css
.sc-ShoppingCart {
/* The root of the component/module, no child extension needed */
}
.sc-ShoppingCart_Title {
/* The 'title' child node of the Shopping Cart */
}
.sc-ShoppingCart_Close {
/* A 'close' button child of the Shopping Cart for when the cart is modal */
}
各子は、その親の名前空間とコンポーネント（またはモジュール）名を取得します。
ECSS命名規則の詳細は、第5章を参照してください。
したがって、この時点で、ECSSをアプリケーションモジュールとロジックの周りに適用する際に、セレクタの名前をどのようにするかを理解しています。セレクタの名前を付け、ECSSを純粋にビジュアルなモジュールに適用する方法を見ていきます。しかし、最初に、タイプセレクタを使用することについての短く重要な接線。
タイプセレクタに関する注釈
CSSのオーサリング時に、タイプセレクタを使いたくなることがあります。典型的には、インラインレベル、など一見無害ノードがある場合に<i>、<b>、<em>または<span>。たとえば、太字にする必要のある単語が2つある文があるとします。それから、誘惑はこれをすることです。
code:ecss07_01.html
<p class="ch-ShoppingCart_TextIntro">Here is the contents of your cart. You currently have <b>5 items</b>.</p>
これらのセレクタを使用して、そのbタグの内容にスタイルを適用します。
code:ecss07_04.css
.ch-ShoppingCart_TextIntro {
/* Styles for the text */
b {
/* Styles for the bold section within */
}
}
ここにいくつかの問題があります：
特定のマークアップ（子ノードでbタグでなければなりません）への依存関係を作成しました。
ポイント1のために、必要以上に具体的なセレクタを作成しました。これにより、将来のオーバーライドを理由づけと実行が難しくなります。
これは過度に冗長に見えるかもしれませんが、これはシナリオを処理する方法です：
code:ecss07_02.html
<p class="ch-ShoppingCart_TextIntro">Here is the contents of your cart. You currently have <b class="ch-ShoppingCart_TextIntroStrong">5 items</b>.</p>
そしてCSS：
code:ecss07_05.css
.ch-ShoppingCart_TextIntro {
/* Styles for the text */
}
.ch-ShoppingCart_TextIntroStrong {
/* Styles for the bold section within */
}
各要素には独自のセレクタとルールがあります。どちらもどちらにも依存しません。どちらのルールも、特定のマークアップを適用する必要はありません。
要素に適用される各規則は、可能な限り独自の外観について意見を述べる必要があります。たとえば、2つのテキストノードを含む要素があると、フォントサイズと行の高さを折り返し要素に適用して2つのテキストノードを継承します。ただし、これにより、テキストノードが別の場所に移動され、一貫してレンダリングされることがなくなります。
その代わりに、色、フォントサイズ、行の高さを最初に非常に似ていても（最初は色が異なるだけかもしれません）、各ノードに適用してください。これは、直感に反するように見えますが、将来の可能性のある偏差（DOM内で動かされる、スタイルの分岐など）から保護します。
ビジュアルモジュールへのECSSの適用
「ビジュアル」コンポーネントとは、特定のアプリケーションロジックによって必ずしも生成されないマークアップの領域を指します。
ハードとファーストルールはありません。たとえば、構造、メニュー、フッター、ナビゲーション、クイックジャンプメニュー、ヒーローイメージなどのビジュアルエリアにデザインを分割することがあります
この場合、セレクタは次のようになります。
code:ecss07_06.css
.st-Header {
/* Structural container for header
}
.st-Footer {
/* Structural container for footer */
}
ただし、これを簡単に行うこともできます。
code:ecss07_07.css
.hd-Outer {
/* Structural container for header
}
.ft-Outer {
/* Structural container for footer */
}
それともモジュールの場合でもこれが好きです：
code:ecss07_08.css
.hd-Header {
/* Structural container for the Header module */
}
.ft-Footer {
/* Structural container for the footer module */
}
それらのどれもが間違っているか、正しい。子ノード/セレクタが同じ命名規則に従う限り、スタイルは特定の領域に分離されます。
現実には、小規模なサイトでは、好きなクラスネーミング手法をほとんど使用でき、衝突の危険性は最小限に抑えられます。しかし、プロジェクトが成長し始めるとすぐに名前空間の利点が得られ、厳密な命名規則があなたをうまく返済し始めます。
-- WIP --