web-dev-qa-db-ja.com

CSS爆発の管理

私が取り組んでいるWebサイトではCSSに大きく依存しています。現在、すべてのCSSスタイルはタグごとに適用されているため、今後の変更を支援するために、より多くの外部スタイルに移動しようとしています。

しかし今、問題は、「CSS爆発」に気づいたことです。 CSSファイル内でデータを最適に整理および抽象化する方法を決定することは私にとって難しくなっています。

ウェブサイト内で多数のdivタグを使用しており、非常にテーブルベースのウェブサイトから移動しています。そのため、次のような多くのCSSセレクターを取得しています。

div.title {
  background-color: blue;
  color: white;
  text-align: center;
}

div.footer {
  /* Styles Here */
}

div.body {
  /* Styles Here */
}

/* And many more */

まだそれほど悪くはありませんが、私は初心者なので、CSSファイルのさまざまな部分をどのように整理するのが最善かを提案できるかどうか疑問に思っていました。 Webサイトのすべての要素に個別のCSS属性を持たせたくありません。CSSファイルは常に直感的で読みやすいものにする必要があります。

私の最終的な目標は、CSSファイルを簡単に使用できるようにし、Web開発の速度を向上させる力を実証することです。このようにして、将来このサイトで作業する可能性のある他の個人も、私がやった方法を取り上げるのではなく、優れたコーディングプラクティスを使用するプラクティスに参加します。

677
JasCav

これは非常に良い質問です。私が見るところはどこでも、CSSファイルはしばらくすると制御不能になる傾向があります。特に、チームで作業しているときだけではありません。

以下は、私が自分で固守しようとしているルールです(私がいつも順守しているわけではありません)。

  • 早期にリファクタリングし、頻繁にリファクタリングします。頻繁にCSSファイルをクリーンアップし、同じクラスの複数の定義を融合します。古い定義をすぐに削除します

  • バグ修正中にCSSを追加する場合、変更内容についてコメントを残してください(「これは、ボックスがIE <7に配置されていることを確認するためです」)

  • 重複を避けます。 .classname.classname:hoverで同じものを定義しています。

  • コメント/** Head **/を使用して、明確な構造を構築します。

  • 一定のスタイルを維持するのに役立つプリティファイアーツールを使用します。 Polystyle を使用します。これには非常に満足しています(15ドルかかりますが、お金は十分に使います)。周りにも無料のものがあると確信しています(更新:たとえば Code BeautifierCSS Tidy 、私はまだ自分自身を使用したことはないが、非常に興味深いように見えるオープンソースのツール。

  • 賢明なクラスを構築します。これに関するいくつかのメモについては、以下を参照してください。

  • セマンティクスを使用し、DIVスープを避けます-たとえば、メニューには<ul>sを使用します。

  • すべてを可能な限り低いレベル(たとえば、bodyのデフォルトのフォントファミリ、色、サイズ)で定義し、可能な場合はinheritを使用します

  • 非常に複雑なCSSがある場合は、CSSプリコンパイラが役立つ可能性があります。すぐに同じ理由で xCSS を調べる予定です。周りにはいくつか他のものがあります。

  • チームで作業する場合は、CSSファイルの品質と標準の必要性も強調してください。プログラミング言語のコーディング標準には誰もが大きな関心を持っていますが、これがCSSにも必要であるという認識はほとんどありません。

  • チームで作業している場合、doバージョン管理の使用を検討してください。追跡がはるかに簡単になり、競合の編集がはるかに簡単になります。あなたがHTMLとCSSに「ちょうど」慣れていても、それは本当に価値があります。

  • !importantを使用しないでください。 IE = <7で対処できないためだけではありません。複雑な構造では、!importantを使用すると、ソースが見つからない動作を変更しようとすることがよくありますが、長期的なメンテナンスではpoisonです。

賢明なクラスの構築

これは私が賢明なクラスを構築する方法です。

最初にグローバル設定を適用します:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

次に、ページのレイアウトのメインセクションを特定します。上部領域、メニュー、コンテンツ、およびフッター。 適切なマークアップを記述した場合、これらの領域はHTML構造と同じになります。

次に、CSSクラスの構築を開始し、可能な限り賢明な祖先を指定し、関連するクラスをできるだけ密接にグループ化します。

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

CSS構造全体をtreeと考えてください。ルートから遠ざかるほど、具体的な定義が増えます。クラスの数をできる限り少なくして、できるだけ頻繁に繰り返さないようにします。

たとえば、3つのレベルのナビゲーションメニューがあるとします。これら3つのメニューは異なって見えますが、特定の特性も共有しています。たとえば、それらはすべて<ul>であり、すべて同じフォントサイズを持ち、アイテムはすべて隣り合っています(ulのデフォルトのレンダリングとは対照的です)。また、どのメニューにも箇条書き(list-style-type)はありません。

まず、common特性をmenuという名前のクラスに定義します。

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

次に、3つのメニューのそれぞれの特定の特性を定義します。レベル1の高さは40ピクセルです。レベル2および3 20ピクセル。

注:これには複数のクラスを使用することもできますが、Internet Explorer 6 は複数のクラスに問題があります なので、この例ではidsを使用します。

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

メニューのマークアップは次のようになります。

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

これらの3つのメニューのように、ページに意味的に類似した要素がある場合は、まず共通性を解決してクラスに入れてみてください。次に、特定のプロパティを作成してクラスに適用するか、Internet Explorer 6をサポートする必要がある場合はIDを適用します。

その他のHTMLヒント

これらのセマンティクスをHTML出力に追加すると、デザイナーは後で純粋なCSSを使用してWebサイトやアプリの外観をカスタマイズできます。これは大きな利点であり、時間の節約になります。

  • 可能であれば、すべてのページのボディに一意のクラスを指定します:<body class='contactpage'>これにより、ページ固有の微調整をスタイルシートに非常に簡単に追加できます。

    body.contactpage div.container ul.mainmenu li { color: green }
    
  • メニューを自動的に作成するときは、CSSコンテキストを可能な限り追加して、後で広範囲のスタイルを設定できるようにします。例えば:

    <ul class="mainmenu">
     <li class="item_first item_active item_1"> First item </li> 
     <li class="item_2"> Second item </li> 
     <li class="item_3"> Third item </li> 
     <li class="item_last item_4"> Fourth item </li> 
    </ul>
    

    このように、すべてのメニュー項目は、そのセマンティックコンテキストに従ってスタイル設定のためにアクセスできます。リストの最初の項目か最後の項目か。現在アクティブなアイテムかどうか。番号で。

上記の例で説明した複数のクラスの割り当て はIE6では正しく機能しません IE6が複数のクラスを処理できるようにするための )回避策 があります。私はまだ試していませんが、ディーン・エドワーズから来た非常に有望に見えます。それまでは、最も重要なクラス(アイテム番号、アクティブまたは最初/最後)を設定するか、IDを使用する必要があります。 (ブーイングIE6!)

