5

効率的とは、コードが少ない (CSS ルールが少ない) ことを意味します。

CSSファイルをlessに変換していて、コンパイルされたCSSファイルが非常に小さいことに驚いたからです（まだ完了していません:P）

4

4 に答える 4

3

それは、LESS でコードをどのように構成するかによって大きく異なります。多くのミックスイン (グラデーションなど) を使用したり、@演算子を使用してセレクターを自由にネストしたりすると、コンパイルされた出力が非常に扱いにくくなる可能性があります。

全体として、適切に使用すれば、より効率的なコードを生成できると主張できます。ただし、プレーンな CSS を使用することもできます。

于 2012-09-16T21:30:57.070 に答える
2

上記のように、CSSが最初から非効率的であったかどうかに大きく依存します。ただし、実際には、より「効率的な」CSSを必要とする状況はほとんどありません（繰り返しではなくパフォーマンスについて話します）-はい、ルールなどを複製するのは悪いことですが、何よりもまず、コードの可読性と保守性が必要です。

一般に、プリプロセッサを使用することによる生産性の向上は、ルールの繰り返しに関する問題をはるかに上回ります。実際のファイルサイズを削減したい場合は、WinLESS（および他のコンパイラ）をソースで縮小できます。

于 2012-09-16T21:47:24.220 に答える
2

一般に、LESS や SASS などのツールは、ツールが操作している DOM の知識がないため、(適切な知識があれば) 手動で記述するほど合理化された CSS を生成できません。どのオプティマイザーも、ランタイム環境をどれだけ徹底的に評価できるかにかかっており、DOM の欠落はかなり大きな変数です。ドキュメントを適切に構成し、それを利用するように CSS を記述した場合、出力は生成されたコードよりもはるかに小さくなります。

あらゆる形式のコード生成やさらに高水準の言語と同様に、これらのツールの利点は、生産性が向上することです。より一貫性があり、おそらく保守可能な出力をより簡単に生成できますが、そのためには、これらのツールは妥協のないほど明確で「安全」であり、ドキュメントに関連付けられたときに人間が不要であると簡単に認識できるコードを生成します。一般に、開発と保守のコストは CPU サイクルよりも高いため、生産性の向上が優先されます。パフォーマンスの問題に対処する必要がある場合もあるかもしれませんが、「時期尚早の最適化は諸悪の根源です」 - Knuth

于 2012-09-16T22:00:05.087 に答える
2

LESS (コンパイル時) と Sass はどちらも CSS を縮小します。空白を取り除くことに加えて、border: 0 10px 0 10pxに変わっborder: 0 10pxたり、色が#666666に変わったりすることがあります#666。これ以上効率的ではありませんが、ユーザーのダウンロード サイズは小さくなります (モバイル デバイスにとっては価値があります)。

とはいえ、Sass には @extend という独自のディレクティブがあり、コンパイル前の状態でスタイルを論理的にグループ化できますが、コンパイル済みの状態では重複を避けるためにグループ化されます。

.classA { color: blue }

// 50 lines of code defining other elements...

.classB { @extend .classA }

次のようなものが出力されます。

.classA, .classB { color: blue }

2 つのクラスに共通点が 1 つしかないというのはそれほど大したことではないように思えますが、使用する要素が多くなり、共通点が多くなればなるほど、大きな問題になります。

そうでなければいいえ。効率は完全に著者に基づいています。

于 2012-09-16T22:34:57.243 に答える