この質問は、実際のCSSディレクティブ自体を.cssファイル内に編成することに関するものです。新しいページまたはページのセットを開発するとき、私は通常、.cssファイルに手動でディレクティブを追加し、可能な場合はリファクタリングを試みます。しばらくすると、数百（または数千）の行ができ、レイアウトを微調整するときに必要なものを見つけるのが難しくなる可能性があります。
ディレクティブを整理する方法について誰かアドバイスがありますか？
また、CSSを個別のファイルに分割することをお勧めする前に、1つのファイルに保持する必要のあるCSSの量に制限はありますか？言う、1000行？それとも、すべてを1か所にまとめておくのは常に良い考えですか？
関連する質問：CSSルールを整理するための最良の方法は何ですか？
回答:
開始するには、次の3つのスライドシェアプレゼンテーションをご覧ください。
まず、そして最も重要なこととして、CSSを文書化します。CSSを整理するために使用する方法が何であれ、一貫性を保ち、文書化します。各ファイルの上部に、そのファイルの内容を説明します。目次を提供し、一意のタグを簡単に検索できるように参照して、エディターでそれらのセクションに簡単にジャンプできるようにします。
CSSを複数のファイルに分割したい場合は、必ずそうしてください。Oliは、追加のHTTPリクエストは高額になる可能性があることをすでに述べましたが、両方の長所を活用できます。ある種のビルドスクリプトを使用して、十分に文書化されたモジュラーCSSを圧縮された単一のCSSファイルに公開します。YUIコンプレッサーは圧縮を支援することができます。
他の人がこれまでに言ったこととは対照的に、私は各プロパティを別々の行に記述し、インデントを使用して関連するルールをグループ化することを好みます。たとえば、Oliの例に従います。
#content {
/* css */
}
#content div {
/* css */
}
#content span {
/* css */
}
#content etc {
/* css */
}
#header {
/* css */
}
#header etc {
/* css */
}
これにより、ファイル構造を簡単に追跡できます。特に、グループ間に十分な空白と明確にマークされたコメントがあれば（すばやくざっと目を通すのは簡単ではありませんが）、編集も簡単です（CSSの1行の長い行をたどる必要がないため）。ルールごとに）。
カスケードと特異性を理解して使用します（したがって、セレクターをアルファベット順にソートするのは簡単です）。
CSSを複数のファイルに分割するかどうか、およびどのファイルに分割するかは、サイトとCSSのサイズと複雑さによって異なります。私はいつも少なくとも持っていreset.cssます。サイトのナビゲーションメニューが少し複雑になり、フォームのスタイルを設定するためのCSSが十分にある場合はlayout.css、一般的なページレイアウトにこれが伴う傾向がありnav.cssますforms.css。それ以外は、私もまだそれを理解しています。私が持っているかもしれないcolors.cssし、type.css/fonts.css色/グラフィックスとタイポグラフィをオフに分割するために、base.cssすべてのHTMLタグのための完全な基本スタイルを提供します...
reset.cssデッドリンクになっています
私はこのように私のCSSを組織化する傾向があります：
<link>HTMLファイルを<style>タグで乱雑にするよりも、使用する方が効率的であると主張する人もいます。
ただし、読みやすいと思います。
真剣に、あなたは10億と5つの提案を得るでしょう、しかしあなたは2、3の方法だけが好きになるでしょう。
しかし、私が言うべきいくつかのこと：
個人的には、CSSを次のようにコーディングしています。
* { /* css */ }
body { /* css */ }
#wrapper { /* css */ }
#innerwrapper { /* css */ }
#content { /* css */ }
#content div { /* css */ }
#content span { /* css */ }
#content etc { /* css */ }
#header { /* css */ }
#header etc { /* css */ }
#footer { /* css */ }
#footer etc { /* css */ }
.class1 { /* css */ }
.class2 { /* css */ }
.class3 { /* css */ }
.classn { /* css */ }
ルールを1行に保つことで、ファイルを非常に高速にざっと読み、ルールが何であるかを確認できます。それらが拡張されると、どのルールが適用されているかを見つけようとするのは大変な作業のように思えます。
CSSをフォーマットするための認識された方法論がいくつかあります。最終的には、最も快適に書くことができるかどうかはあなた次第ですが、これらは、より大規模で複雑なプロジェクトのCSSの管理に役立ちます。それは重要ではありませんが、私はBEMとSMACSSを組み合わせて使用する傾向があります。
BEMは、フロントエンドコードを読みやすく、理解しやすく、操作しやすく、スケーリングしやすく、堅牢で明示的で、より厳密にするための、非常に便利で強力でシンプルな命名規則です。
次のような、それ自体で意味のあるスタンドアロンエンティティ。
header, container, menu, checkbox, input
ブロックの一部であり、スタンドアロンの意味はありません。それらは意味的にそのブロックに結び付けられています：
menu item, list item, checkbox caption, header title
ブロックまたは要素のフラグ。それらを使用して、外観や動作を変更します。
disabled, highlighted, checked, fixed, size big, color yellow
OOCSSの目的は、コードの再利用を促進し、最終的には、追加と保守が容易な、より高速で効率的なスタイルシートを促進することです。
OOCSSは、次の2つの主要な原則に基づいています。
これは、繰り返しの視覚的特徴（背景や境界線のスタイルなど）を個別の「スキン」として定義することを意味します。これをさまざまなオブジェクトと組み合わせて、多くのコードなしで大量の視覚的多様性を実現できます。モジュールオブジェクトとそのスキンを参照してください。
基本的に、これは「場所に依存するスタイルをほとんど使用しない」ことを意味します。オブジェクトは、どこに置いても同じように見えるはずです。したがって、.myObject h2 {...}を使用して特定のスタイルを設定する代わりに、。のように、問題を説明するクラスを作成して適用します。これにより、次のことが保証されます。（1）クラス化されていないすべてのが同じように見える。（2）カテゴリクラス（ミックスインと呼ばれる）を持つすべての要素は同じように見えます。3）実際に.myObject h2を通常のように見せたい場合は、オーバーライドスタイルを作成する必要はありません。
SMACSSは、設計プロセスを調査する方法であり、これらの厳格なフレームワークを柔軟な思考プロセスに適合させる方法です。これは、CSSを使用する際のサイト開発への一貫したアプローチを文書化する試みです。
SMACSSの中核となるのは、分類です。CSSルールを分類することで、パターンがわかり始め、これらの各パターンに関するより良いプラクティスを定義できます。
カテゴリには5つのタイプがあります。
/* Base */
/* Layout */
/* Modules */
/* State */
/* Theme */
ベース リセットおよびデフォルトの要素スタイルが含まれます。また、特定の状況下でドキュメントの後半で上書きできるボタンやグリッドなどのコントロールの基本スタイルを持つこともできます。
レイアウトに は、すべてのナビゲーション、ブレッドクラム、サイトマップなどが含まれます。
モジュールには 、連絡先フォームスタイル、ホームページタイル、製品リストなどの領域固有のスタイルが含まれています。
国は 、このようななどなどisSelected、のisActive、hasError、wasSuccessfulような状態クラスが含まれています
テーマテーマに 関連するすべてのスタイルが含まれます。
ここで詳しく説明するには多すぎますが、これらの他のものも見てください。
私はこの順序で行きます：
単一のページまたは小さなグループ化ページに適用されるスタイルルールのいずれについても、本文をIDとクラスに設定して、特定のページを簡単にターゲットにできるようにします。idはファイルのベース名であり、classはファイルが存在するディレクトリ名です。
一般的なスタイルを除外します。たまたま同じスタイルではなく、同じことを目的としたスタイルです。一方のセレクターのスタイルを変更すると、もう一方のセレクターも変更する必要がある可能性があります。このスタイルの例を別の投稿に載せ ました。CSSファイル内で使用する変数をCSSファイルに作成します。
それとは別に、関連するルールをグループ化します。そして、ルールを複数のファイルに分割します...すべてのページが実際にすべてのルールを必要としない限り。
実際の順序はCSSの適用方法の重要な部分であるため、「アルファベット順」の提案を進めるのは少しばかげているようです。
一般に、影響を受けるページの領域ごとにアイテムをグループ化する必要があります。たとえば、すべてに影響するメインスタイル、ヘッダーとフッターのスタイル、ナビゲーションスタイル、メインコンテンツのスタイル、セカンダリコンテンツのスタイルの順になります。
保守がより困難になる可能性があるため、この時点では複数のファイルに分割することは避けます。（6つのCSSファイルを開いている場合、カスケードの順序を頭の中で維持することは非常に困難です）。ただし、スタイルがページのサブセットにのみ適用される場合、たとえば、ページに実際にフォームが含まれている場合にのみフォームスタイルがページにリンクされる場合は、スタイルを別のファイルに移動し始めます。
これが私がすることです。ディレクティブがなく、さまざまなファイルを呼び出すCSSインデックスページがあります。ここに短いサンプルがあります：
@import url("stylesheet-name/complete-reset.css");
@import url("stylesheet-name/colors.css");
@import url("stylesheet-name/structure.css");
@import url("stylesheet-name/html-tags.css");
@import url("stylesheet-name/menu-items.css");
@import url("stylesheet-name/portfolio.css");
@import url("stylesheet-name/error-messages.css");
完全なリセットから始まります。次のファイルは、簡単に参照できるようにカラーパレットを定義しています。それから私のスタイルの主<div/>なレイアウト、ヘッダー、フッター、彼らはフィットの列、などの数を決定するのは... HTMLタグdefinses <body/>、<h1/>、<p/>、トン等...次は、サイトの特定のセクションを来ります。
それは非常にスカラバレで非常に明確です。変更するコードを見つけたり、新しいセクションを追加したりする方がはるかに簡単です。
CSSファイルはクライアントにキャッシュされます。したがって、すべてのスタイルを1つのファイルに保持することをお勧めします。しかし、開発するときは、ドメインに従ってCSSを構造化すると便利だと思います。
例えば：reset.css、design.css、text.cssなど。最終製品をリリースするときに、すべてのスタイルを1つのファイルにマッシュアップします。
もう1つの便利なヒントは、読みやすさをスタイルではなくルールに集中させることです。
一方：
ul li
{
margin-left: 10px;
padding: 0;
}
たとえば、100行のコードがある場合、ルールを見つけるのは簡単ではありません。
代わりに、次の形式を使用します。
rule { property: value; property: value; }
rule { property: value; property: value; }
通常、私はこれを行います：
<link rel="stylesheet" href="css/style.css">style.cssで、次を@importします。
@import url(colors.css);
@import url(grid.css);
@import url(custom.css); + some more files (if needed)
ではcolors.cssI @import（CSSのカスタムプロパティを使用している場合）、以下：
@import url(root/variable.css);
すべてが整然としていて、コードのどの部分でも簡単に編集できます。なんとなくお役に立てれば幸いです。