557
Pekka 웃

以下に4つの例を示します。

4つすべてについて、私の答えには、Natalie DowneのPDF CSS Systems をダウンロードして読むことのアドバイスが含まれていました。 (PDFにはスライドにない大量のメモが含まれていますので、PDFをお読みください!)組織に対する彼女の提案に注意してください。

EDIT(2014/02/05)4年後、私は言います:

  • CSSプリプロセッサを使用し、ファイルをパーシャルとして管理します(個人的にはSassとCompassを好みますが、Lessも非常に優れており、他にもあります)
  • OOCSSSMACSS 、および BEM または getbem などの概念を読んでください。
  • BootstrapZurb Foundation などの一般的なCSSフレームワークがどのように構成されているかを見てください。そして、あまり人気のないフレームワークを軽視しないでください- イヌイット は興味深いものですが、他にもたくさんあります。
  • 継続的インテグレーションサーバー上のビルドステップや、GruntやGulpなどのタスクランナーを使用して、ファイルを結合/縮小します。
88
Andy Ford

CSSで見出しを書かない

セクションをファイルに分割するだけです。 CSSのコメントは、コメントである必要があります。

reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css

スクリプトを使用してそれらを1つに結合します。必要であれば。ニースのディレクトリ構造を持つこともでき、スクリプトに.cssファイルを再帰的にスキャンさせるだけです。

見出しを書く必要がある場合は、ファイルの先頭に目次があります

TOCの見出しは、後で書く見出しと完全に一致する必要があります。見出しを検索するのは大変です。問題に追加するには、最初のヘッダーの後に別のヘッダーがあることを誰が正確に知っていると思いますか?追伸TOCを作成するときに各行の先頭にdocのような*(星印)を追加しないでください。テキストを選択するのが面倒になります。

