一个基本的CSS示例。我遇到的每个浏览器都会使用边距和&填充和红色边框
.test{
margin: 4px;
border: 1px solid black;
padding: 4px;
}
.test{
border: 1px solid red;
}
当然,如果我手工编写这个CSS,我会用红色代替黑色,只有一条规则。
但是如果第一条规则来自父CSS文件(或者在我的情况下是LESS文件),我无法编辑,因为它在其他地方使用,或来自第三方库,我不想破解然后我认为别无选择,只能添加额外的规则。
现在因为我使用服务器端LESS - >使用缩小的CSS编译,对我来说似乎完全合理的是压缩器/缩小器应该将规则减少到
.test{
margin: 4px;
border: 1px solid red;
padding: 4px;
}
但是我所尝试过的一切都遵守了这两条规则;一些压缩器/缩小器甚至可以删除换行符
.test{margin:4px;border:1px solid black;padding:4px}.test{border:1px solid red}
它删除了一个换行符但留下了一个完全不必要的规则声明。这对我来说似乎很奇怪。
是否有任何系统可以做到这一点? (最好是node.js的附加组件)如果没有,我们知道为什么不呢?看起来像一个相当大的文件大小保存,没有任何缺点。
免责声明我已经尝试过搜索组合选择器,合并选择器和少数变体,如果我错过了这个程序的常用术语,请道歉,似乎很可能因为增益看起来很明显我必须是遗失了什么!
答案 0 :(得分:16)
你说:
我遇到的每个浏览器都会呈现 保证金和项目的项目填充和红色边框。
那是因为,cascading nature of CSS。它被设计为像这样工作,以达到覆盖的明确目的。这正是为什么(以及如何)在CSS中添加额外规则以覆盖的原因。
有原因
现在,我可以在预处理器中看到你的观点或者“合并”代码与相同的选择器以实现最小化目的。然而,(1)将会有一个罕见的(如果有的话)两个类在CSS代码中实际跟随之后的另一个的情况,正如你的例子所示(在这种情况下,最小化是可以的)。通常会有干预的CSS,它可以影响级联在渲染中的表现。这导致(2),它需要比最初明显(甚至可能)实现更多的逻辑。考虑这个例子:
<强> HTML 强>
<div class="test1 test2"></div>
CSS(框架文件)
.test1 {
margin: 4px;
border: 1px solid black;
padding: 4px;
}
.test2 {
border: 1px solid blue;
}
CSS(开发者文件)
.test1 {
border: 1px solid red;
}
如果正常输出,上面的代码应该按照级联呈现red
边框,就像开发人员想要的那样。现在假设LESS或其他预处理器根据您的需要进行缩小。它最终会像这样:
理论最小化
.test1 {
margin: 4px;
border: 1px solid red;
padding: 4px;
}
.test2 {
border: 1px solid blue;
}
实际上会将blue
呈现为red
!这是因为两个.test1
已合并,现在最后.test2
在级联顺序而不是.test1
的最后一个实例。因此,预处理器必须足够“智能”才能找出理论上无限数量的可能级联组合,并且不知道html编码是什么最终会影响到决定(就像这里一样,html double类与级联顺序一起决定了最终的渲染)。
如果预处理器合并到第二个实例中,那么就无法解决问题,如果开发人员在.test2
的第二个实例之后放置了第二个.test1
实例,但没有定义不同的边框颜色?通过与以下.test2
合并,仍会覆盖.test2
边框颜色。
这个例子应该说明为什么这样的最小化不能也不应该这样做 - 可能的html形式和CSS级联之间的交互逻辑是不可能预测合并的内容或者如何合并除了案例之外CSS 中的两个精确选择器字符串紧接着彼此。任何其他情况都可能做出错误的决定。