任何不在HTML中刪除空格的原因

Question

這個問題非常自我解釋。 為什么我不能脫掉它？ 在我看來，大多數空格純粹用於文本編輯器中的格式化，並且對最終頁面沒有影響。

更重要的是，當這些空格的隨機節點確實對最終頁面產生影響時，它通常是我不想要的影響，例如內聯塊之間的神秘一個字符（在空白崩潰之后）。

我可以很容易地剝離所有這些空白文本節點。 我不應該有任何理由嗎？

編輯：

它主要用於空白的奇怪行為，而不是性能。 一個例子是我想要使用內聯塊而不是浮動來並排放置圖像，同時防止包裝到下一行並允許它們溢出父節點。

空白會導致這些神秘的空白，可以通過基本縮小HTML源代碼來手動刪除內聯塊之間的空白（並在此過程中完全弄亂源代碼格式）來刪除這些空白。

Answer 1

真的沒有理由不這樣做。 它可以通過htmlcompressor之類的東西輕松完成。

但是，假設您通過gzip提供所有html，css和js文件，那么從剝離空白中看到的實際帶寬節省量將非常小。 那么問題就變成了，值得麻煩嗎？

更新：

也許這會影響你的決定。 我在我的網站頁面上進行了簡單的縮小 ，只是為了看看它會產生什么樣的差異。 結果如下：

在縮小之前

• 22232字節（未壓縮）
• 5276字節（gzip）

縮小后

• 19207字節（未壓縮）
• 5146字節（gzip） - 保存130個字節

縮小后，未壓縮文件縮小約3 KB。 但這並不重要。 gzip壓縮文件是通過線路發送的。 你可以清楚地看到，即使使用非縮小的HTML，gzip也能做得很好。

我看到了縮小js庫的好處，或者不斷變化的東西。 但我不認為這樣做對你的HTML有130麻煩的麻煩是不值得的。

Answer 2

讓我給出一個你不應該縮小html的原因：

最終如何呈現html與應用於它的CSS緊密相關，但是minifiers通常可以在不期待CSS的影響的情況下工作。 在編寫本文時你可以得到所有縮小器，它們會根據編碼和CSS樣式的某些假設刪除html中的空格，如果你不按照他們的預期編碼，那么瀏覽器中的縮小渲染結果將是與縮小之前不同。

例如，一些縮小器假設“塊元素”之間的空間（例如<div/> ， <p/> ）可以被移除，這通常是正確的，因為它們之間的空格對渲染最終結果沒有影響。 但是，如果在CSS中為默認顯示屬性為塊的元素設置“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> tag和white-space: pre ？

嘗試從下面的url復制html代碼片段並粘貼到你的minifier中，看看它是否在縮小之前產生結果：

https://jsfiddle.net/normanzb/58rpazL2/

Answer 3

從生產頁面中刪除空白的唯一缺點是可編輯性，以及跟隨您編輯那些/那些頁面的人的可維護性; 但是如果你保持一個'正確'/'可讀'的空白版本進行編輯，然后縮小后期編輯以形成生產頁面，那么它並不會真正造成重大問題。

我不確定這種技術會有多么有效或有用，但沒有什么可以阻止你嘗試它。

Answer 4

簡短的回答：沒有任何理由

唯一真正用途的白色空間用於使代碼更易於閱讀。 隨着時間的推移，您可以通過從文檔中剝離所有不必要的空白來節省大量帶寬，這應該被視為生產代碼的良好實踐。 如果您壓縮內容節省的費用會更少，但即使1GB的1GB也是10MB ......如果您在繁忙的網站上一個月內做100GB，那么削減1％的數據可能是兩個定價層之間的差異托管...

正如你所說，一些瀏覽器（通常是IE，grrrr ....）在呈現頁面時偶爾會解釋空白區域，但通常情況下會發生這種情況，你可能會認為它不是......