/* Table of Contents
   - - - - - - - - -
   Header stuff
   Body Stuff
   Some other junk
   - - - - - - - - -
 */
...
/* Header Stuff 
 */
...
/* Body Stuff 
 */

ブロック外ではなく、ルール内またはルール内にコメントを書く

まず、スクリプトを編集するときに、50/50の可能性があります。ルールブロックの外にあるものに注意を払います(特に、大きなテキストの場合は;))。第二に、外部で「コメント」が必要になる場合はほとんどありません。外にある場合は、99%がタイトルであるため、そのままにしておきます。

ページをコンポーネントに分割する

コンポーネントには、ほとんどの場合、position:relativeがあり、paddingmarginはありません。これにより、%ルールが大幅に簡素化され、要素のはるかに単純なabsolute:position 'ingが可能になります。これは、絶対配置コンテナがある場合、toprightbottomleftプロパティ。

通常、HTML5ドキュメントのほとんどのDIVはコンポーネントです。

コンポーネントは、ページ上の独立したユニットと見なすこともできます。素人の用語では、blackboxのようなものを扱うことが理にかなっている場合、コンポーネントのようなものを扱います。

QAページの例をもう一度使用します。

#navigation
#question
#answers
#answers .answer
etc.

ページをコンポーネントに分割することにより、作業を管理可能な単位に分割します。

同じ行に累積効果を持つルールを配置します。

たとえば、bordermargin、およびpadding(ただし、outlineは除く)はすべて、スタイリングする要素のサイズとサイズに追加されます。

position: absolute; top: 10px; right: 10px;

1行で読めない場合は、少なくとも近くに置いてください。

padding: 10px; margin: 20px;
border: 1px solid black;

可能な場合は速記を使用します。

/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;

セレクターを繰り返さない

同じセレクターのインスタンスが複数ある場合、必然的に同じルールの複数のインスタンスになる可能性が高くなります。例えば:

#some .selector {
    margin: 0;
    font-size: 11px;
}
...
#some .selector {
    border: 1px solid #000;
    margin: 0;
}

ID /クラスを使用できる場合は、TAGをセレクターとして使用しないでください

まず、DIVタグとSPANタグは例外です。これらを使用しないでください。 ;)クラス/ IDを添付するためにのみ使用します。

この...

div#answers div.answer table.statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
    outline: 3px solid #000;
}

このように書かれるべきです:

#answers .answer .statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

余分なぶら下がりDIVがあるため、セレクタには何も追加されません。また、不必要なタグルールを強制します。たとえば、.answerdivからarticleに変更すると、スタイルが崩れます。

または、より明確にしたい場合:

#answers .answer .statistics {
    color: pink;
    border: 1px solid #000;
}
#answers .answer table.statistics {
    border-collapse: collapsed;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

border-collapseプロパティである理由は、tableに適用された場合にのみ意味をなす特別なプロパティです。 .statisticstableでない場合、適用されません。

一般的なルールは悪です!

  • 可能であれば、汎用/魔法のルールを書かない
  • cSSリセット/リセット解除の場合を除き、すべての一般的な魔法は少なくとも1つのルートコンポーネントに適用する必要があります。

彼らはあなたの時間を節約しません、彼らはあなたの頭を爆発させます。メンテナンスを悪夢のようにします。ルールを書いているときに、どこで適用されるかを知っているかもしれませんが、ルールが後で混乱しないという保証はありません。

この一般的なルールを追加することは、スタイリングしているドキュメントについてある程度の知識がある場合でも、混乱を招き、読みにくくなります。これは、ジェネリックルールを書くべきではないということではなく、本当にジェネリックにするつもりがない限り、単に使用しないでください。また、セレクタにスコープ情報をできるだけ多く追加します。

このようなもの...

.badges {
    width: 100%;
    white-space: nowrap;
}

address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

...プログラミング言語でグローバル変数を使用するのと同じ問題があります。スコープを与える必要があります!

#question .userinfo .badges {
    width: 100%;
    white-space: nowrap;
}

#answers .answer .userinfo address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

基本的に次のようになります:

components                   target
---------------------------- --------
#answers .answer   .userinfo address
-------- --------- --------- --------
domain   component component selector 

