这个问题非常自我解释。为什么我不能脱掉它？在我看来，大多数空格纯粹用于文本编辑器中的格式化，并且对最终页面没有影响。
更重要的是，当这些空白的随机节点对最终页面产生影响时，它通常是我不想要的影响，例如神秘的一个字符（在空白崩溃之后）差距在内联块之间。
我可以很容易地删除所有这些空白文本节点。我不应该有任何理由吗？
编辑：
这主要是针对空白的奇怪行为，而不是表现。一个例子是我想要使用内联块而不是浮动来并排放置图像，同时防止包装到下一行并允许它们溢出父节点。
空白会导致这些神秘的空白，可以通过基本缩小HTML源代码来手动删除内联块之间的空白（并在此过程中完全弄乱源代码格式）来删除这些空白。
答案 0 :(得分：4)
没有理由不，真的。它可以通过htmlcompressor等方式轻松完成。
但是，假设您通过gzip提供所有html，css和js文件，那么从剥离空白中看到的实际带宽节省量将非常小。那么问题就变成了，值得麻烦吗？
更新：
这可能会影响您的决定。我在我的网站页面上执行了simple minification只是为了看看它会产生什么样的差异。结果如下：
在缩小之前
缩小后
缩小后，未压缩文件缩小约3 KB。但这并不重要。 gzip压缩文件是通过线路发送的。你可以清楚地看到，即使使用非缩小的HTML，gzip也能做得很好。
我看到了缩小js库或者不会不断变化的东西的好处。但我不认为这样做对你的HTML有130麻烦的麻烦是值得的。
答案 1 :(得分：1)
从生产页面中删除空白的唯一缺点是可编辑性，以及跟随您编辑那些/那些页面的人的可维护性;但如果你保持一个正确的“可读”的可读性。 whitespaced-version用于编辑，然后缩小后期编辑以形成生产页面，然后它不会真正导致重大问题。
我不确定这项技术会有多么有效或有用，但是没有什么可以阻止你尝试它。
答案 2 :(得分：1)
让我给出一个为什么您不应该缩小html的原因：
最终呈现html的方式与应用在其上的CSS紧密相关，但是缩小器通常在不期望CSS影响的情况下工作。您在撰写本文时可以使用的所有缩小器，它们都会根据您的编码和CSS样式的某些假设删除html中的空格，如果您未按预期的方式进行编码，则浏览器中的缩小渲染结果将是与缩小之前不同。
例如，一些缩小器假设“块元素”之间的空间（例如<div/>，<p/>）可以删除，这通常是正确的，因为它们之间的空间对渲染没有影响最终结果。但是，如果在CSS中为默认显示属性为block的元素设置了“ display：inline”或“ inline-block”呢？
如果您删除<div/> s之间的空格，则html代码段下方是否仍将按原样呈现？
<div style="display: inline">will</div> <div style="display: inline">this</div> <div style="display: inline">still</div> <div style="display: inline">work?</div>
您可能会争辩说，我们可以保留至少1个空间，并删除剩余的连续空间，但仍然可以节省很多字节。那么<pre>标签和white-space: pre呢？
尝试从url下面复制html代码段，然后粘贴到您的缩小器中，看看它是否产生缩小之前的结果：
答案 3 :(得分：0)
简短回答：没有任何理由
唯一真正用途的空白区域是使代码更易于阅读。随着时间的推移，您可以通过从文档中剥离所有不必要的空白来节省大量带宽，这应该被视为生产代码的良好实践。如果您压缩内容节省的费用会更少，但即使1GB的1GB也是10MB ......如果您在繁忙的网站上一个月内做100GB，那么削减1％的数据可能是两个定价层之间的差异托管...
正如你所说，有些浏览器（通常是IE，grrrr ....）在呈现页面时偶尔会解释空白区域，但通常情况下会发生这种情况，你会更喜欢它。