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 这样的工具将无法像手动编写（具有适当的知识）那样生成流线型的 CSS，因为这些工具不知道它们正在运行的 DOM。任何优化器都只能与它对运行时环境的全面评估一样好，而缺少的 DOM 是一个相当大的变量。如果您正确地构建文档并编写 CSS 以利用这一点，那么输出将远远小于生成的代码。

这些工具（如任何形式的代码生成甚至更高级别的语言）的优势在于它们提高了生产力。可以更容易地生成更一致且可能可维护的输出，但为了做到这一点，这些工具将毫不妥协地明确和“安全”，因此生成的代码在与文档相关联时可以很容易地识别为不必要的。一般来说，开发和维护成本高于 CPU 周期，因此生产力收益胜出。有时可能存在需要解决的性能问题，但“过早的优化是万恶之源”——Knuth

于 2012-09-16T22:00:05.087 回答
2

LESS（编译时）和 Sass 都缩小了你的 CSS。除了去除空白之外，您有时还会看到border: 0 10px 0 10pxget 变成border: 0 10px或颜色#666666变成#666. 它不再有效，但它确实为用户减少了下载量（这对移动设备很有价值）。

也就是说，Sass 有一个名为 @extend 的独特指令，它允许您在预编译状态下对样式进行逻辑分组，但会将它们组合在一起以避免在编译状态下重复。

.classA { color: blue }

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

.classB { @extend .classA }

将输出如下所示的内容：

.classA, .classB { color: blue }

两个类只有一个共同点似乎没什么大不了的，但是你使用的元素越多，它们的共同点就越多，它的意义就越大。

否则没有。效率完全取决于作者。

于 2012-09-16T22:34:57.243 回答