私が知っているコンポーネントがページ上のシングルトンである場合は常にIDを使用するのが好きです。ニーズが異なる場合があります。

注:理想的には、十分に記述してください。ただし、セレクタでより多くのコンポーネントに言及することは、より少ないコンポーネントに言及することと比較して、より寛容な間違いです。

paginationコンポーネントがあると仮定しましょう。サイト全体の多くの場所で使用します。これは、一般的なルールを記述するときの良い例です。個々のページ番号のリンクをdisplay:blockして、それらに暗い灰色の背景を与えてみましょう。それらを表示するには、次のようなルールが必要です。

.pagination .pagelist a {
    color: #fff;
}

今、あなたは答えのリストにあなたのページネーションを使用すると言うことができます、あなたはこのような何かに遭遇するかもしれません

#answers .header a {
    color: #000;
}
...
.pagination .pagelist a {
    color: #fff;
}

これにより、白いリンクが黒くなりますが、これは望ましくありません。

それを修正する間違った方法は次のとおりです。

.pagination .pagelist a {
    color: #fff !important;
}

修正する正しい方法は次のとおりです。

#answers .header .pagination .pagelist a {
    color: #fff;
}

複雑な「論理」コメントは機能しません:)

「この値は、何とか何とか何とかで決まります」というようなものを書くと、間違いを犯すことは避けられず、すべてがカードの家のように落ちます。

コメントはシンプルにしてください。 「論理演算」が必要な場合は、 SASS または LESS などのCSSテンプレート言語を検討してください。

カラーパレットを書くにはどうすればいいですか?

これを最後に残します。カラーパレット全体のファイルを用意します。このファイルがなくても、スタイルにはルールで使用可能なカラーパレットがまだあるはずです。カラーパレットが上書きされます。非常に高レベルの親コンポーネント(#pageなど)を使用してセレクターをチェーンし、スタイルを自己充足ルールブロックとして記述します。それは単なる色またはそれ以上のものです。

例えば。

#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
    color: #222; background: #fff; 
    border-radius: 10px;
    padding: 1em;
}

アイデアはシンプルで、カラーパレットはベーススタイルとは独立したスタイルシートであり、これをcascadeに入れます。

名前が少なく、必要なメモリが少ないため、コードが読みやすくなります。

使用する名前は少ない方が良いです。理想的には、テキスト、本文、ヘッダーなどの非常に単純な(そして短い!)単語を使用してください。

また、単純な単語の組み合わせの方がわかりやすく、長い「適切な」単語のスープを持っていることがわかります:postbody、posthead、userinfoなど。

スタイルスープ(数週間後に自分のように;)を読むためにやってくる他の誰かが、すべてのセレクターが使用される場所ではなく、単語が使用される場所を理解する必要がある場合でも、このように語彙を小さくしてください。たとえば、要素が「選択されたアイテム」または「現在のアイテム」などと思われる場合は常に.thisを使用します。

自分の後片付け

CSSを書くことは食べることのようなもので、時には混乱を残します。あなたがその混乱をクリーンアップすることを確認してください、そうしないと、ガベージコードが山積みになります。使用しないクラス/ IDを削除します。使用しないCSSルールを削除します。すべてがきちんとニースであり、競合または重複したルールがないことを確認してください。

私が提案したように、いくつかのコンテナをスタイルのブラックボックス(コンポーネント)として扱い、セレクタでそれらのコンポーネントを使用し、すべてを1つの専用ファイルに保持する(またはTOCとヘッダーでファイルを適切に分割する)場合、作業が大幅に簡単になりました...

Firefox拡張Dust-Meセレクター(ヒント:sitemap.xmlを指すようにする)などのツールを使用して、CSS核兵器やカーニーに隠されたジャンクの一部を見つけることができます。

unsorted.cssファイルを保持する

QAサイトをスタイリングしていて、すでに「answers page」のスタイルシートがあり、これをanswers.cssと呼びます。多くの新しいcssを追加する必要がある場合は、unsorted.cssスタイルシートに追加してから、answers.cssスタイルシートにリファクタリングします。

これにはいくつかの理由があります。

  • 終了後にリファクタリングする方が高速です。次に、ルール(おそらく存在しない)を検索し、コードを注入します
  • 削除するものを作成します。コードを挿入すると、そのコードを削除するのが難しくなります
  • 元のファイルに追加すると、ルール/セレクターの複製が容易になります
