在css规则之间放置分号时,将忽略分号后面的规则.这可能会导致一些非常奇怪的结果.MDN有一个jsfiddle可以用来相当清楚地显示这种效果.
幸运的是,从一个人的css块之间排除分号本质上是普遍的做法.
我的问题是:为什么会这样？我听说这是因为它会节省空间(在这种情况下,每个css规则只有一个字符).但这种推理虽然如此,但似乎有点奇怪.我找不到css文件中每个char占用多少空间的细节,但如果它类似于JS,这个SO帖子告诉我们每个char大约是16位,或2个字节.这意味着每条规则可以节省2个字节.
根据该国家平均连接速度列表,全球平均连接速度为5.1兆比特/秒.由于我们通过不允许分号保存每个规则正好1个字符,并且每个字符是16位,我们可以显示平均需要我们节省一秒的规则量是:
5,100,000(bits/second) / 16(bits{saved}/rule)
(5,100,000/16)*[(bits * rule)/(second * bits] or
318750 (rule/second)
因此,基于全球平均连接速度,需要超过300,000条规则来节省我们一秒钟的时间.
当然,必须存在更有效的方法来为用户节省下载时间,并且还有诸如css/js的缩小/丑化.或者减少CSS属性名称的长度,因为它们比1个字符长得多,并且可以出现很多次,与剪掉一个尾随的分号相比,缩短这些可以节省大量字节的数量级.
在我看来,比保存的字节更重要的是,这对于开发人员来说是多么令人困惑.我们中的许多人都习惯于用分号跟随封闭的括号.
returnType/functionDec functionName(arguments){
//...function body
};
在许多语言(包括JavaScript)中都可以找到非常常见的模式,并且可以想象开发人员打字
cssRuleA{
/*style Rules */
};
cssRuleB{
/* Style Rules*/
};
作为这种习惯的偶然结果.控制台将不记录任何错误,开发人员将没有迹象表明在样式之外没有正确显示错误.绝对最糟糕的部分是,即使cssRuleA是导致错误的原因,它也会正常工作,即使没有任何问题,cssRuleB也将无法正确显示.这个事实
特别是在大型项目中会出现问题,因为样式/ UI问题可能有许多不同的根源.
CSS中是否存在一些固有的因素使得这种约定更有意义？我错过了一些白皮书中有什么东西可以解释为什么这就是CSS的行为方式吗？就个人而言,我试图从有限自动机/语法的角度来看是否更快地排除分号,但我无法确定它是否更快.
在 CSS 中，规则由块或语句定义，但不能同时由两者定义。块是由一对花括号包围的一段代码。语句是一段以分号结尾的代码。
空的“规则”不是有效的 CSS 规则，因为它不能被解析为限定规则或at-rule。因此，;两个块之间的单独部分是无效的，这与不包含前奏（选择器列表，或后跟可选前奏的 at 关键字）的块无效的原因相同：因为它不能被解析成任何有意义的东西。
只有 at-rules 可以采用语句的形式，因此以分号结尾（示例包括@charset和@import）；合格的规则永远不会做。因此，当遇到格式错误的规则时，如果解析器尚未解析规则，则将其视为合格规则，并且直到并包括下一组匹配的花括号在内的所有内容都将被消耗和丢弃，包括分号. 这在css-syntax-3 的第 2.2 节中有简洁的描述（它说文本是非规范的，但这只是因为规范规则是在语法本身中定义的）。
错误处理在 CSS 中采用如此急切的方法的原因主要是由于选择器错误处理——如果它是保守的，浏览器最终可能会无意中将以下规则解析为完全出乎意料的东西。例如，如果不理解 的 IE6>仅忽略p >inp > span {...}并将以 开头的所有内容span视为有效，则该规则最终将匹配IE6 中的任何 span元素，同时仅匹配支持浏览器中的适当元素子集。（事实上，IE6 中确实存在一个类似的问题，它带有链式类选择器——.foo.bar被视为.bar.) 因此，您可以认为这不是自由的错误处理，而是 CSS 规则的保守应用。最好不要在有疑问时应用规则，而不是在出现意外结果时应用它。
谁告诉你这是出于性能原因，这只是在编造。