HTMLメールの最近の実装方法を解説、tableは不要になりました

Post on:2023年6月1日

HTMLメールの実装で「tableか、、、」とため息をついていた人に朗報です。
tableを使用しなくてはいけなかった理由はWindows上のOutlookだったのですが、新しいOutlookではレンダリングエンジンがEdgeに切り替わります。これにより、tableによる実装は不要になります。

HTMLメールの最近の実装方法を解説します。

HTMLメールの最近の実装方法を解説、tableは不要になりました

Modern HTML email (tables no longer required)
by Ollie Williams

下記は各ポイントを意訳したものです。
※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。

はじめに

MailChimpによるHTMLメール実装のベストプラクティスで最初のポイントは「table要素ですべての構造をコード化する」とあります。また、HTMLメールテンプレートのCerberusによるベストプラクティスでは「疑わしい場合は別のtableをネストする」とあります。

これらによると、HTMLメールはfloatベースのレイアウトにさえも進化していません。HTMLメールのコーディングは回避策、ハック、廃止された非推奨のHTML要素の集合体と言えます。

これは長い間、矛盾に満ちた開拓時代であり、対応するには難解な知識が必要です。Can I Email（Can I Useに相当するメール版）のサポート一覧を見ると、電子メールのクライアント間で大きな相違があることがよく分かります。Apple Mail, Hey, Fastmail, Outlook for Mac, Proton Mail, Mail.ru向けにHTMLメールを作成することは、モダンなWebページをコーディングすることとそれほど代わりません。それに対してYahoo Mailは背景のグラデーションでさえサポートされていません。今日までHTMLメールの実装を苦しめていたのは、他のどのクライアントよりもWindows上のOutlookだったのです。

Windows上のOutlookは、電子メールクライアントのInternet Explorerのような存在でした。Windows上のOutlookデスクトップアプリとWindowsメールアプリがあるため、デベロッパーはHTMLのtableを使用してHTMLメールを実装しなければならない唯一の理由でした。ちなみに、macOS, iOS, AndroidのOutlookアプリは問題ありません。

Windows上のOutlookのおかげで、HTMLメールのコードは通常下記のようになります。

tableの中にtableがあり、そのtableの中にもtableがあり、、、

ここで、朗報があります！
Outlookに苦しめられていたのは過去のものになります、ついにそのときがきました。新しいOutlookでは、レンダリングエンジンがMicrosoft WordからEdgeに切り替わります。新しいOutlookアプリのCSS機能のサポートは、outlook.comのものと同等（Can I Email）になり、これは大きな進歩です。

Windows上のOutlookはもっとも古く、もっとも便利なCSSプロパティの1つであるbackground-imageをサポートしていませんでした。もちろん、float, flex, border-radius, opacity, outline, z-indexなど、多くの機能もサポートされていませんでした。しかも、width, margin, display: none;のサポートでさえ、部分的にバグがありました。

Outlookのシェア率は月日の経過とともに減少していますが、依然として3番目に人気のある電子メールのクライアントです。Outlookは本当にひどいものでしたが、無視するには大きすぎました。

電子メールの各クライアントのシェア率

Email Client Market Share

上記はLitmus Email Analyticsによる電子メールの各クライアントのシェア率で、13億件以上を母数に2023年5月時点のものです。

今後も使い続けるユーザーもいると思いますが、デベロッパーにとってはできるだけ早く移行するための説得力のある理由がいくかあります。

GmailはHTMLのサイズ制限が102Kbまでとなっており、それ以降は「クリップしたメッセージ」というテキストとメールの残り部分を表示するためのリンクが表示されます。言うまでもなく、これは優れたユーザーエクスペリエンスではなく、ほとんどのユーザーはリンクをクリックしないので、HTMLメールのすべては多くのユーザーに表示されることはありません。tableでレイアウトされたHTMLメールのコードは大量にかさばるので、それを超えるようにすれば、Gmailでメッセージがクリップされることを防ぐことができます。その一方、最新のHTMLメールのコードには入れ子になったtableが非常に密集しているため、Outlookがクラッシュすることがあります。

HTMLメールのスピードは、フロントエンドのWeb開発のように特に重視されることはありませんが、クリックスルー率やブランドの認知度に何らかの影響を与えることは間違いありません。Windows上のレガシーOutlookはWebP画像をサポートしていない唯一のクライアントであり（AVIFでさえほとんどのクライアントでサポートされています）、picture要素が一般的にサポート不足していることから、Outlookに対応するとパフォーマンスが低下します。

HTMLメールの実装でもっとも頭を悩ませている問題

