作者 | s0.rumi

譯者 | 核子可樂

策劃 | 丁曉昀

首先，如果大家點進來的原因是厭煩了開發(fā)郵件系統(tǒng)，請允許我先對各位的悲慘遭遇表達最誠摯的慰問。

說說結(jié)論，我認為郵件系統(tǒng)的開發(fā)可以說是能在筆記本電腦上完成的、最惡心的工作，沒有之一。我們做的一切似乎都沒有意義，只能像瘋子一樣反復(fù)測試一切，那種感覺跟清理浴室地板上莫名其妙的頑固污漬倒有幾分相似。

總之，希望文章接下來的內(nèi)容能幫大家厘清整個混亂的局面，提供一點有用的建議，特別是讓您在絕望中找到一絲活下去的勇氣。

郵件開發(fā)是干啥的？

理論上講，郵件系統(tǒng)的開發(fā)其實跟網(wǎng)站開發(fā)應(yīng)該比較相似。電子郵件在本質(zhì)上只是個 HTML 文檔，跟網(wǎng)頁一樣，只不過是在郵件客戶端、面非網(wǎng)絡(luò)瀏覽器中呈現(xiàn)視覺效果。但除此之外，二者都能渲染，也就是把 HTML 代碼轉(zhuǎn)換成文本、圖形和圖像——即內(nèi)容的可視化。

其實在 2005 年那會，網(wǎng)站和郵件系統(tǒng)的開發(fā)其實非常相似。瀏覽器和郵件客戶端會以幾乎相同的方式呈現(xiàn) HTML，而且功能也相差不大。但是，盡管 Web 標(biāo)準(zhǔn)不斷發(fā)展且持續(xù)入駐網(wǎng)絡(luò)瀏覽器，但郵件客戶端這頭卻似乎陷入了時?！两駸o甚變化。

如今，我們在開發(fā)網(wǎng)站時可以支持各種酷炫且高效的功能，比如網(wǎng)格、Flexbox、夜晚模式、過渡，而且所有主要瀏覽器都能兼容。但另一方面，這些功能在郵件客戶端中則分以下三種情況：

所以，如果大家希望一定比例的用戶（至少得有 95% 吧）能按預(yù)期查看郵件內(nèi)容，那就只能堅持使用最基本的 HTML 和 CSS 功能。而且即使這樣，成功率也不是 100%……

而且更離奇的是，如今 Web 開發(fā)中最糟糕的實踐竟然仍是郵件開發(fā)中的最佳實踐。下面，就讓我們一探究竟。

首先，如果大家點進來的原因是厭煩了開發(fā)郵件系統(tǒng)，請允許我先對各位的悲慘遭遇表達最誠摯的慰問。

說說結(jié)論，我認為郵件系統(tǒng)的開發(fā)可以說是能在筆記本電腦上完成的、最惡心的工作，沒有之一。我們做的一切似乎都沒有意義，只能像瘋子一樣反復(fù)測試一切，那種感覺跟清理浴室地板上莫名其妙的頑固污漬倒有幾分相似。

總之，希望文章接下來的內(nèi)容能幫大家厘清整個混亂的局面，提供一點有用的建議，特別是讓您在絕望中找到一絲活下去的勇氣。

為什么要用 元素?

展開全文

郵件開發(fā)最讓人頭痛，當(dāng)數(shù)其中大量使用到 table 元素，以及永無止境的和字符串。但是，為什么會這樣？

根據(jù)相關(guān)文獻的解釋，微軟 Outlook 使用著與 Word 相同的渲染引擎。也就是說，在 Outlook 中打開電子郵件基本上相當(dāng)于在 Word 中打開文檔，所以我們得先擺正思路——手頭開發(fā)的并不是電子郵件，而是 Word 文檔。

有朋友可能會想，“不會吧，Word 里可沒有多少布局和樣式工具……”說得沒錯！但它有 table，而且只有 table。所以任何想要正確實現(xiàn)可視化的內(nèi)容都必須是 table。沒有其他辦法了，請大家收下這份表格大禮。