73
srcspider

1をご覧ください。 SASS 2. Compass

55
Zimbabao

CSSbloatに対抗するために私が見た最良の方法は、オブジェクト指向のCSS原則を使用することです。

OOCSS フレームワークもありますが、それはかなり良いです。

いくつかのイデオロギーは、ここでトップアンサーで言われたことの多くに反しますが、オブジェクト指向の方法でCSSname__を設計する方法を理解すると、実際にコードを無駄のない状態に保つことができます。

ここで重要なことは、サイト内の「オブジェクト」またはビルディングブロックパターンを識別し、それらを使用して設計することです。

FacebookはOOCSSの作成者 Nicole Sullivan を雇い、フロントエンドコード(HTML/CSS)を大幅に節約しました。はい、あなたは実際にあなたのCSSだけでなく、あなたのHTMLでも節約を得ることができます、それはあなたがtablename__ベースのレイアウトを多くのdivname__に変換することについて言及するようにあなたにとって非常に可能です

別の優れたアプローチは、いくつかの点でOOCSSに似ています。CSSを最初からスケーラブルかつモジュール式に計画および作成することです。 ジョナサン・スヌーク についての素晴らしい執筆と本/電子ブックを作成しました SMACSS-CSSのスケーラブルでモジュール式のアーキテクチャ

リンクをいくつかご紹介します。
大規模なCSSの5つの間違い-(ビデオ)
大規模なCSSの5つの間違い-(スライド)
CSS膨張-(スライド)

31
Moin Zaman

また、カスケード、重量、およびそれらの仕組みを理解する必要があります。

クラス識別子(div.title)のみを使用していることに気付きました。 IDも使用できること、およびIDがクラスよりも重要であることをご存知ですか?

例えば、

#page1 div.title, #page1 ul, #page1 span {
  // rules
}

これらのすべての要素がフォントサイズ、たとえば、色、またはあなたのルールが何であれ共有します。 #page1の子孫であるすべてのDIVに特定のルールを取得させることもできます。

重みについては、CSS軸が最も一般的で最も軽いものから最も具体的で最も重いものに移動することに注意してください。つまり、CSSセレクターでは、要素指定子はクラス指定子によって無効にされ、ID指定子によって無効にされます。数がカウントされるため、2つの要素指定子(ul li)を持つセレクターは、単一の指定子(li)のみを持つセレクターよりも重みが大きくなります。

数字のように考えてください。 1列の9は、10列の1よりもまだ小さくなります。 ID指定子、クラス指定子、および2つの要素指定子を持つセレクタは、IDなしのセレクタ、500クラス指定子、および1,000要素指定子よりも重みが大きくなります。もちろんこれはばかげた例ですが、アイデアは得られます。重要なのは、この概念を適用すると、多くのCSSをクリーンアップできることです。

ところで、class = "title"を持つ他の要素と競合する場合を除き、要素指定子をクラス(div.title)に追加する必要はありません。後でその重みを使用する必要がある場合があるため、不要な重みを追加しないでください。

16
Robusto

CSS動的フレームワークが少ない

前述のSASSに似ています。

親クラスごとにCSSを維持するのに役立ちます。

例えば。

 #parent{     
  width: 100%;

    #child1
    {    
     background: #E1E8F2;    
     padding: 5px;    
    }

    #child2
   {
     background: #F1F8E2;
     padding: 15px
   }
 }

これが行うこと:#child1と#child2の両方にwidth:100%を適用します。

また、#child1固有のCSSは#parentに属します。

これはにレンダリングされます

#parent #child1
{
 width: 100%;
 background: #E1E8F2;
 padding: 5px;
}

#parent #child2
{
 width: 100%;
 background: #F1F8E2;
 padding: 15px;
}
13
Abhishek Mehta

難しいのは、サイトに必要なデザインを一連のルールに翻訳することです。サイトのデザインが明確でルールに基づいている場合、クラス名とCSS構造はそこから流れることができます。しかし、時間が経つにつれて、あまり意味のない小さなビットがサイトにランダムに追加される場合、CSSでそれについてできることはあまりありません。

