電子郵件開發的 7 個誤區
已發表: 2016-10-251971 年,電子郵件最初是一種純文本的 1:1 通信方式,當時它是由 Ray Tomlinson 構思的。 幾十年來,電子郵件不斷發展,從早期電子郵件的純文本版本轉變為 HTML。 將電子郵件推向未來的是電子郵件開發人員,他們在嚴格的範圍內使用創造性的技術。
在那個時候,電子郵件開發人員創建了所有類型的“最佳實踐”來幫助其他人開始使用電子郵件編碼,或者提醒那些處於戰壕中的電子郵件開發人員可以做什麼和不可以做什麼。
我們今天在這裡提醒電子郵件開發人員,最佳實踐不應被視為靜態的。 他們改變。 1990 年代後期最適合電子郵件開發人員的做法在 2010 年代中期不再適用。
以下是七個流傳已久的電子郵件開發誤區,以及為什麼是時候讓它們停下來了:
- 誤區一:電子郵件的寬度必須為 600 像素。
- 誤解 2:您必須只使用標準系統字體。
- 誤區 3:只使用 Transitional DOCTYPE。
- 誤區四:需要使用屬性選擇器。
- 誤區 5:電子郵件中的所有樣式都必須內聯。
- 誤區 6:不要在電子郵件中使用背景圖片。
- 誤區 7:所有電子郵件客戶端的電子郵件必須看起來相同。
誤區一:電子郵件的寬度必須為 600 像素。
在手機和平板電腦變得司空見慣並且電子郵件僅僅是桌面應用程序之前,最佳實踐規定所有電子郵件的寬度不應超過或小於 600 像素。 為什麼正好是 600 像素? 當時最常用的電子郵件客戶端(HoTMaiL、Yahoo 和 Outlook)的視口大小約為 500-550 像素。 將電子郵件寬度設置為不超過 600 像素將允許電子郵件中的水平滾動盡可能少。
那個 600 像素的規則一直存在。 即使今天有更多的設備可以滿足,所有設備都有不同的屏幕尺寸,為什麼我們堅持這個 600 像素規則?
這是一個容易遵守的規則,特別是如果您的電子郵件工作流程包括在 Adobe Photoshop 或 Sketch 中創建設計——您需要一個物理寬度來開始您的電子郵件設計。 的確,600 像素寬度的電子郵件在桌面上的更流行的電子郵件客戶端中仍然可以很好地顯示。 通過使用媒體查詢,電子郵件開發人員可以根據訂閱者用來打開的設備輕鬆更改電子郵件的寬度。
流體寬度解決了電子郵件開發人員需要支持的設備數量過多的問題。 為了實現這一點,請使用 max-width 阻止電子郵件在較大的視口上變得太寬和難以辨認,並使用 MSO 條件語句讓 Outlook 理解(因為它不呈現 max-width CSS 屬性)。

Zalando 的電子郵件寬度為 450 像素——與我們習慣看到的 600 像素標準相差甚遠。 結合大型 CTA,看起來 Zalando 的移動友好電子郵件更適合移動人群。

同時,Email Weekly 的郵件採用流體技術,最大寬度為 960 像素。 它使用媒體查詢根據設備寬度優雅地更改電子郵件的寬度。
根據訂閱者用來打開電子郵件的客戶端和設備,將電子郵件的寬度設置為 600 像素以外的最大值是有意義的。
![]() | 您的訂閱者在哪裡打開您的電子郵件?通過電子郵件分析,您可以找出他們打開您的電子郵件的設備和電子郵件客戶端。 了解更多 → |
誤解 2:您必須只使用標準系統字體。
系統字體長期以來一直是用於電子郵件的安全選擇。 好吧,他們是唯一的選擇。
另一方面,自 2000 年代初以來,網頁設計師一直在嘗試在網頁上使用非標準字體。 2008 年,CSS 規則@font-face 終於得到了網頁瀏覽器的支持,讓網頁設計師可以在他們的網站上使用非標準字體。 2010 年,谷歌推出了自己的網頁字體庫,供網頁設計師免費使用。
由於缺乏將 Web 字體導入 HTML 電子郵件的可靠方法,電子郵件設計人員沒有這樣的運氣。 更不用說缺乏許可:當第一次創建網絡字體時,沒有人想過它們會在電子郵件中使用,因此網絡字體的許可不包括電子郵件的使用。
儘管我們建議您在電子郵件中使用標準系統字體,但這並不意味著您不能將 Web 字體用作漸進式增強技術。 在線字體庫開始在其許可中涵蓋電子郵件的使用。 Google Fonts 擁有 800 種免費使用的網絡字體,現在正成為希望在電子郵件中使用非標準網絡字體的電子郵件設計人員的首選庫。
Google Android 4.4、iPhone、iPad 和 Mac 的 Apple Mail 以及 OS X 上的 Outlook 2011 和 2016 中都支持 Web 字體。這似乎不是很多,但截至今年 9 月,前五名電子郵件客戶端中有四個,在市場份額上,支持網頁字體——iPhone、iPad、谷歌安卓和蘋果郵箱。 這佔 9 月份打開的所有電子郵件的 50% 以上! 當然,您需要查看自己的訂閱者群,但這是一個很好的指標,可以表明有多少人能夠在您的電子郵件中看到網絡字體。

