HTML 和電子郵件：您應該避免的 6 個常見錯誤

使用 HTML 代碼構建電子郵件？ 這裡有 6 個你應該避免的過於頻繁的錯誤，以便從簡化、乾淨的電子郵件通信中獲益。

錯誤 1. 使用過於冗長的代碼

我們知道，多虧了 HTML 和 CSS，我們可以構建電子郵件結構並為其提供一種形式，或者更確切地說是一種格式，從而可以顯示特定類型的字體、特定的背景顏色、圖像等。

現在我們將看到 HTML 和 CSS 標籤如何在某些方面執行相同的功能，並最終重疊。 讓我們舉一個實際的例子：在 HTML 和 CSS 中定義表格的背景顏色。

代碼顯示在圖像中。 可以看到定義了背景色的有兩點：

• bgcolor = “#e75c00”是標籤表的屬性；
• background-color是應用於表格的 CSS 屬性。

這兩個屬性做同樣的事情，所以它們重疊：它們在表格的背景上施加橙色（根據十六進制格式為#e75c00）。

關鍵點現在應該更清楚了：HTML 和 CSS 屬性定義可以相互疊加。 事實上，當重新設計或改變相同的電子郵件模型時，代碼通常會被執行相同功能的冗餘屬性所困擾。

這還不是全部。 由於內聯樣式可以應用於每個元素，因此也可能發生這種（反常的）情況：

瀏覽器（或電子郵件客戶端）或多或少會像這樣讀取代碼：

