作者 | s0.rumi

譯者 | 核子可樂(lè)

策劃 | 丁曉昀

首先，如果大家點(diǎn)進(jìn)來(lái)的原因是厭煩了開(kāi)發(fā)郵件系統(tǒng)，請(qǐng)?jiān)试S我先對(duì)各位的悲慘遭遇表達(dá)最誠(chéng)摯的慰問(wèn)。

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

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

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

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

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

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

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

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

首先，如果大家點(diǎn)進(jìn)來(lái)的原因是厭煩了開(kāi)發(fā)郵件系統(tǒng)，請(qǐng)?jiān)试S我先對(duì)各位的悲慘遭遇表達(dá)最誠(chéng)摯的慰問(wèn)。

說(shuō)說(shuō)結(jié)論，我認(rèn)為郵件系統(tǒng)的開(kāi)發(fā)可以說(shuō)是能在筆記本電腦上完成的、最?lèi)盒牡墓ぷ鳎瑳](méi)有之一。我們做的一切似乎都沒(méi)有意義，只能像瘋子一樣反復(fù)測(cè)試一切，那種感覺(jué)跟清理浴室地板上莫名其妙的頑固污漬倒有幾分相似。

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

為什么要用 元素?

展開(kāi)全文

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

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

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

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

微軟 Word 2013 中打開(kāi)的蘋(píng)果發(fā)票郵件

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

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

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

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

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

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

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

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

看著沒(méi)什么毛病，對(duì)吧？那是因?yàn)槠渲杏玫搅?40 個(gè)內(nèi)聯(lián)樣式屬性。不信？大家可以看看這封郵件的 HTML 代碼證明我沒(méi)說(shuō)謊：https://dodov.dev/blog/why-does-email-development-have-to-suck/email-inline-styles.html

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

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

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

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

顏色反轉(zhuǎn)

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

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

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

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

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

全寬內(nèi)容

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

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

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

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

自定義字體

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

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

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

響應(yīng)式圖像

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

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

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

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

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

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

其他小問(wèn)題

如果大家已經(jīng)讀過(guò)這篇文章，但仍不相信開(kāi)發(fā)電子郵件有多么痛苦，那下面咱們?cè)倏袋c(diǎn)別的小例子：

Outlook 中沒(méi)有 table 填充。所以當(dāng)我們?cè)谏显O(shè)置 CSS 填充時(shí)，Outlook 只會(huì)對(duì)表內(nèi)的所有td元素應(yīng)用填充。但我們至少可以覆蓋掉td元素本身的填充……

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

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

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

有辦法解決嗎？

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

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

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

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

寫(xiě)在最后

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

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

最后，別覺(jué)得丟臉，沒(méi)人能搞定郵件客戶(hù)端……沒(méi)人可以。

原文鏈接：

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

相關(guān)閱讀：

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

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

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

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

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

今日好文推薦

號(hào)稱(chēng)比 Python 快 68000 倍的 Mojo 語(yǔ)言正式發(fā)布！Rust 能否與之匹敵？

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

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

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