你能看出這兩封電子郵件之間的細微差別嗎? 左邊的一個是使用網絡字體,而右邊的一個禁用了網絡字體。 Outnet 選擇了一種很棒的後備字體,它在外觀和感覺上與他們的 Web 字體非常接近,展示瞭如何在今天的電子郵件中始終如一地使用 Web 字體。
誤區 3:只使用 Transitional DOCTYPE。
HTML 文檔的 DOCTYPE 告訴瀏覽器如何呈現頁面,並用於驗證文檔的 HTML。
電子郵件中最常用的 DOCTYPE 是:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional //EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">電子郵件開發人員已經養成了擁有 DOCTYPE 的好習慣,儘管一些電子郵件客戶端會完全剝離 DOCTYPE 或用不同的 DOCTYPE 替換它。 Gmail、Outlook.com 和 Yahoo! 郵件是刪除電子郵件中存在的任何 DOCTYPE 並將其替換為 HTML5 DOCTYPE 的電子郵件客戶端之一。

在 Web 上,不同的 DOCTYPE 會改變一些 CSS 屬性和 HTML 元素的呈現方式。 上面的 DOCTYPE 允許最廣泛的 HTML 元素,包括不推薦使用的元素,例如 <font>,它們已在電子郵件中使用。 在過去的測試中,此 DOCTYPE 被證明是最可靠的電子郵件。 已被證明——過去時。
這是在 HTML5 成為現在的標準之前:
<!DOCTYPE html>HTML5 DOCTYPE 允許使用較新的 HTML5 元素,例如 <video>,可以在電子郵件中使用。 雖然並非所有客戶端都能夠呈現新元素或屬性,但沒有理由不通過更新您的 DOCTYPE 將您的電子郵件推向未來。 您仍然可以將已棄用的代碼與 HTML5 DOCTYPE 一起使用,但在通過驗證服務進行檢查時,該代碼將不再有效。 儘管無論您的代碼有效與否,都不會在可傳遞性或性能方面對您的電子郵件產生影響,但檢查您的 HTML 標記是否有打開的 HTML 標記可能是一個好主意,這可能會影響您的電子郵件的呈現方式。
誤區四:需要使用屬性選擇器。
雅虎! 與 Outlook 相比,Mail 是一個稍微友好的電子郵件客戶端。 只要我們記得,它就支持頭腦中的風格。 一個怪癖雅虎! Mail 確實提供的是,它將媒體查詢中的任何 CSS 語句與媒體查詢之外的任何 CSS 一起呈現。 對此的簡單解決方法是將 CSS 語句編寫為屬性選擇器:
*[class=”foo”] {color:#000000; font-family: sans-serif;}像這樣在電子郵件頭部編寫 CSS 成為標準,因為其他電子郵件客戶端也讀取頭部樣式,讀取簡單的屬性選擇器沒有問題,如上面的示例。
2015 年初,雅虎! Mail 推出了一項更新,使其能夠像任何“普通”電子郵件客戶端一樣閱讀樣式:
.foo {color:#000000; font-family: sans-serif;}然而,因為屬性選擇器在電子郵件開發中已經根深蒂固,所以看到它們仍然在電子郵件代碼中出現也就不足為奇了。 電子郵件開發人員只是習慣於使用它們,並且電子郵件模板經常未更新。
以前無害的屬性選擇器現在可能對您的電子郵件造成一些傷害,如果您的代碼中確實有它們的話。 如果您的電子郵件樣式在 Gmail 中似乎不起作用,請檢查您是否仍在樣式中使用屬性選擇器。 Gmail 不支持屬性選擇器,但現在(終於!)支持 <head> 中的樣式。
Yahoo! 不再需要屬性選擇器Mail 和 Gmail 缺乏對它們的支持,因此無需在電子郵件的 CSS 中使用屬性選擇器。
誤區 5:電子郵件中的所有樣式都必須內聯。
用於佈局和內聯樣式的表格一直是電子郵件開發的基石……永遠。 它們定義了電子郵件和 Web 開發之間的區別。 內聯樣式現在對於電子郵件開發人員來說是如此普遍,對於為什麼必須首先內聯樣式變得有點模糊。
令人震驚的是,一些網站聲稱需要內聯樣式的原因是 Outlook 和 Gmail。 這是完全錯誤的。 [推特]
Outlook 從未遇到過電子郵件標題中的樣式問題。 另一方面,Gmail 做到了。 Gmail 確實是電子郵件開發人員內聯 CSS 的最大原因(截至 2016 年 9 月,其市場份額為 16%)。
9 月底,Gmail 開始支持頭部樣式。 那麼我們是否需要內聯所有樣式?
如果您的訂閱者主要使用 Gmail、iOS 甚至 Outlook,我們可以自信地說,現在是時候將您的風格轉移到頭腦中了。 但是,如果您的大多數訂閱者使用依賴於內聯樣式的晦澀的電子郵件客戶端或國際電子郵件客戶端(Yandex、Libero、Terra),您可能不得不繼續使用它們。 與往常一樣,我們提倡在您對電子郵件進行任何重大更改時對其進行測試。
誤區 6:不要在電子郵件中使用背景圖片。
眾所周知,背景圖像很難在電子郵件中正確顯示。 電子郵件開發人員使用複雜的 VML 代碼為他們呈現在許多版本的 Outlook 中,並且其他電子郵件客戶端也缺乏對背景圖像的支持。
事情是這樣的:背景圖像可以並且確實在電子郵件中起作用,但這是將它們融入電子郵件設計的方式。 在有限的支持下,您不應將背景圖片用作電子郵件設計中的關鍵元素,因為這會影響訂閱者的體驗。 但是您可以在電子郵件中使用它們,就像您使用網絡字體的方式一樣——作為一種漸進式增強。

不在電子郵件中使用背景圖片的最大原因之一是 Gmail 缺乏對 CSS 屬性 background-size 和 background-position 的支持。 這些 CSS 屬性對於高像素密度屏幕和混合/流暢/響應式電子郵件非常重要,在這些情況下,需要對背景圖像的大小和放置方式進行一定程度的控制。 Gmail 和 Inbox by Gmail 現在都支持兩者,因此沒有理由不嘗試在電子郵件中使用背景圖片。
TWO Digital Marketing 的首席電子郵件開發人員兼 2016 年電子郵件設計大會發言人 Kristian Robinson 深入探討了電子郵件中的背景圖片,如果您有靈感來解決這些問題的話。
誤區 7:所有電子郵件客戶端的電子郵件必須看起來相同。
電子郵件客戶端呈現 HTML 電子郵件的方式略有不同。 電子郵件開發人員並沒有接受這一點,而是試圖在眾多電子郵件客戶端中破解相同的電子郵件。 這是一項非常光榮的任務,但它可能會導致 HTML 代碼臃腫和亂七八糟,這對於管理和保持更新來說可能是一場噩夢。
尋求完美電子郵件的可能不是電子郵件開發人員,而是客戶或其他利益相關者。 然而,電子郵件開發人員有責任教育他們周圍的人了解電子郵件開發的陷阱——為什麼電子郵件客戶端呈現不同,以及為什麼一個電子郵件客戶端中的某些東西與另一個相比高 1 個像素並不重要。
“電子郵件必須達到像素完美的時代已經過去了。” @ericlepetitsf #LitmusLive
- Chad S. White (@chadswhite) 2016 年 8 月 16 日
當嘗試在電子郵件中採用新技術時,這個誤區尤其有害,這些技術可能無法在 100% 的電子郵件客戶端上呈現,例如 Web 字體和背景圖像。 這兩者都是增強電子郵件的絕佳方式。 如果我們不嘗試在電子郵件中採用和試驗新技術,我們作為一個行業將何去何從?
僅僅因為某件事多年來一直以特定的方式完成並不意味著沒有更好的方法來做到這一點。 現在是質疑電子郵件營銷行業幾十年來一直採用的規則和最佳實踐的時候了。
使用 Builder 更快、更輕鬆地編寫電子郵件
使用 Builder 加速您的電子郵件開發工作流程,Builder 是唯一專為電子郵件構建的代碼編輯器。 而且是免費的!
開始使用 Builder →

