##1.CSS の class 命名原則
camel 規則と中線区切り方式の組み合わせ使用を推奨し、下線の使用は推奨しません。入力しにくいからです
camel 規則は異なる単語を区別するために使用し、中線は従属関係を示すために使用します。例えば：
<ul class="xxList">
<li></li>
<li></li>
<li class="xxList-lastItem"></li>
</ul>
中線はネームスペースのようなもので、スコープを限定するために使用します。この観点から見れば、モジュール化 CSS、オブジェクト指向 CSS と呼べるかもしれません
##2.低優先度原則
子選択子、子孫選択子の乱用を避けます。優先度が上がり、競合の隐患も存在します。スタイルを簡単に上書きできるようにするために、選択子の優先度を可能な限り低く保つ必要があります
スタイル変更に対面したとき、高すぎる優先度は非常に悩ましいものです。例えば：
.info .infoBody .lastItem span {
color: red;
}
この場合、lastItem の特定の span 子要素を緑色に変更するのは非常に困難です。対象の span の span 兄弟に影響を与えないようにするために、対象の span にスタイルを追加し、さらにこの一連の選択子を追加する必要があります：
.info .infoBody .lastItem span.special {
color: green;
}
そうでないと優先度が足りずに red に上書きされてしまいます。この場合、子孫選択子がさらに長くなるのを防ぐ方法はないようです
ネームスペース方式を採用すればはるかに良くなります。例えば：
.info-infoBody-lastItem span {
color: red;
}
.info-infoBody-lastItem special {
color: green;
}
選択器を低優先度に保つことで修正が容易になるため、CSS Lint でさえ id 選択子の使用を推奨していません。もちろん id 選択子が拡張をサポートしていない（id は一意）ことも重要な要因です
##3.class 命名競合の回避
複数人での協力において、競合を最大限に避けるために、スタイルにプレフィックスを追加できます。例えば：
<!-- by zhangsan -->
<ul class="zs-xxList">
<li></li>
<li></li>
<li class="zs-xxList-lastItem"></li>
</ul>
<!-- by lisi -->
<ul class="ls-xxList">
<li></li>
<li></li>
<li class="ls-xxList-lastItem"></li>
</ul>
##4.可読性と長すぎる命名
長すぎる命名、例えば"zs-dropMenu-lastItem-img"は、確かにファイルサイズを増大させますが、このような命名がもたらす可読性のメリットはテキストファイルサイズの増加よりもはるかに価値があります。ましてやテキストファイルは gzip 圧縮できます
##5.組み合わせを多く使用する
CSS にも同様の問題が存在します：複数の class を追加すべきか、新しい class を 1 つ追加すべきか？
オブジェクト指向の設計原則に「継承より組み合わせを多用せよ」というものがあります。これも同様に適用できます。継承は无从谈起ですが。組み合わせの利点はより柔軟で、拡張しやすいことです。例えば：
.fl {
float: left;
}
.fr {
float: right;
}
.bdRed {
border: 1px solid red;
}
一般的に、このようなアトム class を組み合わせてスタイルを実装する方が拡張しやすくなります（bdGreen, w950 などを追加できます）。base レイヤーと common レイヤーはこのように組織され、page レイヤー内部もこのように組織できます。これによるメリットは、スタイルが変更されたときに class の値を更新するだけで済み、特定のスタイルルールを修正する必要がないことです。もちろん、場合によってはまず新しい class を追加してから適用する必要があります。1 つの class だけを追加する方式を採用すると、毎回スタイルファイルから特定の class を見つけて特定のルールを修正する必要が生じます
（bdRed のような命名は反対される可能性があります。class 名が追加のセマンティクスを表現し、単にスタイルを示すだけでなく、スタイルが変更されたときに bdRed が実際には黒い実線ボーダーを表す場合、セマンティクスを維持するために bdRed を bdBlack に変更し、同時に html も修正する必要があるためです。組み合わせを採用すればこのような問題は存在しません。bdRed を修正するのではなく、bdBlack を新規追加するためです）
注意：OOP と同様に、拡張性は具体的な状況に応じて取捨選択する必要があります。変更が発生する可能性が低い部分で組み合わせを採用しても、CSS コードの長さが増加する以外に何のメリットもありません
##6.hook
これは最も重要な点です。class や id を hook として使用できます。hook は宙ぶらりん（どのスタイルにも対応せず、選択子に���現れない）のフックで、後から物をぶら下げることができます。hook は css hook と js hook に分かれ、どちらも非常に便利です。
css hook は変更を予防するためのものです。変更が発生する可能性のある要素にまず class を追加し、スタイルを適用する必要はありません。将来変更が発生したときにスタイルルールを埋めればよいです。実はこれは別の問題も示しています：应有的なタグを省略しないでください。より少ないタグは拡張が難しいことを意味します。例えば：
<h2> 二級タイトル<span class="btn"> 展開/折りたたみ</span></h2>
スタイル変更で二級タイトルに下線が必要になった場合、「二級タイトル」を inline タグで包み込んでからスタイルを追加する必要があります。垂直中央揃えなども影響を受ける可能性があります。最初から「二級タイトル」をタグで包んでおけば慌てずに済みます。もちろん、css hook を一堆追加する必要もありません。確かにスタイル変更が発生する可能性が低い場所もあるため、無駄と節約の間には度が存在します
js hook は js に提供する手がかりで、スタイル操作を容易にします。一般的に id を js hook として使用します。ネイティブのgetElementByIdが最も効率が高いためです。直接要素を見つけられない場合でも、検索範囲を狭めるために使用できます。同様に、class を js hook として使用することも要素検索効率を向上させ、非効率な右から左への後孫選択子スキャンによる要素検索を回避できます
参考資料
- 《高品質コードの書き方-Web フロントエンド開発修練の道》
コメントはまだありません