wordhtml代碼(html的文檔代碼)
作者 | s0.rumi
譯者 | 核子可樂(lè )
策劃 | 丁曉昀
首先,如果大家點(diǎn)進(jìn)來(lái)的原因是厭煩了開(kāi)發(fā)郵件系統,請允許我先對各位的悲慘遭遇表達最誠摯的慰問(wèn)。
說(shuō)說(shuō)結論,我認為郵件系統的開(kāi)發(fā)可以說(shuō)是能在筆記本電腦上完成的、最?lèi)盒牡墓ぷ?,沒(méi)有之一。我們做的一切似乎都沒(méi)有意義,只能像瘋子一樣反復測試一切,那種感覺(jué)跟清理浴室地板上莫名其妙的頑固污漬倒有幾分相似。
總之,希望文章接下來(lái)的內容能幫大家厘清整個(gè)混亂的局面,提供一點(diǎn)有用的建議,特別是讓您在絕望中找到一絲活下去的勇氣。
郵件開(kāi)發(fā)是干啥的?
理論上講,郵件系統的開(kāi)發(fā)其實(shí)跟網(wǎng)站開(kāi)發(fā)應該比較相似。電子郵件在本質(zhì)上只是個(gè) HTML 文檔,跟網(wǎng)頁(yè)一樣,只不過(guò)是在郵件客戶(hù)端、面非網(wǎng)絡(luò )瀏覽器中呈現視覺(jué)效果。但除此之外,二者都能渲染,也就是把 HTML 代碼轉換成文本、圖形和圖像——即內容的可視化。
其實(shí)在 2005 年那會(huì ),網(wǎng)站和郵件系統的開(kāi)發(fā)其實(shí)非常相似。瀏覽器和郵件客戶(hù)端會(huì )以幾乎相同的方式呈現 HTML,而且功能也相差不大。但是,盡管 Web 標準不斷發(fā)展且持續入駐網(wǎng)絡(luò )瀏覽器,但郵件客戶(hù)端這頭卻似乎陷入了時(shí)?!两駸o(wú)甚變化。
如今,我們在開(kāi)發(fā)網(wǎng)站時(shí)可以支持各種酷炫且高效的功能,比如網(wǎng)格、Flexbox、夜晚模式、過(guò)渡,而且所有主要瀏覽器都能兼容。但另一方面,這些功能在郵件客戶(hù)端中則分以下三種情況:
所以,如果大家希望一定比例的用戶(hù)(至少得有 95% 吧)能按預期查看郵件內容,那就只能堅持使用最基本的 HTML 和 CSS 功能。而且即使這樣,成功率也不是 100%……
而且更離奇的是,如今 Web 開(kāi)發(fā)中最糟糕的實(shí)踐竟然仍是郵件開(kāi)發(fā)中的最佳實(shí)踐。下面,就讓我們一探究竟。
首先,如果大家點(diǎn)進(jìn)來(lái)的原因是厭煩了開(kāi)發(fā)郵件系統,請允許我先對各位的悲慘遭遇表達最誠摯的慰問(wèn)。
說(shuō)說(shuō)結論,我認為郵件系統的開(kāi)發(fā)可以說(shuō)是能在筆記本電腦上完成的、最?lèi)盒牡墓ぷ?,沒(méi)有之一。我們做的一切似乎都沒(méi)有意義,只能像瘋子一樣反復測試一切,那種感覺(jué)跟清理浴室地板上莫名其妙的頑固污漬倒有幾分相似。
總之,希望文章接下來(lái)的內容能幫大家厘清整個(gè)混亂的局面,提供一點(diǎn)有用的建議,特別是讓您在絕望中找到一絲活下去的勇氣。
為什么要用 元素?
展開(kāi)全文
郵件開(kāi)發(fā)最讓人頭痛,當數其中大量使用到 table 元素,以及永無(wú)止境的和字符串。但是,為什么會(huì )這樣?
根據相關(guān)文獻的解釋?zhuān)④?Outlook 使用著(zhù)與 Word 相同的渲染引擎。也就是說(shuō),在 Outlook 中打開(kāi)電子郵件基本上相當于在 Word 中打開(kāi)文檔,所以我們得先擺正思路——手頭開(kāi)發(fā)的并不是電子郵件,而是 Word 文檔。
有朋友可能會(huì )想,“不會(huì )吧,Word 里可沒(méi)有多少布局和樣式工具……”說(shuō)得沒(méi)錯!但它有 table,而且只有 table。所以任何想要正確實(shí)現可視化的內容都必須是 table。沒(méi)有其他辦法了,請大家收下這份表格大禮。
為了證明這一點(diǎn),以下是蘋(píng)果發(fā)送的現代電子郵件被粘貼進(jìn)微軟 Word 2013 后的樣子:
微軟 Word 2013 中打開(kāi)的蘋(píng)果發(fā)票郵件
神奇吧,這格式多么規整。而之所以能這么規整,是因為郵件的 HTML 中包含 75 個(gè)和 122 個(gè)??纯?HTML 格式,就知道內容有多亂了。
為什么要使用內聯(lián)樣式?
跟常規 HTML 文檔一樣,電子郵件也可以具有 CSS 樣式。如果各位朋友足夠理智,肯定會(huì )想到把它們放在文檔的標記當中。根據“如何開(kāi)發(fā)郵件……”支持頁(yè)面中的和部分的說(shuō)明,這種處理方式能讓樣式得到良好渲染。
我們可以選擇“正確的方式”,也就是發(fā)送郵件、打開(kāi)郵件,然后發(fā)現它的呈現效果跟預期一致。但問(wèn)題是用戶(hù)不只會(huì )接收郵件,還會(huì )撰寫(xiě)自己的郵件,甚至進(jìn)一步再做轉發(fā)。
那在轉發(fā)電子郵件時(shí),具體會(huì )發(fā)生什么?根據 Stack Overflow 上的回答,簡(jiǎn)單來(lái)講,中的所有內容都會(huì )被刪除。就是說(shuō)我們向其中添加的任何新式,都會(huì )被 Gmail 無(wú)情拋棄。
唯一不會(huì )被刪除的樣式就只有內聯(lián)樣式。因此,如果希望電子郵件在轉發(fā)之后仍然正常顯示,那就只能使用內聯(lián)樣式。
以下是我轉發(fā)的蘋(píng)果通知郵件:
在 Gmail 中渲染得到的轉發(fā)郵件
看著(zhù)沒(méi)什么毛病,對吧?那是因為其中用到了 40 個(gè)內聯(lián)樣式屬性。不信?大家可以看看這封郵件的 HTML 代碼證明我沒(méi)說(shuō)謊:https://dodov.dev/blog/why-does-email-development-have-to-suck/email-inline-styles.html
下面我們刪掉內聯(lián)樣式,看看更新之后的 HTML。在瀏覽器端,二者的顯示效果幾乎相同,因為內聯(lián)樣式所提供的樣式會(huì )被復制到當中作為后備。但因為轉發(fā)郵件時(shí)這些樣式會(huì )被刪除,所以我們的樣式就徹底消失了:
Gmail 中渲染的、不帶內聯(lián)樣式的轉發(fā)郵件
可以看到,標題、頁(yè)腳、間距全都是一團糟……這顯然不對勁,但至少還有個(gè)合乎邏輯的理由——保障安全。電子郵件客戶(hù)端在渲染 HTML 之前,會(huì )對其進(jìn)行預處理以保證安全,樣式也是這樣被丟掉的。
如果大家希望自己的郵件在轉發(fā)時(shí)看著(zhù)能有點(diǎn)章法,那就必須拿起內聯(lián)樣式的“顏料瓶”沖著(zhù) CSS 之墻拼命噴灑。
顏色反轉
在開(kāi)發(fā)網(wǎng)站的時(shí)候,我們會(huì )用 Prefers-Scheme 來(lái)檢測用戶(hù)是否在 DAMB 模式下查看,并相應更改當前頁(yè)面的調色板。您猜怎么著(zhù)?大多數電子郵件客戶(hù)端還不支持這項功能。時(shí)間已經(jīng)過(guò)去了 20 年,Apple Mail 等少數客戶(hù)端倒是支持,但 Gmail 卻采用了另一種不同的方法……
在谷歌看來(lái),一切問(wèn)題說(shuō)到底都是概率論問(wèn)題。只要在數學(xué)上具備可行性,那就可以完全不管少數情況下的怪異效果,這就免去了重新設計調色板和其他顏色的麻煩。
所以在夜晚模式下,Gmail 會(huì )簡(jiǎn)單將郵件中的所有顏色反轉——包括背景、邊框和文本顏色,如下圖所示:
iOS 版本的 Gmail 客戶(hù)端,會(huì )在夜晚模式時(shí)直接將顏色反轉
可悲的是,這事我們防不勝防、幾乎沒(méi)辦法做預先控制。唯一的辦法就是盡量揀選那些在反轉之后效果仍然不錯的配色,保證圖像在常規和反轉配色時(shí)都有過(guò)得去的觀(guān)感……這事不容易,大家多留點(diǎn)時(shí)間吧。
全寬內容
在移動(dòng)設備上,我們可能需要讓內容從一端顯示到另一端,正常的網(wǎng)站也都是這么顯示的。大多數移動(dòng)郵件客戶(hù)端也都支持這種方案,除了……Gmail。
Gmail 在每封郵件的側面,都放置了一塊莫名其妙的 16 像素空白。
Apple Mail 和 Gmail 的側邊留白比較
我們沒(méi)法去掉這塊留白。查看邊距?已經(jīng)是 0 了。填充?是 0。而且!important 已經(jīng)全部應用過(guò)了。反正就是解決不了,你既檢測不到它、也沒(méi)法做進(jìn)一步處理。忍著(zhù)吧,強迫癥們!
自定義字體
對組織來(lái)說(shuō),品牌中最重要的組成部分應該就是字體了吧,所以我們當然想在郵件中也繼續使用自己的獨特字體……可以嗎?行啊,除了 Gmail。
大多數電子郵件客戶(hù)端都不支持 font-face 字體,但這卻是 Gmail 那邊使用率最高的字體。
Stack Overflow 發(fā)帖有云,這時(shí)候只能使用設備操作系統提供的本地字體??傊?,希望各位的品牌多跟 Arial 和 Times New Roman 合作!??
響應式圖像
有時(shí)候,我們可能需要張臺式機壁紙,又想把同樣的畫(huà)面也放到移動(dòng)設備端。假設大家已經(jīng)讀過(guò) MDN 的響應式圖像指南,就會(huì )想到這時(shí)應該使用 srcset……沒(méi)錯,只是郵件客戶(hù)端這邊不支持。
為了解決這個(gè)問(wèn)題,我們需要使用多個(gè)元素,然后使用媒體查詢(xún)把它們隱藏掉。但如果稍不注意,這里也有陷阱:
在 Outlook 中,我們沒(méi)辦法直接向元素中添加 display:none。相反,大家需要把它打包進(jìn),然后再隱藏掉。具體請參考 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
這里我們只能倒轉邏輯,使用兩個(gè)單獨的媒體查詢(xún),并依靠 CSS 級聯(lián)來(lái)覆蓋掉之前的樣式:
大家可能感受得到,這東西太容易出錯了。
其他小問(wèn)題
如果大家已經(jīng)讀過(guò)這篇文章,但仍不相信開(kāi)發(fā)電子郵件有多么痛苦,那下面咱們再看點(diǎn)別的小例子:
Outlook 中沒(méi)有 table 填充。所以當我們在上設置 CSS 填充時(shí),Outlook 只會(huì )對表內的所有td元素應用填充。但我們至少可以覆蓋掉td元素本身的填充……
大多數電子郵件客戶(hù)端會(huì )掃描文本內容中的郵件地址和電話(huà)號碼,然后把它們轉換成看起來(lái)很丑的藍色鏈接形式。我們必須把它們打包進(jìn)標簽,并提前標記再刪除樣式才能避免這個(gè)問(wèn)題:
如果郵件地址是條指向空 href 的鏈接,那電子郵件客戶(hù)端就不會(huì )這么處理。在 Outlook 中,列表項目還應該用邊距分開(kāi),且列表本身需要縮進(jìn)來(lái)保證保留邊距:
最后一個(gè)條目須明確設置 0 邊距,避免底部再留額外的空間。像這樣的問(wèn)題,還有很多……
有辦法解決嗎?
其實(shí)并沒(méi)有太好的解決辦法,大家別抱什么希望。所以在跟設計師合作時(shí),一定要讓他們知道郵件系統的開(kāi)發(fā)有多么復雜。告訴他們關(guān)于上述問(wèn)題的所有細節,提醒他們在設計時(shí)務(wù)必考慮到這些現實(shí)挑戰。
而且即便通過(guò)協(xié)商得出了更簡(jiǎn)潔的設計,上述問(wèn)題也只是得到了緩解,它們仍然存在。另外,永遠別以為你可以編寫(xiě)“干凈的代碼”來(lái)讓電子郵件系統始終保持整潔、正常工作??倳?huì )在一些地方,總會(huì )有一些東西就是不起作用。在郵件開(kāi)發(fā)當中,我們唯一能夠確定的就只有這點(diǎn)。
當然,MJML 和 React Email 等項目能幫上不少忙。它們會(huì )努力把電子郵件客戶(hù)端里那些晦澀難懂的怪癖抽象出去。例如,使用 MJML,我們可以忘掉所有復雜性,讓創(chuàng )建郵件真正變得簡(jiǎn)單:
這樣看著(zhù)就好多了,對吧?用不著(zhù)再處理一大堆和,MJML 會(huì )在后臺幫各位解決??傊?,歡迎大家多體驗體驗 MJML,并參閱 Josh Comeau 的文章了解這款強大的 HTML 郵件開(kāi)發(fā)工具:https://www.joshwcomeau.com/react/wonderful-emails-with-mjml-and-mdx/
寫(xiě)在最后
與符合 Web 標準的網(wǎng)絡(luò )瀏覽器不同,電子郵件客戶(hù)端從不給任何人面子。電子郵件開(kāi)發(fā)之所以很糟糕,就是因為我們在網(wǎng)站構建時(shí)所使用的很多現代功能在郵件這邊根本不受支持。這就迫使我們只能使用遺留技術(shù),同時(shí)需要考慮各種各樣的極端情況。
電子郵件的構建方式跟網(wǎng)站不同,所以千萬(wàn)別像設計網(wǎng)站那樣設計電子郵件。盡量用更簡(jiǎn)單的布局,同時(shí)配合 MJML 這類(lèi)項目消除種種令人頭痛的問(wèn)題。各位,你們一定能挺過(guò)去!
最后,別覺(jué)得丟臉,沒(méi)人能搞定郵件客戶(hù)端……沒(méi)人可以。
原文鏈接:
https://dodov.dev/blog/why-does-email-development-have-to-suck
相關(guān)閱讀:
前端精準測試實(shí)踐 (https://xie.infoq.cn/article/8f7976ab813eb2897f6feded9)
大前端測試的思考和在語(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),獲取更多精彩內容!
今日好文推薦
號稱(chēng)比 Python 快 68000 倍的 Mojo 語(yǔ)言正式發(fā)布!Rust 能否與之匹敵?
小米一開(kāi)源項目被批“三無(wú)”,項目導師回應;Ruby on Rails之父將Type從Turbo框架中移除 | Q資訊
大模型之戰,騰訊來(lái)了
面對一家年產(chǎn)值 500 萬(wàn)噸的焦化廠(chǎng),這家數科公司靠什么賦能業(yè)務(wù)?
掃描二維碼推送至手機訪(fǎng)問(wèn)。
版權聲明:本文由飛速云SEO網(wǎng)絡(luò )優(yōu)化推廣發(fā)布,如需轉載請注明出處。