通过有效我的意思是更少的代码(更少的CSS规则)。
因为我正在将CSS文件转换为更少,我很惊讶地发现编译后的CSS文件非常小(我还没有完成:P)
答案 0 :(得分:3)
这取决于你在LESS中构建代码的方式。如果你使用大量的mixins(例如用于渐变)或者@
运算符过于宽松地嵌套选择器,编译后的输出会变得非常笨重。
总而言之,如果使用得当,他们可以说他们“可以”生成更高效的代码。但是,你也可以使用普通的CSS。
答案 1 :(得分:2)
如上所述,它在很大程度上取决于你的CSS是否效率低下。但是,在实践中几乎没有情况需要更多"高效" CSS(我说的是性能而不是重复) - 是的,复制规则等是不好的,但首先应该是代码可读性和可维护性。
总的来说,我发现使用预处理器带来的生产力提升远远超过了规则重复的任何问题,如果它想要减少实际文件大小,那么WinLESS(和其他编译器)可以缩小来源。
答案 2 :(得分:2)
一般来说,像LESS或SASS这样的工具将无法像手动编写(使用适当的知识)那样生成简化的CSS,因为这些工具不了解它们正在运行的DOM。任何优化器只会像评估运行时环境的程度一样好,而缺少的DOM是一个非常大的变量。如果正确构造文档并编写CSS以利用它,则输出将远小于生成的代码。
这些工具的优势,如任何形式的代码生成,甚至更高级别的语言,都可以提高生产力。可以更容易地产生更一致且可维护的输出,但是为了这样做,这些工具将是毫不妥协的明确和“安全”的,并且因此产生人类在与文档相关联时能够容易地识别为不必要的代码。一般而言,开发和维护成本高于CPU周期,因此生产率提高了。当可能存在需要解决的性能问题时,可能会有其他时间,但“过早优化是所有邪恶的根源” - Knuth
答案 3 :(得分: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个类只有一个共同点,这似乎没什么大不了的,但是它使用的元素越多,它们的共同点就越多。
否则没有。效率完全基于作者。