次の方法で共有

Script Junkie {}

  • [アーティクル]

CSS アーキテクチャ、パート 2: 最高のスケーラビリティを備えたモジュール方式の CSS アプローチ

Denise R. Jacobs | 2013 年 3 月 21 日

オンライン業界が成長するにつれてコードを扱うアプローチの対象は、より大きな Web サイトへと移ります。フロント エンド開発者は CSS を整理する (英語) ことから着手するのが一番ですが、最近人気が高まっているスケーラブルな CSS アーキテクチャで採用されている手法を当てはめても、サイトのスタイルシートをレベルアップできます。このアーキテクチャ全体を 1 つのアプローチとして採用するか、アーキテクチャに含まれる原則や手法を選別して採用することで、大きなサイトの CSS での一般的な悩み (保守と更新を難しくするコードの複雑さ、コードが大きくなる冗長性など) を解決できます。

CSS が大きくなる原因を診断する

次の兆候や問題が見受けられる場合は、スタイルシートをモジュール構造にしてスケーラビリティを向上します。問題点に適切に対処するには、特定のプロパティを探し、その数から問題点を把握します。Nicole Sullivan のプレゼンテーション「Top 5 Mistakes of Massive CSS」(CSS が大きくなるミス トップ 5、英語) では、いくつかの主要プロパティが過剰に使用される原因が次のように診断されています。

  • float が多くなるのは、グリッドが存在しないか、効果的に機能していない。
  • margin が多くなる場合は、reset.css(または normalize.css) が必要。
  • padding が多くなるのは、設計パラメーターが明確でないため、複数の開発者が何度も細部を微調整している。
  • font-size が多くなるのは、カスケードを利用しておらず、font-size と一緒に見出しもルール セット内に隠れている可能性がある。
  • !important が多くなるのは、このプロパティを使用して具体性をオーバーライドしており、カスケードを利用していない。

このようなことを知っていましたか。このような兆候を理解すれば CSS が大きくなる原因がわかり、適切な対処法を考えることができるようになります。

スケーラビリティが高いモジュール方式のアプローチ: 基本

スケーラビリティが高いさまざまなアプローチの主な考え方は、次の 2 つの核となる手法に集約されます。

1. リデュース、リユース、リサイクル

「リデュース」とは、想定する最も短い要素チェーンをセレクターに記述し、要素の修飾子を削除することです。これについては、大部分を前回(英語) 説明しました。これと同じくらい重要なことは、適切なセレクターを作成することです。つまり、ID よりもクラスを優先し、要素の使用を避け、ページで必要な要素をより直接対象にする連結子セレクターを使用します。

「リユース」とは、過度に具体的なクラスを作成するのではなく、ジェネリック クラスを作成し、このクラスを組み合わせて異なる表示結果を生み出すことです。

「リサイクル」とは、カスケードを適切に利用して冗長なスタイル宣言を削減し、サイト全体で使用するページ コンポーネントを最小限のコードにモジュール化して、サブクラス化によってモジュールを拡張することです。

2. 整理、構造化、および通知

情報を明確にし、正しく理解させるには、うまく整理して提示することが重要です。シリーズの初回(英語) で取り上げたスタイルシートに開発者情報を記述する方法や、(ドキュメントのスタイルをカテゴリに分けることによって) ドキュメント自体を構造化する方法もスケーラビリティを上げるアプローチの 1 つです。ただし、スタイルのカテゴリを複数のドキュメントに分け、再利用可能なクラスに特別な名前付け規則を当てはめて構造とその意味を示し、グリッドを使用してページ構造を確立することで、さらに構造化を進めることができます。最後に取り上げるコンポーネントは Web サイトのスタイル ガイドで、スタイル、構造、および名前付け規則をチームに正しく通知するために使用します。

スケーラビリティが高いモジュール方式のアプローチの概要