私はCSSファイルをおよそ次のように整理する傾向があります。

  1. Eric Meyer’s に基づくCSSリセット。 (そうでなければ、ほとんどの要素について、デフォルトのブラウザスタイルをリセットするだけのルールが少なくとも1つまたは2つあることがわかります。たとえば、リストのほとんどはリストのデフォルトのHTMLスタイルとは異なります。)

  2. グリッドシステムCSS(サイトが要求する場合)。 (私は 960.gs をベースにしています)

  3. すべてのページに表示されるコンポーネント(ヘッダー、フッターなど)のスタイル

  4. サイト全体のさまざまな場所で使用されるコンポーネントのスタイル

  5. 個々のページにのみ関連するスタイル

ご覧のとおり、そのほとんどはサイトの設計に依存しています。デザインが明確で整理されていれば、CSSを使用できます。そうでない場合は、ねじ込まれています。

12
Paul D. Waite

私の答えは、質問で提起した高レベルの懸念に対処するための高レベルです。低レベルの組織的なトリックとTweakを使用して、よりきれいにすることができますが、それらのいずれも方法論的な欠陥を修正することはできません。 CSSの爆発に影響するものがいくつかあります。明らかにサイトの全体的な複雑さだけでなく、命名のセマンティクス、CSSのパフォーマンス、CSSファイルの編成、およびテスト可能性/受け入れ可能性なども含まれます。

名前付けのセマンティクスについては正しい道を進んでいるように見えますが、さらに一歩踏み込むことができます。構造を変更せずにサイトに繰り返し表示されるHTMLのセクション(「モジュール」と呼ばれる)は、セレクタールートと見なすことができ、そこからそのルートに関連する内部レイアウトをスコープできます。これはオブジェクト指向CSSの基本的な信条であり、 Yahooエンジニアによるこの講演で詳細を読む/見る ができます。

このクリーンなアプローチは、パフォーマンスの懸念とは反対に実行できることに注意することが重要です。これは、IDまたはタグ名に基づく短いセレクターを支持します。そのバランスを見つけるのはあなた次第ですが、あなたが大規模なサイトを持っているのでない限り、これはあなたのセレクターを短く保つことを思い出させるあなたの頭の後ろにあるガイドでなければなりません。 パフォーマンスの詳細はこちら

最後に、サイト全体に対して単一のCSSファイルを使用しますか、それとも複数のファイル(ページごとまたはセクションファイルで使用される単一のベースファイル)を使用しますか?単一のファイルの方がパフォーマンスは向上しますが、複数のチームメンバーの理解や保守が難しくなり、テストが難しくなる場合があります。テストのために、衝突と意図しないカスケードをテストするためにサポートされるすべてのCSSモジュールを含むsingle CSS-test pageをお勧めします。

または、CSSルールをページまたはセクションにスコープするために、複数ファイルアプローチを使用できます。これには、ブラウザが複数のファイルをダウンロードする必要がありますが、これはパフォーマンスの問題です。サーバー側のプログラミングを使用して、CSSファイルを動的に1つのファイルに指定および集約(および縮小)できます。ただし、これらのファイルは別個のものであり、それらのテストは別個のものであるため、ページ/セクション間で一貫性のないルックアンドフィールの可能性が生じます。したがって、テストは難しくなります。

顧客の特​​定のニーズを分析し、それに応じてこれらの懸念のバランスを取るのはあなた次第です。

7
G-Wiz

私の前に言ったように:OOCSSに入ります。 Sass/Less/Compassは使いたがりますが、Vanilla CSSが正しい方法で使用されるまで、Sass/Less/Compassは事態を悪化させるだけです。

まず、効率的なcssについて読んでください。 Google Page Speedを試して、Soudersが効率的なcssについて書いたことを読んでください。

次に、OOCSSと入力します。

  • カスケードの使用方法を学びます。 (結局、これをCascading Stylesheetsと呼びます)。
  • 粒度を正しくする方法を学ぶ(トップダウンではなくボトムアップ)
  • 構造とスキンを分離する方法を学びます(ユニークなものと、これらのオブジェクトのバリエーションは何ですか?)
  • コンテナとコンテンツを分離する方法を学びます。
  • グリッドを愛することを学ぶ。

CSSの記述に関するあらゆる点で革命を起こします。私は完全にリニューアルし、それを愛しています。

更新:SMACSSはOOCSSに似ていますが、一般的に言えばより簡単に適応できます。

5
madr

CSSリファクタリングから抽出された、賢明なCSSの基本原則:追加のみからモジュラーCSSへ

