私はこれについて過去1.5時間読んでいますが、簡潔で決定的な答えを見つけることができませんでした.
私が理解している限り、ブラウザーは CSS セレクターを右から左に解析します。
これは、次のような長い CSS セレクターを意味します。
.card .container .businesscard .pinfo li.pinfo-box span:first-child
ここで SO に表示される最も効率の悪いコード行の 1 つです。
まず第一に、私はこれで正しいですか？
次に、LESS を使用してリッチな UI を設計しています。これにより、コーディングしている入れ子になった設計からこの種の巨大なセレクターが最終的に生成されます。
この種のセレクターを回避するにはどうすればよいでしょうか? クラスと ID だけに頼っていますか? しかし、ネストされた CSS を記述できない場合、LESS を使用する目的は何ですか?
ご意見をお待ちしております。
それは正しいです。ブラウザーはセレクターを右から左に評価します。spana などの中の aを見つけようとしますli.pinfo-box。
LESS を記述する際に従うべき経験則の 1 つは、3 ～ 4 レベルを超えて入れ子にしないことです。
これにより、セレクターが大きくなるのを防ぎながら、LESS のネスト機能を引き続き利用できます。
「役に立たない」入れ子の良い例は、リストのスタイリングです。時々、私は次のようにセレクターを書きます:
#wrapper .blog-post ul、#wrapper .blog-post ul li
が 内にあるli 必要があることを指定する必要は本当にありますulか? おそらく次のように書くだけで十分でしょう。
#wrapper .blog-post li
これはすべて知っておくとよいことです。しかし: これは、サイトのパフォーマンスを最適化しようとするときに最初に取り組むべきことではありません. 代わりに、リクエストの数を減らすか、他の何かに時間を費やしてください。
かなり変わったコンテンツがない限り、セレクターの解析とマッチングが大きな要因になることはまずありません。テストでパフォーマンスの問題が示されるまでは、保守可能で仕事を完了できるものを使用することをお勧めします。次に、プロファイラーを取得し (OSX では Instruments を使用しますが、ほとんどのプラットフォームで適切なプロファイラーを使用できるはずです)、ブラウザーにアタッチします。セレクターの一致がプロファイルの上位に表示される場合は、遅いセレクターを高速なセレクターに置き換えることを検討してください (id セレクターは間違いなく良い賭けです)。