Litmus（人気のある電子メールのテストツール）は、メールクライアントの市場シェアを示す統計データを毎月公表しています。

Apple Mailはもっとも多く使用されているクライアントです。Appleのすべてのデバイスにデフォルトで搭載されており、ありがたいことにどの電子メールクライアントよりもCSSをもっともよくサポートしています。Can I Emailでカバーされている253個のHTMLとCSSのプロパティのうち、Apple Mailは234個（92%）をサポートしています。一方、iOSのGmailは92個（36%）しかサポートしていません。

下記は、Can I Emailによるスコアボードを要約したもので、より人気のあるクライアントのみを表示しています。

サイトのキャプチャ

Email Client Support Scoreboard -Can I Email

tableによるレイアウトが廃止されたからといって、電子メールが今日の世界に完全に導入されるわけではありません。クライアント間での完全サポートがまだ不足しているCSSのプロパティや値がたくさんあります。

  • background-imageの線形、放射状、円錐状のグラデーション
  • box-shadow
  • CSS GridとFlexboxのアイテム間を調整するgap, column-gap, row-gap
  • grid,
  • align-items, justify-content
  • object-fit
  • relative, absoluteによる配置

現在、対応するのがもっとも難しいクライアントはGmailです。Gmailアプリは@gmail.comのメールアドレスを使用しているか、サードパーティのアドレス（@outlook.com, yahoo.comなど）を使用しているかによって異なるレベルのCSSをサポートします。サードパーティのアドレスだと、CSSのサポートレベルは最低限です。このようなユーザーは少数派ですが、たとえプログレッシブエンハンスメントの考え方しか持たないとしても、対応する価値はあると思います。

今日、HTMLメールをどのように実装すべきか？

それが問題です。HTMLのtableの枠を超えるのであれば、今日のHTMLメールにおいてHTMLとCSSで何ができるかを確認する必要があります。

まず最初に、divを使用する

標準的なdiv要素を使用する場合は問題ありませんが、メールのクライアントが他のすべてのHTMLもサポートしているとは限りません。以下のHTML要素は、すべてのメールクライアントでサポートされていないため、代わりに<div>を使用する必要があります。

  • <article>
  • <aside>
  • <details>
  • <figcaption>
  • <figure>
  • <footer>
  • <header>
  • <main>
  • <mark>
  • <nav>
  • <section>
  • <summary>
  • <time>

見出し要素（<h1>, <h2>）、パラグラフ（<p>）、リスト（<ul>, <li>）など、その他のHTML要素はどのクライアントにもサポートされています。

インラインのCSSはまだ（ちょっとだけ）必要です

メールクライアントのほとんどは<style>タグをサポートしていますが、いくつか例外があります。Gmailのデスクトップ版でHTMLメールを転送すると、転送されたメールはすべての<style>タグが削除されます。Gmailアプリで使用されるサードパーティのメールアカウントも<style>タグをサポートしていません。

<style>タグはメディアクエリや:hoverや@font-faceなどを定義するために必要です（これらはインラインで定義できないため）。それ以外のスタイルについては可能な限り幅広いユーザーに対応するためにインラインのCSSを引き続き使用することをお勧めします。

電子メール用のAMPについて

AMP（Accelerated Mobile Pages）は、Webに起きた最悪の出来事の一つでした。2018年にはWeb標準とフロントエンド開発の世界で活躍する何百人の著名人が巨大な権力を利用して企業にこの技術の採用を強要したGoogleを批判する書簡に署名しました。

Terence Eden氏は、AMP諮問委員会の会議で次のように報告しました。

パブリッシャーがAMPを好まないという話を耳にしました。なぜなら、そうしないと検索結果の一番上に表示されるGoogleのニュースのカルーセルにアクセスできないため、ユーザーはそれを使用しなければならないと感じています。

Web用のAMPが悪い評判を集めたのは当然ですが、メール用のAMPはその存在を正当化する要素があります。

動的なメール

すべてのメールクライアントは、HTMLメールにおいてJavaScriptをブロックしています。AMPは任意のスクリプトを実行する代わりに、限定的な代替手段を提供します。これにより、これまでは不可能だった新しい可能性が開かれます。

メールの返信をせずに、イベントの出欠確認をしたことがありますか？ AMPによって受信トレイで出欠・コメントへの返信・カタログ閲覧が可能になりました。

AMPを使用すると、ユーザーはリンクをクリックすることなく、メール内でアクションを実行できます。

AMPメールを送信する