主な考え方についてはここまでです。ここからは、大きな CSS プロジェクトを扱う著名なアプローチの概要を紹介しながら、そのアプローチの考え方をサポートする具体的な手法を見ていきます。今回紹介するアプローチは、DRY (Don't Repeat Yourself) CSS、OOCSS (Object-Oriented CSS)、SMACSS (Scalable and Modular Architecture for CSS)、および CSS for Grownups の 4 つです。

DRY CSS

CSS は言語としての論理性に欠けるため、理解して利用するのがやや難しくなります。変数や関数のような再利用可能なコンポーネントがあるプログラミング言語と違って、CSS ではセレクターや、プロパティと値のペアを再利用することが多くなります。実際、冗長で膨大になっても、CSS は問題なく機能します。

DRY CSSの基になっているのは、ソフトウェア開発の「同じことを繰り返さない(Don't Repeat Yourself)」という原則です。CSS をコーディングする際の目標は、同じプロパティと値のペアを繰り返し指定しないようにすることです。かなり難しいことですが、不可能ではありません。

グループを使用する (強いて言うなら)

DRY CSS の核をなすのはグループ化です。グループ化の基本は、構造化、整理、リデュース、リサイクルです。DRY CSS を提唱した Jeremy Clarkeは、共有プロパティを含むセレクターのグループを作成することを提案しています。つまり、CSS を記述する際によく行ってしまう、個別のプロパティと値のペアのセレクターごとの繰り返しをやめるようにします。グループには多くのセレクターが含まれるようになりますが、それぞれのプロパティと値のペアを定義するのは １ 回だけになります。

実際には、グループは共有プロパティを定義します。DRY CSS では、.alert-box のように機能の意味からクラスや ID の名前を付ける習慣を止める必要があります。グループでは、.rounded-corners のように、外観や設計上の役割を基に説明的な名前を付け、特定のプロパティを共有するすべてのセレクターをそのスタイルにグループ化します。このようにすると、スタイルの混在や重複の可能性がなくなり、コード量を削減できます。

グループを作成するには、まず、設計上の役割に基づいてグループに名前を付けます。次に、そのグループ名を、リストの先頭では ID として、一番下ではクラスとして使用します。続いて、この説明的なクラス名の上にプロパティを共有する残りのセレクターを追加します。Jeremy は「DRY CSS: 効率的で統一されたスケーラブルなスタイルシートを作成するための同じことを繰り返さない手法」(英語) で例を紹介しています (図 1参照)。


図 1DRY CSS のグループ化の例

簡単にはグループに分類できそうもないセレクターについてはどうでしょう。CSS に DRY 手法を適用するもう 1 つの目標は、独自性のあるセレクターをできる限り少なくし、このようなセレクターを限定的に例外として扱うことです。つまり、コーディングするときに頭を働かせる必要があります。セレクターのスタイル宣言を作成するときは常に「これをグループに追加できないだろうか」と問いかけ、可能であればグループに追加する方法を考えます。

グループを作成したら、グループを整理する方法を考えます。Clarke は、色、テキスト、形状、構造、およびモジュールをカテゴリとして使用することを推奨していますが、開発者がプロジェクトに応じて最適なカテゴリを作成することも勧めています。

メリット

Clarke は、DRY CSS のプレゼンテーションで、このアプローチの多くのメリットを一覧しています。その中で最も魅力的なメリットを示しておきます。

  • CSS のファイル サイズが減少する (明らかに、これが主な目的で、DRY CSS を使用することで得られる大きな成果です)。
  • 要素を最適化し、セレクターを汎用化する (セレクターどうしの相互関係と継承方法がわかるので、最適化と汎用化が進みます)。
  • グループを編集するだけですべてのメンバーに変更が反映されるため、一貫性が保たれる (グループのメンバーが同時に変更されるのがわかるため、多くの個別セレクターに変更を反映する場合に大きなメリットが得られます)。
  • HTML に影響を与えない (コンテンツ管理システムやブログ ツールなど、簡単に管理できない生成済みの HTML を含むサイトに有効です)。
  • 設計の要素/スタイル、設計パターン、および一貫性をじっくり検討できるようになる (優れた設計手法の採用や更新の統一が進みます)。

Clarke は、DRY CSS をスケーラビリティが高い別のアーキテクチャ (OOCSS や SMACSS など) に統合できる点も強調しています。

成果

Clarke は、複数言語へのローカライズも必要なグローバル ボイスのサイトにこのアプローチを適用し、大きな成果を上げました。Clarke によると、DRY CSS を考案して適用することで、このサイトのスタイルシートを約 4500 行から約 2400 行に削減できたそうです。これは、多くのフロントエンド開発者が歓迎する成果です。

OOCSS

オブジェクト指向 CSS (英語) では、同様の構造のページ要素や、サイトで頻繁に使用されている要素を特定する、パターン認識から着手します。パターンを特定したら、この設計要素をモジュールに変換します。その後、このモジュールをスキン化して、複数のサイトが異なる方法で利用できるようにします。

OOCSS には 2 つの主要原則があります。1 つは、構造とプレゼンテーション (構造と "スキン") を分離することです。つまり、要素の構造と外観とを切り離し、外観を "スキン (皮膚)" のように扱います。この原則は、プレゼンテーションとコンテンツを分離するという Web 標準の基本原則の 1 つに似ているため、それほど難しくなく実装できます。

2 つ目は、コンテナーとコンテンツを分離することです。つまり、要素固有で、場所に依存しないスタイルを使用します。CSS セレクターの作成に多く使用されているのは、DOM 内で優先度の高い要素 (

など) に ID やクラスを結び付けてから、要素にバリエーションを持たせるために長いチェーンのセレクターを作成する方法です。この手法は、CSS が手に負えなくなり、スタイルシートの保守が困難になる原因になります。OOCSS では、コンテナーを拡張することでコンテナーを変更する手法をとります。そのため、そのコンテンツに基づいてコンテナーを効果的に変更できるようになります。つまり、新たな CSS クラスを追加して、外観だけを変えるようにします。

Sullivan は、OOCSS アプローチを以下の手順に分けています。

  1. サイト単位で再利用可能な要素を判断する。見出し、リスト (操作リスト、外部リンク リスト、製品リスト、機能リスト)、モジュールのヘッダーとフッター、グリッド、ボタン、角が丸いボックス、タブ、カルーセル、トグル ブロックなど。
  2. 次の項目の関係を明確にする。
    • コンテナーとコンテンツ
    • 構造とスキン
    • 輪郭と背景
    • オブジェクトとミックスイン
  3. コンテナーとコンテンツのオブジェクトを混在または一致させてパフォーマンスが高い設計を実現する。
  4. 外観の違いのために、モジュールをスキン化する。スキン/テーマはモジュールのプレゼンテーション (外観) です。目標は、内容を簡単に推測できるスキンを用意して、計算や測定が容易な値のみを変化させることです。

モジュール: サイトのビルディング ブロック

OOCSS を実践する大半の作業は、再利用可能なコンポーネントを構築することです。Sullivan は、このような再利用可能なコンポーネントを「モジュール」と呼んでいます。モジュールは、DOM ツリーにも、具体的な要素の種類にも依存させないようにします。さまざまなコンテナーに適用でき、簡単にスキン化できる柔軟性が必要です。

モジュールの特定、作成、および利用は OOCSS でもかなり DRY な側面です。共通の要素やプレゼンテーションを見つけ、再利用可能なコードのモジュールに抽象化すれば、フロントエンド開発者は作業を繰り返すことなく、リデュース、リユース、リサイクルを実践できます。

さまざまな形式のテキストと画像を処理できるモジュールの優れた例として、Sullivan の .media モジュールがあります。.media モジュールは、左側に置いた画像の大きさに合わせてテキストを右側に添えて表示するために考案されています。彼女は、media モジュールで利用できるさまざまな形式の例(英語、図 2 参照) を紹介しています。

図 2 .media モジュールのさまざまな形式

media モジュールの構造を形成する HTML を以下に示します。



  


...


初期モジュールの CSS がスタイルの基礎を作り、このスタイルを拡張することで差異を生み出します。つまり、要素の外観を変えます。


/* ====== media ====== */
 .media {margin:10px;}
 .media, .bd {overflow:hidden; _overflow:visible; zoom:1;}
 .media .img {float:left; margin-right: 10px;}
 .media .img img{display:block;}
 .media .imgExt{float:right; margin-left: 10px;}



media モジュールは多くの例の 1 つにすぎません。GitHub の OOCSS プロジェクト (英語) には、他にも多くのモジュール (ボタン、グリッド、カルーセル、コンテンツなど) があります。


メリット


OOCSS を採用するか、最低でもこのシステムの要素を利用するだけで、多くのコード行を削減できます。また、このアプローチはサンドボックス化が容易で、チームのすべての開発者が利用できます。


成果


Sullivan が OOCSS を適用した最も大規模で有名なサイトの 1 つが Facebookです。彼女のプレゼンテーション「CSS の肥大化」(英語) で示されている数値によると、彼女と Facebook チームはページあたりの CSS のバイト数を 19% 削減し、ページあたりの HTML のバイト数を 44% 削減しています。ヘッダーの数だけでも 958 個から 25 個に削減し、サイトの応答時間を半分に減らしています。


SMACSS


SMACSS (https://smacss.com/、英語) は、大きなサイト向けにスケーラビリティが高いモジュール方式の CSS を記述するもう 1 つのアプローチです。このアプローチを作成した Jonathan Snook によると「SMACSS は設計のパターンを特定して体系化する手法」です。核となる考え (「リデュース、リユース、リサイクル」および「整理と構造化」) を表すもう 1 つの方法としてパターンの "体系化" を採用しています。


Snook は、大きな CSS プロジェクトを整理し、構造化する手法をいくつか用意しています。SMACSS の中核をなすのは CSS ルールのカテゴリ化です。カテゴリは設計パターンを明確にするのに役立ちます。そのため、開発者は、設計パターン用の定義や設計パターン自体の定義を向上することができます。


Snook が推奨するカテゴリを以下に示します。


    

  • Base(ベース) — 既定のスタイル。通常、1 つの要素セレクターを対象にします。
    • 

  • Layout(レイアウト) — ページを複数のセクションに分割します。通常、モジュールを一緒に保持します。
    • 

  • Module(モジュール) — 設計の中で再利用可能なモジュール構造の部分 (吹き出し、サイドバー セクション、製品リストなど)。
    • 

  • State(状態) — 特定の状態や異なるページのビューにおけるモジュールまたはレイアウトの外観を表します。
    • 

  • Theme(テーマ) — モジュールまたはレイアウトの外観を表します。
    • 



小さなプロジェクトでは、これらを同じファイルに含めてもかまいません。大きなプロジェクトでは、複数のファイルに分けることが推奨されます。


ただし、カテゴリにはやっかいな部分もあり、スタイルの実際の動作について考え、サイト、設計、および機能のどの部分にスタイルを適用するか考える必要があります。開発者は、構築プロセスの中で「どのようにコーディングするか」、「なぜこのようにコーディングするのか」を自身に問いかけることになります。したがって、カテゴリが表すのはスタイルの使用方法についてのガイドラインで、さらに複数のカテゴリにまたがってスタイルが混在するのを防ぐごとができます。


名前について


SMACSS で次に重要なのは、スタイルのルールの名前です。明確なクラス名を付けることは、スタイルのルールが含まれるカテゴリや、ページの基盤となる方式でのスタイルの動作を把握する重要な方法の 1 つです。


Snook は、レイアウト、モジュール、および状態の各スタイルの違いを示すために、クラス名にプレフィックスを付けることを提案しています。レイアウトの場合、たとえば l- や layout- を付けて、.l-aside や .layout-aside のようなクラス名を作成します。状態変化を生み出すクラスを示すには、.is-active や .is-collapsed のように .is- の後ろに状態を付けます。


ナビゲーション バー、カルーセル、ダイアログ、ウィジェット、表、アイコンなどを含むモジュールの名前を作成するときは、モジュール自体の名前を使用します。たとえば、サンプル モジュールには、.example という名前を付けます (クラスであって ID ではないことに注意してください)。吹き出しのモジュールは .callout にします。モジュールに状態を追加する必要がある場合は、どのようにすればよいかおわかりでしょう。折りたたまれた状態の吹き出しモジュールは、.is- の後ろに状態を付けて、.callout.is-collapsed とします。


クラスを拡張 (サブラス化) する場合はどうすればよいでしょう。簡単です。連結子セレクターの一部としてモジュールのクラス名を使用する (具体性の問題を生み出す) のではなく、元のクラスを基に新しいクラス名を作成します。たとえば、.pod-callout を作成して .pod を拡張すると、要素に両方のスタイルを適用することになります。新しいスタイルでは両方のスタイルが同じ具体性を持ち、新しいスタイル ルールと最初のスタイル ルールがうまく調和します。


適切かつクリーンなコードに集中し、クラスの問題は気にしない


明白なことですが、(OOCSS と同様) SMACSS の目的の 1 つは、階層が深いセレクターではなく、要素の世代を最も少なくした、階層の浅いセレクターを作成する (できるだけセレクターの階層が浅くなるように努力する) ことです。このシリーズ初回(英語) に示した推奨事項に従えばうまく実行できます。しかし、セレクターの要素数を制限するのに役立つ簡単な注意事項があります。以下のルールに従います。


    

  • 完全に予測可能でない限り、共通要素にタグのセレクターを使用しない。要素が予想可能なまま変化しないと考えられるとしても、クラスの使用をお勧めします。これは、クラスを要素で修飾することも含みます。
    • 

  • クラス名を右端のセレクター (キー セレクター) として使用する。
    • 

  • 子孫セレクター (e f) ではなく、子セレクター (e > f) を使用する。
    • 



階層が浅いセレクターを作成するもう 1 つの目標は、セレクターの具体性の問題を取り除くことです。CSS で具体性の競合が発生しないようにするための主な方法の 1 つは、セレクターでの ID の使用を避けることですが、まったく ID を使用しないということではありません。SMACSS では、レイアウト セクションや JavaScript のフックで ID を使用しても問題ありません。


フロントエンド開発者の精神に深く根付いた「クラスを使用しすぎない」という昔からのベスト プラクティスをご存じの方もいるでしょう。ただし、SMACSS (およびスケーラビリティが高い CSS アプローチの多く) に関していえば、具体的すぎるスタイルを作成して適用することでクラスが多くなりすぎることを気にするよりも、HTML で対象となる要素にクラスを追加して、そのクラスを繰り返すほうが適切だと考えられています。適切な名前を付けた複数のクラスを使用することで意図が明確になり、対象の要素に意味を追加できることがわかります。


メリット


SMACSS のメリットは、最初の段階からコーディングについてよく考えることによって得られる明確性です。カテゴリは冗長性を減らすのに役立ち、名前付け規則はすばやく効率的に CSS のスタイル ルールを特定するのに大きく貢献します。


成果


Snook は、膨大な Web プロジェクト (最も注目に値するのは Yahoo メールの再設計) に取り組んだ自身の経験から SMACSS を考案しました。大規模なチームが構築した大きなサイトにこの原則を適用することで、大きな成果を上げました。


CSS for Grown Ups


CSS for Grown Ups (英語) を作成した Andy Hume は、冗談めかしてこのシステムを「気難しい年配者のための CSS」と呼んでいます (こちらからビデオを視聴できます)。Hume は、スケーラブビリティの高いアプローチの考案者の多くと同様、業界が従来のいわゆるベスト プラクティスに固執するようになっていることを懸念しています (皮肉なことに、このようなベスト プラクティスの大半は単独で作業する開発者が生み出したものです)。彼は、フロントエンド開発者が、多くのプロジェクトで恐れられ嫌われる CSS を作成する道のりを、無意識のうちに重い足取りで進んでいると考えます。このようなフロントエンドのコードは、Web 標準に従って、とんでもなく長いコードでコンテンツとセッションの分離を保っていますが、スタイルやプロジェクトの複雑性を管理することについては注意を払っていません。


コードを変更するために最適化が必要なことは明らかです。CSS for Grown Ups では、ページではなくモジュールのスタイルを設定し、再利用可能なスタイル モジュール ライブラリを作成することでさらに一歩前進するのが目標です。


たまねぎやケーキ (またはパフェ) のような層*


SMACSS でカテゴリを使用したのとほぼ同様に、CSS for Grown Ups ではスタイルを「階層化」して表現します。スタイルには以下の層が関係します。


    

  • ドキュメント — HTML コード、要素セレクターから構成
    • 

  • ベース スタイル — 要素セレクター、タイポグラフィカル、色に適用
    • 

  • モジュール スタイル — リスト、ナビゲーション、プロモーション ボックスなど
    • 

  • レイアウト スタイル — グリッドや列、ページ レイアウトの確立
    • 



セレクターを作成するときは、作成するセレクターがドキュメント、ベース、またはモジュールのどれに該当するかを確認し、すべてのセレクターをモジュール レベルにするように努めます。これはどのようにして判別すればようでしょう。セレクターの一部にタグがある場合は、ドキュメント スタイルになります。セレクター用のクラスを作成する場合は、セレクターをタグを取り除いてモジュール スタイルにします。


目標は、ドキュメント、ベース、またはレイアウトに関連するスタイルを避け、モジュール関連のスタイルを作成することを目指します。理由については、以下の例をご覧ください。


.promo-box h2 { ... }



このセレクターは、ドキュメント レベルのセレクター (h2) と組み合わされたモジュール レベルのセレクター (.promo-box) です。これは、最初の段階では問題になりませんが、HTML の構造が変更されると問題が発生します。


代わりに、後でセレクターを拡張できるように、ドキュメントとモジュールの密接な結び付きを緩めることを目指します。上記の例は以下のようにします。


.promo-box-h { ... }



この例では、スタイルはドキュメントの要素に結び付けられているのではないため、(HTML でまだ考案されていない要素さえも含む) あらゆるものに適用でき、はるかに柔軟性が高く移植も可能です。


セレクター名は自由に付けて、残りの情報を後ろに付ける


CSS for Grownups は、「整理、構造化、および通知」の原則を示す典型的な例になります。Hume によると、役立つ情報を含む明確なクラス名を使用してスタイルを設定することは、「API をドキュメントに埋め込むようなものです。API を使用すると、最もシンプルで効率的な方法でドキュメントのスタイルを設定できます」ということです。クラス名は説明的にし、取り組んでいるサイトのコンテキストの意味を含めます。クラス名は、共有している用語のどの部分を再利用できるか判断できるように、サイトに取り組むチームのメンバーが理解できるものにします。


他のアプローチと同様、CSS for Grownups でもモジュールの作成と使用を推奨しています。また、OOCSS や SMACSS のアプローチと同様、モジュール名は説明的でセマンティックにし、場所または外観に結び付けないようにします。


.promo-box { ... }



CSS for Grownups には、モジュールを拡張したりサブスタイル化する手法があります。以下のように、モジュール名だけを使用し、これに 2 つのダッシュ (--) を付け加え、役立つ情報を含む明確な名前を拡張子に追加します。


.promo-box--light { ... }



2 つのダッシュは、このスタイルが最初のスタイルを拡張したものであり、最初のスタイルに依存することを示します。したがって、このスタイルは、元の 1 つ以上のスタイル ルールを上書きするために、CSS のソース順の最初のスタイルの後に適用されます。


ヘルパーを使用して共有性を高める


Hume は、プレゼンテーションの問題に対処するために、間隔または余白を提供するスタンドアロンのクラスの "正確なレイアウト ヘルパー" を使用することを推奨しています。以下に例を示します。


.margin-top {margin-top: 1em;}



これは、スタイルをコンポーネントにラップしないで、必要とするページのすべての要素に追加できるようにするスタイルです。その後、ページでモジュールを垂直方向に間隔を空けて配置する必要があるときに、このようなクラスをケース バイ ケースで使用できます。ベース スタイルシートでこれらのヘルパー スタイルを使用すれば、プロジェクト全体で簡単に使用できるようになります。


最後に、名前付けや確立した構造を体系化し、この情報をチームに伝達するための方法として、オンラインのスタイル ガイドを作成することを強くお勧めします (将来作業に取り組んでサイトに手を加えたり、サイトを変更したりする開発者が参照できるようにします)。スタイル ガイドや対応するモジュール ライブラリのニーズをコードにすることで、チーム メンバーは同じような表示スタイルを最初から設計して実装する必要がなくなります。


メリット


Hume は、SXSW 2012 のプレゼンテーションで「Web ページのスタイルを十分に設定できるほど実際に賢い人はいない」と述べています。彼は、この理由から、CSS for Grownups などで提供している特定の制約やパラメーターが必要であると主張しています。制約は、複雑性を管理する方法という点で優れています。Hume は、大きなサイトで長期間開発者チームが CSS の複雑性を管理する方法として CSS for Grownups を考案しました。さらに CSS for Grownups では、組織の設計言語がコードに変わる場所である、Hume 言うところの「設計と開発が出会うタッチポイント」を作成し、両方のチームの明確なコラボレーションによって、さらに高品質の製品を生産できます。


成果


CSS for Grownups のルーツは、Hume が、Channel 4、アムネスティ インターナショナル、Mozilla などの大規模なクライアントを抱える Clearleft で働いていた間に取り組んだ膨大な作業にあります。現在は Guardian(英語) で働いており、考案したシステムを適用することで、この会社のフロントエンド開発者のためのフレームワークを作成することに成功しました。


前進するが、完璧は目指さない


Harry Roberts は、「良い習慣を破る」(英語) というプレゼンテーションで、「CSS は実に乱雑なものなので、これをクリーンアップしても乱雑であることは変わらない」と述べています。目標は CSS を改良することであり、完璧さを目指すことではありません。そのため、広い心でこのような各アプローチを見てください。重要な点は、CSS をいくつかの手法に完璧に当てはめることにこだわらないことです。いくつかの手法を適用するだけでも、拡張可能で、少ないコードというメリットを実現できます。


スケーラビリティが高いモジュール方式のアプローチは、それぞれに優れた機能や特徴があり、ゼロからコーディングを始めるときは特に有効です。しかし、複雑怪奇な既存の CSS を処理しなくてはならない場合はどうすればよいでしょう。次回は、整理を進め、複雑怪奇な CSS 立ち向かうプロセスを紹介します。お楽しみに。


参考資料


    

  • CSS の構造化 – 2012 年の現状 (英語)
    • 

  • CSS 戦略の比較 (英語)
    • 

  • CSS アーキテクチャ (英語)
    • 

  • CSS ID セレクター: 絶対とは絶対に言わない(英語)
    • 



この記事は、Internet Explorer チームによる HTML5 技術シリーズの一部です。3 か月間無料の BrowserStack クロスブラウザー テスト (https://modern.IE) を使って、この記事の概念をお試しください。


執筆者紹介


Denise R. Jacobs は、Web デザインのエキスパートであり、14 年以上の経験を持つ業界のベテランです。彼女は今最も好きなこと、つまり、講演者、著者、Web デザイン コンサルタント、創造的なエバンジェリストになることに取り組んでいます。Twitter (@denisejacobs、英語) では、"great resources" (優れたリソース) を紹介して高い評価を受けており、CSS コードのトラブルシューティングに関する主な書籍である『The CSS Detective Guide』(New Riders Press、2010 年) の著者であり、『Interact with Web Standards』(New Riders Press、2010 年) および『Smashing Book #3: Redesign the Web』(Smashing Media GmbH、2012 年) の共著者です。長年構想を練ってきた最新のプロジェクトでは、少数派の人々に表舞台で活躍する Web エキスパートになって Web でロックする (英語) ことを奨励しています。彼女の連絡先は、denise@denisejacobs.com(英語のみ) です。DeniseJacobs.com(英語) で詳細を確認できます。


コメント (0)


コメントを残すにはサインインしてください。