使わないほうが良い、とされるコーディング理論があります。セレクタは再利用性や汎用性を低下させるので、積極的に使うべきではないとされています。度しか使われないですから、再利用される頻度が低い、ということです。使うべきではありません。コンテンツやテキストはページに複数回登場する可能性があります。単純な装飾は繰り返し使えるようにしておきます。サイトへ使い回すこともできます。ページの本文や主たるコンテンツの装飾は、多くのサイトで使うことができるでしょう。この場合には再利用性は(あまり)関係ありませんね。余計な情報を付与して冗長なコーディングになる気がします。なんて命名は最近見ない気がしますが、本質的な内容が分かれば良しにします。サイトのコーディングに使い回しにくい、ということはあります。名が、同じようなページレイアウトのために使われているとは限らないためです。ように抽象的な内容の場合には、ページ全体のどの部分であるかは定かではありませんね。あっても使い回すことは難しいので、大きな欠点にはならないように思います。セレクタの優先順位は、概ね次のようにされています。ブラウザは並列されたセレクタを右側から解釈し、優先順位が等しい場合には、新しく定義された設定を優先します。ファイルのより下部に書かれた設定を優先する)。よって上書きすることができません。定義された設定を上書きできない場合があります。追加することになります。追加することは、ページと設定ファイルの冗長さを増し、可読性の面でも良くありません。定義されているのであれば、上書きできないケースは極めて少なくなります。設定の上書きのために余計な要素やセレクタを追加する必要がありません。定義することは大いに有効でしょう。ファイルを遡って全体の定義を確認することなく設定を上書きすることができます。堅牢さに利点があるプログラミングにおいては、バグを防ぐために、親のシステムの一部をその子のシステムから変更できないようにするコーディングが求められます。この役割を担うことができます。定義された設定は絶対に変更されません。活用することは考えられます。使うべきではない、というコーディング理論があります。セレクタによって再度装飾される場合は、設定が上書きされます。いくつかの要素が再描画される程度であればこの問題は無視することができます。レイアウトに関わる装飾の場合は、再度レイアウトをやり直し、その要素の子要素を再度描画することになります。そのようなケースの場合には、ページの描画は遅くなってしまいます。解析にも負荷がかかりますし、高速に描画するためには、このような仕様を理解しておく必要があります。コーディングの時点で回避できる問題は、可能な限り回避するべきです。設定情報を順に走査しないために、多少の高速が見込めるようです。これについては定かではありません。具体的で信憑性の高いソースが見当たりませんでした。理屈は理解できますが。使った方が描画が高速化されるはずである、という考え方があるようです。確かにその通りでしょう。検索すれば検証した例もいくつか見つかります。全体のレイアウトのために使われることの方が多いですし、その数は決して多くないでしょう。それ程に大きなメリットには見えない気がします。可能な限り使わないこと。ファイル内の上部に定義し、リフローやリペイントが発生しないように注意すること。コメントをキャンセルメールアドレスが公開されることはありません。*次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。コメントデータの処理方法の詳細はこちらをご覧ください。