当您在CSS规则之间放置分号时，将忽略半结肠之后的规则。这可能会导致一些非常奇怪的结果。MDN具有一个JSFIDDLE，可用来清楚地显示此效果。
这是初始状态，这是在第一个规则的末端具有半柱。
幸运的是，从本质上讲，从一个人的CSS块之间排除了半隆。
我的问题是：为什么是这样？我听说是这种情况，因为它可以节省空间（在这种情况下，每个CSS规则正是一个字符）。但是这种推理虽然是真的，但似乎有点奇怪。我找不到有关CSS文件中每个字符的空间的细节，但是如果它类似于JS，则此帖子告诉我们，每个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的缩小/uglification。或减少CSS属性名称的长度，因为它们比1个char长得多，并且可以出现多次，而缩短这些可能会节省更多字节的尺寸，而不是砍掉尾随的半隆。
在我看来，比节省的字节更重要的是，对于开发人员而言，这会使它变得混乱。我们中的许多人都经过习惯训练，可以跟随闭合牙套和半隆。
returnType/functionDec functionName(arguments){
//...function body
};
是许多语言（包括JavaScript）中发现的非常常见的模式，绝对可以想象开发人员打字
cssRuleA{
/*style Rules */
};
cssRuleB{
/* Style Rules*/
};
作为这种习惯的偶然结果。控制台不会记录任何错误，开发人员将没有迹象表明在样式之外犯了一个错误。绝对最糟糕的部分是，即使cssrulea是导致错误的原因，它也可以正常工作，即使没有正确显示，cssruleb也将是未正确显示的规则。
的事实- 这将在控制台和 中记录任何错误
- 在这种情况下，未显示的样式永远不会是故障的样式
在大型项目中尤其会引起您的样式/UI问题可能具有许多不同可能根源的问题。
CSS固有的某个因素是否使该惯例更有意义？我错过的一些白皮书中有什么东西解释了为什么这是CSS的行为？就个人而言，我试图看看从有限的自动机/语法的角度来排除分号是否更快，但是我无法确定确定它是否更快。
在CSS中，规则是由块或语句定义的，但并非同时定义。一个块是一块被一对卷发括号包围的代码。语句是以分号结尾的代码的一部分。
一个空的"规则"不是有效的CSS规则，因为它不能被解析为合格规则或设备规则。因此，有理由认为两个块之间的孤独的;无效，其原因是不包含前奏的块（selector-list或at-keyword，然后是可选的序曲）是无效的：因为它不能解析为有意义的任何事物。
只有插条可以采取语句的形式，因此由半隆终止（示例包括@charset和@import）；合格的规则永远不会。因此，当遇到畸形的规则时，如果解析器尚未解析，则将其视为合格的规则，并且 everything for和包括下一个匹配的卷发括号是被消耗和丢弃，包括分号。这在CSS-Syntax-3的2.2节中简洁地描述（它说文本是非规范的，但这仅仅是因为语法本身定义了规范规则）。
和错误处理的原因在CSS中采用了这种急切的方法主要是由于选择器错误处理 - 如果保守，浏览器可能会无意中将以下规则解析为完全出乎意料的事情。例如，如果不了解 >的IE6将仅忽略p > span {...}中的p >，并将以span开头的所有内容视为有效的所有内容，则该规则最终会匹配IE6中的任何 ny span元素仅匹配支持浏览器中的元素的适当子集。（实际上，IE6中存在类似的问题 do ，带有链式类选择器 - .foo.bar被视为.bar。）您可以认为这不是自由错误处理，而是CSS规则的保守应用程序。当疑问时，最好不要应用规则，而不是将其应用于意外结果。
谁告诉你，这是出于绩效的原因而只是弥补。