• 將灰色背景 ( bgcolor = “#efefef” ) 應用到表格
• 十應用黑色背景（ bgcolor = “#000000” ）到行
• 最後，將橙色背景 ( background-color: #e75c00 ) 應用於包含文本Hello World!的單元格！

此示例和前一個示例中的最終結果相同：橙色背景上的白色文本。

問題是在第二種情況下定義了三種不同的背景規則。 用戶看到的是與單元格相關的定義，因為瀏覽器是按順序讀取代碼的（table -> tr -> td）。 由於最後一個定義是在<td>上設置的，這正是將要顯示的內容。

很明顯，大部分代碼不是必需的。 這不僅是因為顯示的唯一背景顏色是應用於單元格的背景顏色，還因為良好的電子郵件營銷的目標之一是使通信盡可能輕鬆。 非常冗長，冗餘的代碼不是輕量級的代碼。

我們的建議：

• 保持代碼盡可能乾淨
• 格式化代碼時避免不必要的重複
• 優先考慮內聯樣式
• 嘗試為通信代碼構建模塊化結構
• 盡量通過縮進保持代碼的有序性（有幾個在線服務可以做到這一點，如 HTMLformatter 或 Clean CSS），以便能夠對通信結構有一個概覽
• 跟踪對模型所做的宏觀更改的歷史記錄

錯誤二、代碼註釋過多

與大多數語言一樣，也可以向 HTML 添加註釋。 什麼是 HTML 腳本中的註釋？ 它是列表中被讀取和執行代碼的程序忽略的一部分。

下圖給出了一個註釋示例：

如您所見， <!-和->之間的所有內容不僅是不同的顏色（取決於編輯程序），最重要的是，它不會顯示在屏幕上。

這允許插入有關已編寫代碼的“服務通信”，或尚未完成或需要改進的部分的說明。

還有另一種使用註釋的方法。 由於未顯示開始標記和結束標記之間包含的所有內容，因此可以使用它隱藏整個頁面部分，如下例所示。 事實上，我們可以看到屏幕上只有三行可見，而不是代碼中寫的四行。

它當然是有用的工具，但我們不能濫用它。 雖然確實沒有顯示註釋代碼，但它仍然保留在發送的通信中，從而影響了它。

我們的建議：

• 明智地使用註釋，例如指示通信結構的開始和結束，或插入對開發人員有用的信息
• 不要在評論中囉嗦，最好用英文寫
• 發送前刪除註釋代碼，因為它不是用於通信目的

錯誤 3. 錯誤管理電子郵件內容

在設計電子郵件時，甚至在編寫一行代碼之前，最好定義某些在後續實現階段無法修改的參數，從而在生產過程中無法修改。

其中一些參數包括：

• 郵件寬度
• 圖片尺寸
• 圖片數量
• 標題中使用的字體大小
• 正文複製字體大小

等等。 一個經常被忽略的參數是任何文本元素的最大擊鍵次數。

在這一點上，你可能會反對說我們對規則的狂熱是有罪的，但如此嚴格有兩個很好的理由。 第一個是概念性的，第二個是操作性的。

在概念層面上，內容（文本、圖像等）和容器（HTML 結構）是兩個獨立的實體，具有非常精確的層次結構，前者從屬於後者。

事實上，內容應該適應容器，而不是相反。 通信的架構是在編寫代碼時構建的。 這定義了容器，一旦成形，容器將保持不變，無論內容如何，即使電子郵件已被創建為響應式。

總之——用李小龍的話來說——內容就像水：如果你把水放在杯子裡，它就會變成杯子； 如果你把水放在瓶子裡，它就會變成瓶子； 如果你把水放在茶壺裡，它就變成了茶壺。

你不能指望杯子會變成瓶子，而茶壺永遠不會是杯子。 因此，文本（或圖像或按鈕）必須適應包含它的結構，而不是相反。

第二個原因是更具操作性。 如果用於編寫通信的所有參數都是先驗已知的，那麼不僅可以在起草階段創建更有效的通信，而且還可以創建更平衡的通信。

讓我們舉一個更具​​體的例子：假設我們有一個包含兩個並排產品的 DEM。 產品通常與：

• 一個圖像
• 產品名稱
• 產品描述
• 價格
• 指向產品頁面的 CTA

現在，由於產品是並排的，零件必須平衡。

這意味著圖像必須具有相同的高度，描述性文本必須具有相似的長度，並且兩個 CTA 不能太相似。

忽略或不尊重這些基本原則可能會導致上圖所示的情況。

這兩個元素之間的對稱性被打破了，因為左邊的產品標題太長，覆蓋了三行，而右邊的太短，只佔一行。 引入了不和諧，最終削弱了整個溝通。

在考慮移動世界時，遵守這些規則變得更加重要，其中所有不同的設備都有非常不同的分辨率：從 iPhone X 的 1125 x 2436 像素到三星 Galaxy S8 的 1440 x 2960 像素，通過Microsoft Lumia 1020 的 768 x 1280 像素。

當這種巨大的多樣性與密集的電子郵件客戶端叢林重疊時，這意味著我們無法完全控制 DEM 顯示，因為沒有確定的代碼可以在每種情況下適應像素。 因此，如果您無法通過代碼控制它，則必須嘗試通過更改構成電子郵件的其他部分（例如文本的長度或圖像的大小）來間接進行控制。

我們的建議：

• 定義模板的所有部分
• 在通信的不同部分之間保持一致
• 尊重你給自己制定的規則
• 規則可以被打破，但這必須在充分意識到的情況下完成
• 如果模板不能滿足您的需求，您可以開始考慮定義一個新的

錯誤 4. 獲取交互式電話號碼和地址錯誤

有時，電子郵件發件人會添加他們的聯繫信息，尤其是在頁腳中。 這通常包括地址和電話號碼。

雖然電話號碼和地址可以是桌面客戶端電子郵件的標准信息，儘管它們很少使用，但這些元素在移動端尤其重要。

發生這種情況主要有兩個原因：

• 您可以通過單擊打開管理數據的應用程序（日曆、電話、瀏覽器）
• 減少了顯示空間，因此即使位於頁腳中，每條信息也具有更大的可見性

因此，在開發通信時不要忘記這些細節也很重要，因為它們的行為在不同的設備上有所不同。

讓我們花點時間考慮通過模擬臨時創建的示例。 這兩個示例均由 iPhone 6+ iOS 9 顯示。

左圖顯示了用戶收到的簡報，文本直接輸入，沒有任何格式。

從技術角度來看，一切都是正確的，但我們必須考慮到代碼是由移動設備上的電子郵件應用程序本身解釋的事實。 它“讀取”電子郵件的文本，當它識別出日期、地址或電話號碼形式的文本時，它會自動將活動鏈接鏈接到相應的應用程序，即日曆、地圖或手機。

這一切都非常方便，因為只需單擊一下，您就可以撥打電話、安排活動或打開地圖來設置路線。 唯一可以為此感到難過的是美術和開發人員，他們不喜歡看到藍色鏈接和下劃線。 那麼我們應該怎麼做呢？ 我們應該如何進行？

您可以使用一個小的解決方法或技巧來使事情恢復正常。 讓我們明確一點：儘管它們違反了格式良好的 HTML 的規則，但在浩瀚的電子郵件客戶端中，變通方法是必不可少的。

如果開發人員的主要目標是使通信在盡可能多的客戶端上可見，那麼他們需要妥協並接受變通方法。

那麼讓我們看看代碼是如何改變的。

對於電話，這很簡單：由於錨標記可以通過在屬性href 中使用tel來定義電話號碼，因此我們添加電話號碼時沒有任何空格或分隔線。

但是，我們需要以不同的方式處理地址或日期。 對於這些，有必要定義一個類 (.address) 來施加錨標記，該標記將自動在客戶端中插入顏色（顏色：#ffffff;）。 最重要的是，它應該刪除下劃線，這是每個鏈接的默認功能 (text-decoration:none;)。

請注意，地址類的兩個屬性都有!important ，無論屬性如何，客戶端都必須應用它。 沒有它，就不能保證該變通辦法能夠完成它的工作。

我們的建議：

• 始終注意通信如何在手機上顯示（即通過測試）
• 在可能的情況下，使用微修復使通信適合移動設備
• 不要假設對桌面有好處的東西也對移動設備有好處
• 了解您的受眾：他們使用哪種技術？ 哪些設備？ 哪個媒體？
• 使用內部測試來試驗您自己的通信，尤其是當電子郵件客戶端應用程序有大量更新時

錯誤 5. 不清理廢棄或空標籤

繼續嘗試將​​通信的整體權重保持在最低限度的目標，我們需要注意現有代碼中已清空其自然內容的部分。

讓我們馬上給出一個具體的例子：一個<font>標籤，可能帶有一系列內聯樣式，不包含任何文本。 顯然，電子郵件端將無法讀取任何內容，但<font>格式化標籤繼續存在並佔據電子郵件中的物理空間。

另一個經典的例子是 <a> 沒有鏈接對象的錨標籤，比如： <a href=”http://www.mailup.com” style=”color:#00000;text-decoration:none”> </a>。

通常這些“錯誤”存在於那些經過多次返工或多次使用的代碼中，從而插入、修改或刪除了不同的部分，例如圖像、鏈接和文本。 或者，這可能表明 WYSIWYG 編輯器使用不當。 事實上，如果使用不當或不謹慎，這些編輯器存在向代碼添加代碼的缺陷，因為每個預定義元素通常都有一部分從編輯器本身創建時就定義的代碼。

每次插入所選元素時，程序都會不加批判地應用模型，因此，當您重寫電子郵件的同一部分足夠多次時，就會出現此問題。

我們的建議：

• 編寫代碼時，始終檢查是否有廢棄或空標籤
• 如果您使用 WYSIWYG 編輯器並且可以訪問代碼，請執行檢查以確保一切正常並且沒有此類錯誤

錯誤 6. 使用未經驗證的 HTML

談論電子郵件代碼的驗證是一個棘手的話題。

“萬維網上的大多數頁面都是用計算機語言（如 HTML）編寫的，這些語言允許網絡作者構建文本、添加多媒體內容並指定結果應具有的外觀或樣式。

至於每種語言，它們都有自己的語法、詞彙和句法，用這些計算機語言編寫的每一份文檔都應該遵循這些規則。 對於直到 XHTML 1.1 的所有版本，(X)HTML 語言都使用稱為 DTD 的機器可讀語法，這是一種從 SGML 繼承的機制。

然而，正如自然語言中的文本可能包含拼寫或語法錯誤一樣，使用標記語言的文檔可能（出於各種原因）不遵循這些規則。 驗證文檔是否真正遵循其使用的語言規則的過程稱為驗證，而用於此的工具是驗證器。 成功通過此過程的文檔稱為valid 。

考慮到這些概念，我們可以將“標記驗證”定義為根據它聲稱使用的語法（通常是 DTD）檢查 Web 文檔的過程”。

W3C 定義

W3C 通過提供代碼驗證工具來幫助我們作為代碼的守護者和保證者，該工具的分析表明錯誤並建議糾正錯誤的方法。 借助此工具，可以識別和糾正較大的結構錯誤。

值得記住的是，電子郵件營銷有兩種情況：

• 一方面，HTML 是一種具有非常精確的規則和結構的標準化語言
• 另一方面，一系列不標準的變通方法，通常不受歡迎，但如果您想在電子郵件客戶端上獲得正確的可視化效果，這些變通方法效果很好

這兩個方面就像一對老夫妻，激情早已煙消雲散。 他們不知道為什麼要住在一起，但他們被迫做出妥協。

那麼為什麼要談論代碼驗證呢？ 是否有意義？ 有哪些妥協？

從更廣泛的角度討論代碼驗證是有道理的，而不是太深入細節。 因此，當涉及到結構、組成電子郵件的模塊以及構成通信主幹的表格時，擁有與 W3C 規定的標準一樣乾淨且接近標準的代碼是非常有意義的。盡可能。

然而，我們必須意識到現實，因此妥協在於創建一個堅固且功能性的結構，在其中添加變通方法作為一種微調，以將正確的可視化擴展到盡可能多的客戶。

我們已經知道，變通方法只不過是規則的例外，或者不是完全正統的技術，源自通過經驗積累的知識，但它們的存在僅有意義，因為它們允許正確可視化代碼，無需任何分頁。

我們的建議：

• 如果您對代碼有疑問，驗證可以作為一種快速有效的分析工具
• 代碼驗證可以成為快速識別代碼清單中最大錯誤的好工具
• 經過驗證的代碼始終是後續發展和調整與變通方法的通信的絕佳起點，以使其盡可能通用
• 驗證可以被視為代碼的“服務”，尤其是在經常操作和返工的模型上
• 隨著經驗的積累，為各種客戶建立一個小型的臨時解決方案庫，以節省解決問題的時間