為了證明這一點，以下是蘋果發(fā)送的現(xiàn)代電子郵件被粘貼進微軟 Word 2013 后的樣子：

微軟 Word 2013 中打開的蘋果發(fā)票郵件

神奇吧，這格式多么規(guī)整。而之所以能這么規(guī)整，是因為郵件的 HTML 中包含 75 個和 122 個。看看 HTML 格式，就知道內(nèi)容有多亂了。

為什么要使用內(nèi)聯(lián)樣式？

跟常規(guī) HTML 文檔一樣，電子郵件也可以具有 CSS 樣式。如果各位朋友足夠理智，肯定會想到把它們放在文檔的標(biāo)記當(dāng)中。根據(jù)“如何開發(fā)郵件……”支持頁面中的和部分的說明，這種處理方式能讓樣式得到良好渲染。

我們可以選擇“正確的方式”，也就是發(fā)送郵件、打開郵件，然后發(fā)現(xiàn)它的呈現(xiàn)效果跟預(yù)期一致。但問題是用戶不只會接收郵件，還會撰寫自己的郵件，甚至進一步再做轉(zhuǎn)發(fā)。

那在轉(zhuǎn)發(fā)電子郵件時，具體會發(fā)生什么？根據(jù) Stack Overflow 上的回答，簡單來講，中的所有內(nèi)容都會被刪除。就是說我們向其中添加的任何新式，都會被 Gmail 無情拋棄。

唯一不會被刪除的樣式就只有內(nèi)聯(lián)樣式。因此，如果希望電子郵件在轉(zhuǎn)發(fā)之后仍然正常顯示，那就只能使用內(nèi)聯(lián)樣式。

以下是我轉(zhuǎn)發(fā)的蘋果通知郵件：

在 Gmail 中渲染得到的轉(zhuǎn)發(fā)郵件

看著沒什么毛病，對吧？那是因為其中用到了 40 個內(nèi)聯(lián)樣式屬性。不信？大家可以看看這封郵件的 HTML 代碼證明我沒說謊：https://dodov.dev/blog/why-does-email-development-have-to-suck/email-inline-styles.html

下面我們刪掉內(nèi)聯(lián)樣式，看看更新之后的 HTML。在瀏覽器端，二者的顯示效果幾乎相同，因為內(nèi)聯(lián)樣式所提供的樣式會被復(fù)制到當(dāng)中作為后備。但因為轉(zhuǎn)發(fā)郵件時這些樣式會被刪除，所以我們的樣式就徹底消失了：

Gmail 中渲染的、不帶內(nèi)聯(lián)樣式的轉(zhuǎn)發(fā)郵件

可以看到，標(biāo)題、頁腳、間距全都是一團糟……這顯然不對勁，但至少還有個合乎邏輯的理由——保障安全。電子郵件客戶端在渲染 HTML 之前，會對其進行預(yù)處理以保證安全，樣式也是這樣被丟掉的。

如果大家希望自己的郵件在轉(zhuǎn)發(fā)時看著能有點章法，那就必須拿起內(nèi)聯(lián)樣式的“顏料瓶”沖著 CSS 之墻拼命噴灑。

顏色反轉(zhuǎn)

在開發(fā)網(wǎng)站的時候，我們會用 Prefers-Scheme 來檢測用戶是否在 DAMB 模式下查看，并相應(yīng)更改當(dāng)前頁面的調(diào)色板。您猜怎么著？大多數(shù)電子郵件客戶端還不支持這項功能。時間已經(jīng)過去了 20 年，Apple Mail 等少數(shù)客戶端倒是支持，但 Gmail 卻采用了另一種不同的方法……

在谷歌看來，一切問題說到底都是概率論問題。只要在數(shù)學(xué)上具備可行性，那就可以完全不管少數(shù)情況下的怪異效果，這就免去了重新設(shè)計調(diào)色板和其他顏色的麻煩。