SASSで記述します。変数、ミックスインなどの利点を無視するのは正気ではありません。

スタイリングにHTML IDを使用しないでください。常にクラスを使用します。 HTML IDは、正しく使用された場合、ページ全体に1回だけ表示されます。これは、再利用性とは正反対で、賢明なエンジニアリングの最も基本的な商品の1つです。さらに、IDを含むセレクターをオーバーライドすることは非常に難しく、多くの場合、1つのHTML IDを圧倒する唯一の方法は別のIDを作成することであり、IDが害虫のようにコードベースで伝播するようにします。 Javascriptまたは統合テストフックを変更しないために、HTML IDを残す方が良いです。

アプリケーション固有の機能ではなく、視覚的な機能でCSSクラスに名前を付けます。たとえば、「。bundle」ではなく「.highlight-box」と言います。 -product-discount-box」。この方法でコーディングすると、サイドビジネスをロールアウトするときに既存のスタイルシートを再利用できます。例えば、私たちは法律ノートの販売を始めましたが、最近法律の家庭教師に移りました。私たちの古いCSSクラスには、「。download_document_box」のような名前がありました。これは、デジタルドキュメントについて話すときには意味がありますが、個人教師の新しいドメインに適用する場合にのみ混乱するクラス名です。既存のサービスと将来のサービスの両方に適合するより良い名前は、「。pretty_callout_box」です。

特定のグリッド情報に基づいてCSSクラスに名前を付けることは避けてください。CSSコミュニティには、CSSフレームワークの設計者と作成者による恐ろしいアンチパターンがありました(現在も存在しています) coughTwitter Bootstrap)は、「span-2」または「cols-8」がCSSクラスの妥当な名前であると考えています。 CSSのポイントは、マークアップに(多くの)影響を与えずにデザインを変更できるようにすることです。グリッドサイズをHTMLにハードコーディングすると、この目標が妨げられるため、週末よりも長く続くことが予想されるプロジェクトでは推奨されません。グリッドクラスを回避する方法については、後で詳しく説明します。

CSSをファイル間で分割します。理想的には、すべてを「コンポーネント」/「ウィジェット」に分割し、これらのデザインの原子からページを構成します。ただし、現実的には、ウェブサイトのページの一部に特異性があることがわかります(たとえば、特別なレイアウト、または1つの記事にしか表示されない奇妙なフォトギャラリーなど)。これらの場合、その特定のページに関連するファイルを作成し、要素が他の場所で再利用されることが明らかになった場合にのみ本格的なウィジェットにリファクタリングします。これはトレードオフであり、実際の予算上の懸念から動機付けられます。

最小限のネスト。セレクターをネストする代わりに新しいクラスを導入します。ネストするときにSASSがセレクターを繰り返すという苦痛を取り除くという事実は、5レベルの深さをネストする必要があるという意味ではありません。セレクタを過度に修飾しないでください(たとえば、 "。nav"が同じジョブを実行できる場所で "ul.nav"を使用しないでください)。また、カスタムクラス名(たとえば、 "h2.highlight")と共にHTML要素を指定しないでください。代わりに、クラス名のみを使用してベースセレクターをドロップします(たとえば、前の例は「.highlight」である必要があります)。過剰修飾セレクターは値を追加しません。

アプリケーション全体で一貫性のあるベースコンポーネントをスタイリングする場合にのみ、HTML要素(たとえば「h1」)のスタイルを作成します。「header ul」のような幅広いセレクタを避けますとにかくいくつかの場所でそれらをオーバーライドしなければならない可能性が高いからです。繰り返しますが、ほとんどの場合、特定のスタイルが必要な場合は常に、特定の適切な名前のクラスを使用します。

Block-Element-Modifierの基本を受け入れます。たとえば、ここで読むことができます。かなり軽く使用しましたが、それでもCSSスタイルの整理に大いに役立ちました。

4
Jack Kinsella

多くの場合、個人がファイルをセクションに分割し、セクション間に見出しコメントを付けます。

何かのようなもの

/* Headings and General Text */

.... stuff here for H1, etc..

/* Main page layout */

.... stuff here for layout page setup etc.

それはかなりうまく機能し、後で戻って簡単に作業中のものを見つけることができます。

2
Mitchel Sellers

BEMを見てください。

理論