AMPメールを実際に送信するには、メールのプロバイダがAMPに対応している必要があります。かなり多くのプロバイダが対応（Can I Email）していますが、すべてではありません。また、YahooとGoogleにも登録する必要があります。

AMPメールを受信するには、受信者がYahoo、Gmail、AOL、Mail.ruのいずれかを使用している必要があります。AMP版とHTML版の両方のメールを送信する必要があります。HTML版は、Apple Mail、OutlookなどAMPをサポートしていない受信ボックスを使用している人のために必要です。

AMPが可能にするモダンなスタイリング

AMPのインタラクティブな機能が主なセールスポイントとして紹介されていますが、AMPの最大の特徴はその一貫性です。電子メール用のAMPは、CSSの機能を明確に指定して実装しています。AMPで作成したメールには最新のCSSやマークアップを使用でき、GmailやYahooなどAMPをサポートするあらゆるクライアントで同じように表示されることが比較的確実になっています。電子メールのQAをしなければならない人にとって、これは大きな問題です。HTMLメールのテストはクライアントによってさまざまな矛盾があるため、業界全体で取り組んでいることなのです。AMPの大きな魅力の一つは、その問題を回避できることです。

メールクライアントはセキュリティの観点から、サニタイザーを使用して特定のコードを削除します。絶対位置やz-indexなどのCSSを許可すると、送信者がGmailのUIにコンテンツをオーバーレイできる可能性があります。また、ほとんどのメールクライアントはiframeをレンダリングしませんが、AMPメールは常にifame内でレンダリングされます。これによりセキュリティ上の考慮事項が変更されるため、Googleや他のクライアントはメールから何を削除するかについて寛容になることができます（ただし、GmailのCSSサニタイザーはしばらく更新されていないのに対して、AMPは新しく更新されたという事情もあります）。そのため、HTMLとCSSの扱いがもっとも悪いメールクライアントであるYahooとGmailが、AMPで最新のマークアップとスタイルをレンダリングできるようになりました。

たとえば、flex-wrap, align-items, justify-contentをサポートしていない一般的なクライアントは、YahooとGmailだけです。AMPのインタラクティブな機能に関係なく、最新のCSSを採用する方法としてAMPを利用することも可能です。2種類のメールをコーディングするのは面倒に思えるかもしれませんが、有効なHTMLメールのコードのほとんどは有効なAMPのコードと同じです。しかし、いくつか小さな違いがあります（!importantの使用は許可されておらず、AMPでは<img>の代わりに<amp-img>が使用されます）。

Parcel（HTMLメール用に設計されたコードエディタ）には、プロセスを自動化する「HTMLからAMPを生成する」ボタンがあります。手作業がすこし必要ですが、うまく機能します。HTMLメールで作業するときは、CSSを手動でインライン化し、メディアクエリ内の!importantで上書きする必要があるかを把握します。ParcelはAMPが有効ではないため、すべての!important宣言を削除します。これは、これらの宣言がAMPでは有効ではないためで、メディアクエリ内のコードは何も機能しなくなります。インラインを手動で取得し、<head>内の<style>ブロックに移動する必要があります。

AMPにはいくつかの欠点があります

これは正しい方向への一歩ですが、まだ完璧とは言えません。

  • AMPメールは30日間だけ有効です。その後は、通常のHTMLメールの表示に戻ります。ほとんどの人はすぐにメールを読むか、読まないかのどちらかですが、それでも理想的ではありません。
  • AMPメールを転送すると、たとえAMPをサポートしている受信トレイ（GmailやYahooなど）であっても、受信者は標準のHTML版のみを受け取ることになります。
  • AMPはインラインのSVGをサポートしていません。
  • AMPメールは@font-faceをサポートしていないため、受信者のシステム上のフォントを使用することに制限されます。
  • AMPはCSSトランジションをサポートしますが、CSSアニメーション (@keyframes) はサポートしていません。
  • ::before, ::afterの擬似要素はサポートしていません。

電子メール用のAMPはやや停滞しているように見えますが、無視すべきではありません。Googleは自社サービスの開発を中止することで有名ですが、電子メール用のAMPについて私は心配していません。Googleの自社サービス（Googleカレンダーなど）のユーザーエクスペリエンスはAMPの恩恵を受けています。AMPを廃止してしまうと、自社サービスに悪影響を及ぼす可能性があります。

終わりに

電子メールの世界はゆっくりとした動きですが、正しい方向に向かっています。また最近では、クライアント間の一貫性を高めるためにEmail Markup Consortiumが設立されました。成功することを願います。

この記事の編集を担当したGeoff Grahamに感謝します。

sponsors

top of page

©2024 coliss