所以在夜晚模式下，Gmail 會簡單將郵件中的所有顏色反轉(zhuǎn)——包括背景、邊框和文本顏色，如下圖所示：

iOS 版本的 Gmail 客戶端，會在夜晚模式時直接將顏色反轉(zhuǎn)

可悲的是，這事我們防不勝防、幾乎沒辦法做預(yù)先控制。唯一的辦法就是盡量揀選那些在反轉(zhuǎn)之后效果仍然不錯的配色，保證圖像在常規(guī)和反轉(zhuǎn)配色時都有過得去的觀感……這事不容易，大家多留點時間吧。

全寬內(nèi)容

在移動設(shè)備上，我們可能需要讓內(nèi)容從一端顯示到另一端，正常的網(wǎng)站也都是這么顯示的。大多數(shù)移動郵件客戶端也都支持這種方案，除了……Gmail。

Gmail 在每封郵件的側(cè)面，都放置了一塊莫名其妙的 16 像素空白。

Apple Mail 和 Gmail 的側(cè)邊留白比較

我們沒法去掉這塊留白。查看邊距？已經(jīng)是 0 了。填充？是 0。而且!important 已經(jīng)全部應(yīng)用過了。反正就是解決不了，你既檢測不到它、也沒法做進一步處理。忍著吧，強迫癥們！

自定義字體

對組織來說，品牌中最重要的組成部分應(yīng)該就是字體了吧，所以我們當(dāng)然想在郵件中也繼續(xù)使用自己的獨特字體……可以嗎？行啊，除了 Gmail。

大多數(shù)電子郵件客戶端都不支持 font-face 字體，但這卻是 Gmail 那邊使用率最高的字體。

Stack Overflow 發(fā)帖有云，這時候只能使用設(shè)備操作系統(tǒng)提供的本地字體?？傊?，希望各位的品牌多跟 Arial 和 Times New Roman 合作！??

響應(yīng)式圖像

有時候，我們可能需要張臺式機壁紙，又想把同樣的畫面也放到移動設(shè)備端。假設(shè)大家已經(jīng)讀過 MDN 的響應(yīng)式圖像指南，就會想到這時應(yīng)該使用 srcset……沒錯，只是郵件客戶端這邊不支持。

為了解決這個問題，我們需要使用多個元素，然后使用媒體查詢把它們隱藏掉。但如果稍不注意，這里也有陷阱：

在 Outlook 中，我們沒辦法直接向元素中添加 display:none。相反，大家需要把它打包進，然后再隱藏掉。具體請參考 display:none 支持表格中的第二條：https://www.caniemail.com/features/css-display-none/#display-none-cite-note-2

而 Gmail 還是在鬧脾氣——它不支持嵌套媒體查詢：https://www.caniemail.com/features/css-at-media/#media-cite-note-1

這里我們只能倒轉(zhuǎn)邏輯，使用兩個單獨的媒體查詢，并依靠 CSS 級聯(lián)來覆蓋掉之前的樣式：

大家可能感受得到，這東西太容易出錯了。

其他小問題

如果大家已經(jīng)讀過這篇文章，但仍不相信開發(fā)電子郵件有多么痛苦，那下面咱們再看點別的小例子：

Outlook 中沒有 table 填充。所以當(dāng)我們在上設(shè)置 CSS 填充時，Outlook 只會對表內(nèi)的所有td元素應(yīng)用填充。但我們至少可以覆蓋掉td元素本身的填充……

大多數(shù)電子郵件客戶端會掃描文本內(nèi)容中的郵件地址和電話號碼，然后把它們轉(zhuǎn)換成看起來很丑的藍色鏈接形式。我們必須把它們打包進標(biāo)簽，并提前標(biāo)記再刪除樣式才能避免這個問題：

