任何不刪除HTML中的空白的理由

這個問題很自我解釋。爲什麼我不應該剝離它？在我看來，大多數空白純粹用於在文本編輯器中格式化，並且對最終頁面沒有影響。任何不刪除HTML中的空白的理由

更重要的是，當空白的這些隨機節點做有最後一頁上的影響，它通常是直列塊之間的撞擊，我不想，如神祕的一個字符（空格崩潰後）差距。

我可以很容易地去除所有這些空白文本節點。我有什麼理由不應該？

編輯：

這主要表現爲行爲怪異這裏的空白，而不是性能。一個例子是我想要使用inline-block而不是float來並排放置圖像，同時防止包裝到下一行並允許它們溢出父級。

空格造成了這些神祕的空白，可以通過基本縮小HTML源代碼來手動刪除內嵌塊之間的空白（並且徹底搞亂了你的源代碼格式化過程）。

來源

2011-08-18 Li Haoyi

爲什麼剝離？只需gzip你的頁面。比剝離更好也更容易。 –

沒有理由不真的。它可以通過htmlcompressor這樣的非常簡單的方式完成。

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

更新：

也許這會影響您的決定。我在網站的一個頁面上執行了一個simple minification只是爲了看看它會產生什麼樣的差異。下面是結果：

BEFORE縮小

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

AFTER縮小

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

縮小後的未壓縮文件約小3 KB。但這並不重要。 gzip壓縮文件是通過電線發送的。而且你可以清楚地看到gzip甚至在未縮小的HTML中也做得很好。

我看到了縮小js庫的好處，或者是不會不斷變化的東西。但我認爲這對你的HTML只需130字節是不值得的。

來源

2011-08-18 23:13:56

以我的經驗來看，帶寬節省（正如你指出的那樣微乎其微），你有時可以更好地解析縮小的JS cf的性能。未分類的版本。 –

從生產頁面中刪除空白的唯一缺點是可編輯性和後續編輯該頁面的人員的可維護性;但是如果你保留一個'正確'/'可讀'的空白版本進行編輯，然後縮小這個後期編輯來形成製作頁面，那麼它並不會真正引起重大問題。

我不確定這項技術有多麼有效或有用，但沒有什麼能阻止你嘗試它。

來源

2011-08-18 23:11:57

+1。但是：「我不確定這種技術會有多麼有效或有用，」如果他能像這樣保持2份，他肯定應該這樣做。這些空白字符只是增加了頁面的總下載大小！ –

他們是，但不是顯着;這不是問題的重點（我認爲......）。他談到了空白（'神祕的一個字符空白[s]'）帶來的問題，刪除空白可以減少這些問題，但不一定會通過壓縮/壓縮頁面（取決於壓縮機工具的設置）來防止。 –

在可讀性方面，我正在考慮生成HTML的方式，原始HTML縮進都已經完全搞砸了，但Inspect Element/Firebug/IE9 Dev Tools將很好地格式化並縮進它。我基本上沒有時間看原始HTML;它都是通過上述工具之一查看它的。 –

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

唯一的真正目的空白供應是使代碼更可讀的。隨着時間的推移，您可以通過從文檔中刪除所有不必要的空白區域來節省大量帶寬，並且應該將其視爲生產代碼的良好實踐。如果你壓縮你的內容，節省的費用會更少，但即使是1GB的1％也是10MB ......如果你在一個繁忙的網站上每個月處理100GB的數據，那麼刪除1％的數據可能是兩個定價層之間的差異託管...

正如你所說，一些瀏覽器（通常是IE，grrrr ....）偶爾會在它們呈現頁面時解釋空白區域，但通常在發生這種情況時，它會以您寧願的方式它沒有...

來源

2011-08-18 23:16:18 DaveRandom

IE9正是讓我想到這一點！我對規格並不完全熟悉;這些空白節點是否需要渲染？在Chrome/Safari/Firefox中，他們沒有，但IE9給了我1個字符空白GRARGH –

不應該渲染空白區域。 1個空白字符= 1個文字空間，但任何其他字符都應該被截斷。 IE6有一種惱人的習慣，表現得好像在關閉後的空白空間''元素是'
' - 這讓我感覺好幾次了！ – DaveRandom

任何不刪除HTML中的空白的理由

回答

相關問題