BEMは、CSSセレクターを整理および命名するための一連の指示を提供して、物事をより再利用可能かつモジュール化して、スパゲッティコードと特異性の頭痛につながるようなセレクター間の衝突を回避しようとする試みです。

正しく使用すると、実際に非常に良い効果があります。

  • スタイルは要素に追加されたときに期待することを行います
  • スタイルはリークせず、追加されたものだけに影響します
  • スタイルはドキュメント構造から完全に切り離されています
  • スタイルを強制的に互いにオーバーライドする必要はありません

BEMはSASSと連携して、CSSにほぼオブジェクト指向のスタイルをもたらします。単一のUI要素の表示を処理し、色や内部要素の処理方法などの「メソッド」などの変数を含むモジュラーファイルを構築できます。筋金入りのOOプログラマーはこの考えにalkするかもしれませんが、実際には、適用された概念は、モジュール性、疎結合、緊密な結合など、OO構造の多くの優れた部分をもたらしますコンテキストフリーの再利用性。 Sassおよび& operato rを使用して、カプセル化されたオブジェクトのように構築することもできます。

Smashing Magazineの詳細な記事は こちらにあります ;です。そしてCCS WizardryのHarry Robertsからの1つ(cssに関係する人は誰でも読むべきです) ここにあります

実際に

SMACSSとOOCSSを使用したこととともに、これを数回使用しました。つまり、それらを比較するものもあります。私はまた、いくつかの大きな混乱で働いてきました。多くの場合、私自身の未経験の創造物です。

現実の世界でBEMを使用するとき、いくつかの追加の原則を使用してテクニックを強化します。私はユーティリティクラスを利用します-良い例はラッパークラスです:

.page-section {
    width: 100%;
}
@media screen and (min-width: 1200px) {
    margin: 0 auto;
    width: 1200px;
}

また、カスケードと特異性にもある程度依存しています。ここでは、BEMモジュールは.primary-boxになり、.headerは特定のオーバーライドのコンテキストになります

.header {
  .primary-box {
    color: #000;
  }
}

(すべてを可能な限り一般的かつコンテキストフリーにするために全力を尽くします。つまり、ほとんどすべてが再利用可能なモジュール内にある優れたプロジェクトを意味します)

ここで最後に指摘したいことは、プロジェクトが小さく複雑でないように見える場合でも、最初からこれを行う必要があるということです。これには次の2つの理由があります。

  • プロジェクトの複雑さが増すため、適切な基盤を構築することが重要です。CSSが含まれています
  • WordPressに基づいて構築されているためJavaScriptがほとんどないために単純に見えるプロジェクトでも、CSSで非常に複雑になる可能性があります。サーバー側のコーディングを行う必要はありません。パンフレット着用のフロントエンドには20のモジュールとそれぞれ3つのバリエーションがあります。非常に複雑なCSSがあります。

Webコンポーネント

2015年には、Webコンポーネントの検討を開始しています。私はまだこれらについてはあまり知りませんが、すべてのフロントエンド機能を自己完結型のモジュールにまとめ、BEMからフロントエンドに一種の原則を効果的に適用し、分散しているが完全に結合しているコンポーネントをしようとしています同じUIウィジェットを構築するDOMフラグメント、JS(MVC)、CSSなどの要素。

これを行うことで、theybはBEMのようなもので解決しようとしたcssに存在する元の問題のいくつかに対処すると同時に、他のフロントエンドアーキテクチャのいくつかをより健全にします。

さらに読む here と、フレームワーク Polymer here があります。

最後に

また、これは 優れた最新のベストプラクティスcssガイド -大規模なcssプロジェクトが乱雑になるのを防ぐために特別に設計されたものだと思います。私はこれらのほとんどに従うようにします。

1
Toni Leigh

ここには素晴らしい資料があり、この質問に答えるのにかなりの時間を費やしている人もいますが、別々のスタイルシートまたは個々のスタイルシートの場合は、開発用に別々のファイルを使用し、サイトのマージ全体ですべての汎用CSSを使用しますデプロイ時に単一のファイルに。

このようにして、両方の長所を活用して、パフォーマンスを向上させ(ブラウザーから要求されるHTTP要求が少なくなる)、開発中のコードの懸念を分離します。

0
quinton

"Compass Style" CSS framework をご覧になることをお勧めします。

0
Iouri Goussev