如果郵件地址是條指向空 href 的鏈接，那電子郵件客戶端就不會這么處理。在 Outlook 中，列表項目還應(yīng)該用邊距分開，且列表本身需要縮進來保證保留邊距：

最后一個條目須明確設(shè)置 0 邊距，避免底部再留額外的空間。像這樣的問題，還有很多……

有辦法解決嗎？

其實并沒有太好的解決辦法，大家別抱什么希望。所以在跟設(shè)計師合作時，一定要讓他們知道郵件系統(tǒng)的開發(fā)有多么復(fù)雜。告訴他們關(guān)于上述問題的所有細節(jié)，提醒他們在設(shè)計時務(wù)必考慮到這些現(xiàn)實挑戰(zhàn)。

而且即便通過協(xié)商得出了更簡潔的設(shè)計，上述問題也只是得到了緩解，它們?nèi)匀淮嬖?。另外，永遠別以為你可以編寫“干凈的代碼”來讓電子郵件系統(tǒng)始終保持整潔、正常工作?？倳谝恍┑胤?，總會有一些東西就是不起作用。在郵件開發(fā)當(dāng)中，我們唯一能夠確定的就只有這點。

當(dāng)然，MJML 和 React Email 等項目能幫上不少忙。它們會努力把電子郵件客戶端里那些晦澀難懂的怪癖抽象出去。例如，使用 MJML，我們可以忘掉所有復(fù)雜性，讓創(chuàng)建郵件真正變得簡單：

這樣看著就好多了，對吧？用不著再處理一大堆和，MJML 會在后臺幫各位解決?？傊?，歡迎大家多體驗體驗 MJML，并參閱 Josh Comeau 的文章了解這款強大的 HTML 郵件開發(fā)工具：https://www.joshwcomeau.com/react/wonderful-emails-with-mjml-and-mdx/

寫在最后

與符合 Web 標(biāo)準(zhǔn)的網(wǎng)絡(luò)瀏覽器不同，電子郵件客戶端從不給任何人面子。電子郵件開發(fā)之所以很糟糕，就是因為我們在網(wǎng)站構(gòu)建時所使用的很多現(xiàn)代功能在郵件這邊根本不受支持。這就迫使我們只能使用遺留技術(shù)，同時需要考慮各種各樣的極端情況。

電子郵件的構(gòu)建方式跟網(wǎng)站不同，所以千萬別像設(shè)計網(wǎng)站那樣設(shè)計電子郵件。盡量用更簡單的布局，同時配合 MJML 這類項目消除種種令人頭痛的問題。各位，你們一定能挺過去！

最后，別覺得丟臉，沒人能搞定郵件客戶端……沒人可以。

原文鏈接：

https://dodov.dev/blog/why-does-email-development-have-to-suck

相關(guān)閱讀：

前端精準(zhǔn)測試實踐 (https://xie.infoq.cn/article/8f7976ab813eb2897f6feded9)

大前端測試的思考和在語雀的實踐分享 (https://www.infoq.cn/article/2FhPNEatO5kkR7jeIsU5)

Java 后端有哪些不用學(xué)的技術(shù)？勸退。(https://xie.infoq.cn/article/11fae95025c6909f50ba5fdfd)

前后端分離技術(shù)體系 (https://www.infoq.cn/article/mNfTT4UBk5PQl3JpNt6M)

點擊底部閱讀原文訪問 InfoQ 官網(wǎng)，獲取更多精彩內(nèi)容！

今日好文推薦

號稱比 Python 快 68000 倍的 Mojo 語言正式發(fā)布！Rust 能否與之匹敵？

小米一開源項目被批“三無”，項目導(dǎo)師回應(yīng)；Ruby on Rails之父將Type從Turbo框架中移除 | Q資訊

大模型之戰(zhàn)，騰訊來了

面對一家年產(chǎn)值 500 萬噸的焦化廠，這家數(shù)科公司靠什么賦能業(yè)務(wù)？