私はこのことについて過去1時間半も読んでいますが、それでも簡潔さと決定的な答えを見つけることができませんでした。ネストされたセレクタのパフォーマンスへの影響とLESS
私が理解している限り、ブラウザはCSSセレクタを右から左に解析します。このような長いCSSセレクタ手段
：
.card .container .businesscard .pinfo li.pinfo-box span:first-child
は、これまでここでSOに表示するコードの少なくとも効率的なラインの一つです。
まず、この1つは正しいですか？
第2に、LESSを使用して豊富なUIを設計しています。これは、私がコーディングしているネストされたデザインの中から、この種のマンモスセレクタを最終的に生成します。
この種のセレクタを避けるにはどうすればよいですか？クラスとIDのみに依存していますか？しかし、ネストされたCSSを書くことができない場合、LESSを使用する目的は何ですか？
あなたのご意見をいただければ幸いです。
これは間違いありません。ブラウザはセレクタを右から左へ評価します。それはli.pinfo-boxの中にspanを見つけようとします。
レッスンを書くときのフォローには、は3〜4レベルを超えてはいけません。
これによりセレクタが大きくなるのを防ぐことができますが、それでもLESSの入れ子機能を利用することはできます。
「役に立たない」ネスティングの良い例は、スタイリングリストの場合です。時々、私はこのようなセレクタ書く：
#wrapper .blog-post ulを、#wrapper .blog-post ul li
はliがul内でなければならないことを指定することが本当に必要ですか？それはおそらく十分な書き込みになります。
#wrapper .blog-post li
このすべてを知って良いです。しかし、これは、サイトのパフォーマンスを最適化しようとする際にまず取り組むべきことではありません。時間をかけてリクエストの数を減らしてください。
チップをありがとう。私たちはまだ作業現場を持っておらず、現時点ではUIを設計していません。答えの始めに「左から右へ」を修正したいかもしれません:) – pilau
非常に珍しいコンテンツがない限り、セレクタの解析とマッチングは大きな要因にはなりません。私は保守可能なものを使用することを提案し、テストがパフォーマンス上の問題を示すポイントまで仕事を完了させます。その後、私はプロファイラを使いました（OSX上ではInstrumentsを使用していましたが、ほとんどのプラットフォームで使用できるはずのものが必要です）。セレクタの一致がプロファイル上で高く表示されている場合は、遅いセレクタを高速なものに置き換える（idセレクタは間違いなく良い選択です）。
これは興味深いことです。私はWindows上で1つ探します。ありがとう！ – pilau
セレクタが複雑になっているようです。セレクタに '.container'が必要ですか？ '.container'がその先祖の1人でないなら、あなたは本当に' span：first-child'のスタイルを違うものにするつもりですか？私は、 – cimmanon
を参照してください。私はあまりにも深くネストしたと思います。 – pilau
奇妙なことに、Sass/SCSSに関する同様の質問がちょうど昨日尋ねられました：http：// stackoverflow。com/questions/13805324/how-it-in-practice-to-over-nest-select-in-sass-scss – BoltClock