2017年のHTMLメールを取り巻く環境とモダン開発

HTML・CSS

はじめに：HTMLメールを取り巻く環境

HTMLメール、作ってますか？
マーケティングオートメーションと組み合わせたメールマガジンや、アプリケーションの通知メールなど、多くのプラットフォームがメール配信を行っていますが、その制作で頭を悩ませる担当者は多いことでしょう。
通常のWebサイト制作と同様には行かず、制約の多さ、対応するデバイスの豊富さなど数多の困難が待ち受けています。

総務省から出された平成26年度の情報通信白書の図4-1-1-26によれば、スマートフォンを購入することでGmailなどのメールサービスの利用頻度が増えたという調査結果があります。
他国に比べ携帯キャリアメールの強い日本でも、SIMロック解除の進む今、クラウドメールサービスの台頭は今後も続いていくでしょう。
GmailやiCloudなどのメールサービスでは、メールクライアントに昔ながらのPOP/IMAPなどの設定をせずに済むことが多く、メールアドレスとパスワードで設定が完了し、端末に紐づくこともモバイル端末でのメール利用が進む一つの要因ではないでしょうか。

しかし、クラウドメールサービスの普及や簡単な設定と反対に、HTMLメールでのモバイル対応はそう簡単ではありません。
コーディング上の制約とスピード感、デバイスに応じた見せ方の提供のバランスをとるのは難しいといえるでしょう。

LINEなどのチャットツールやTwitterやFacebookなどのSNSの利用者が増えた今、メールだけでなく各種プラットフォームでのプロモーションも気になるところでしょう。
今すぐにメールがなくなるわけでもなく、いろんなプラットフォームに合わせた施策を行う上で、メール施策の省力化も考えたいですね。

様々な課題を抱えたHTMLメール制作ですが、今回はHTMLメールを取り巻く環境の紹介と、実際にそれに即した（比較的）モダンな開発環境構築を行います。

近年の制作環境

HTMLメールのマークアップは、tableタグを用いたHTML4.01 Transitional / XHTML1.0 Transitionalでの制作がメインです。
未だにflexboxどころかfloatですらまともに使えないほか、linkタグやstyleタグも使えず、CSSは全てインラインでstyle属性に当てる必要がありました。

しかし、現在では多くのメールクライアントがstyleタグに対応し、いくつかのメールクライアントはメディアクエリが使えるようになりました。
2016年の9月にLitmusの記事 Gmail to Support Responsive Email Design でGmailでメディアクエリがサポートされたことが書かれましたが、多くの製作者が「やっとか…」と感じたことでしょう。
GmailやOutlookのための対応は依然として必要ではありますが、プログレッシブ・エンハンスメントを適応することで少々複雑なメールデザインを用いることが出来るようになっています。
（参考リンク：The Ultimate Guide to CSS）

また、モバイル端末をはじめとしたマルチデバイスへの対応はいくつかの手法が知られるようになりました。
TECHSCOREの記事の説明が充実していますので説明はそちらに譲りますが、複雑なメールデザインが可能であるがゆえ、複雑なコーディングが必要となってくることは間違いないでしょう。
（参考リンク：どれ使えばいいの？スマホで見やすいHTMLメールの作り方、4種類（スケーラブル、フルード、レスポンシブ、ハイブリッド））
レスポンシブHTMLメールについてはレスポンシブHTMLメールを作成する際の覚書もぜひご参考にしていただければと思います。

検証環境

更に言えば、検証環境も進化しています。
各種メールクライアントの表示をシミュレートできるLitmusは有料ですが多くの企業が利用していることで知られています。
日本語での文字化けやわずかな表示の違いなどがあるようですが、実環境で全て検証して不具合を修正する労力と比較して、どちらが必要かを選択するとよいでしょう。

ある程度検証環境を自身で用意出来る場合は同じくLitmusから無料で利用できる配信サービスのLitmus PutsMailを利用するのが便利です。
ややタイムラグがある時間帯などありますが、概ね便利に利用可能です。

マークアップとスタイリングの関係

Gmailのモバイル版WebやOutlookは依然としてstyle属性でのスタイリングが必要です。
styleタグでのスタリングやメディアクエリはこれらのメールクライアントを除いたものに適用できると考えます。
style属性でのスタイリングの詳細度が高いため、!importantが頻出することになることに注意してください。

開発環境を考える

では開発環境を整えるにあたって、どのようなことが必要かを考えます。

実際に配信するメールのソースがあるべき状態

適切な文字コードになっていること（iso-2022-jpもしくはUTF-8） ^*1
インデントが除かれていること ^*2
画像のURLが絶対パスで記述されていること
CSSが適切にインライン化（style属性に展開）されていること

1 歴史的経緯からか今でもメールがiso-2022-jpで送信されている場合もありますが、現在ではUTF-8で文字化けするメールクライアントは少なくなっています
2 一部のメールクライアントは文字数や容量制限があること、空白文字による表示崩れがあった経緯からインデントを除くことが通例となっています

これらに留意して、タスクランナーの環境を整備していきましょう。

文字コードの変換

Sublime Textでプラグインを使わないとiso-2022-jpを扱えないなど、一部のエディタでは開発が不可能でしたが、iconvコマンドを使うことでエディタのサポートに関わらず文字コードを変換することが可能です。
gulpを使って開発する場合は、gulp-exec経由でシェルを利用できるでしょう。
残念ながら、gulp-iconvではiso-2022-jpがサポートされていませんので、シェル経由が一番確実かと思います。
gulp-execを使った文字コードの変換はやや面倒になるため、今回は省略しています。

インデントを取り除く

EditorConfigを用いてインデント文字をタブスペースに統一しておきます。
設定の方法はEditorConfigでチームみんなのエディタの設定を揃えるを参考にしてください。
gulp-replaceを使ってタブスペースを空文字に変換すると、インデントが最後に全て除けます。

画像のURLを解決する

開発中にいちいち画像をテストサーバに上げるのは少々大変ですので、ローカルでの開発とテスト配信で参照するURLを変更するのがよいでしょう。
そのため、テンプレートエンジンを用いて画像のURLを設定ファイルなどから渡してあげて、ビルドタスクによって違うURLが吐き出されるようにしてあげます。
Outlook用の条件分岐があるので、pugjsではなくEJSを用いることで解決します。

CSSをインライン化する

CSSファイルをHTMLにinline化するのはgulp-inline-cssを使います。
先述のPutsMailでも同様の処理を行いますが、前処理が理想ですので、こちらを使います。
styleタグの中身をinline化してくれるだけでなく、外部のCSSファイルを渡すことでも行えます。つまり、SCSSやStylusで書いたCSSを利用してinline化することが出来るようになります。ふつうにHTMLページを制作するようにマークアップとスタイリングが出来るわけですね！

確認環境

OutlookやGmailでの確認は実際に送信するかLitmusを用いるしかありませんが、Webブラウザである程度の確認を行って開発を行うほうがスピーディですね。
今回はBrowsersyncを用いてリアルタイムプレビューを行います。

プロジェクトファイルについて

ディレクトリ構成

/
├ images/
├ templates/
│ └ **/index.ejs
├ stylesheets/
│ └ **/styles.scss
├ public/
├ prod/
└ tmp/

上記のようなディレクトリ構成とします。

gulpfile.jsの例

はい、なげえよ、というところだと思います。すみません。
このgulpfileのポイントを以下にまとめますのでそれだけ読めばいいです。

/templates と /stylesheets 以下で同じディレクトリ名を使う
EJS, SCSSのビルド先を /tmp にしている
画像URLを本番用・開発中に分けてEJSビルドタスクに渡す

1についてですが、このプロジェクトでは複数のメールテンプレートを作成することを想定しています。
そのためどのHTMLとどのCSSが対応するかを判別する必要があり、エントリーポイントを限定しています。
/templates/{任意のディレクトリ名}/index.ejs と /stylesheets/{任意のディレクトリ名}/styles.scss が対応します。

2の理由ですが、inline化を行う関係上、全てをストリームで行うことが出来ないためです。
CSSのinline化を行う場合、gulp-inline-cssはHTMLをgulp.srcで取り、外部CSSはオプションのextraCssに文字列で渡します。
EJSファイルをwatchしてEJSのビルドタスクを行った場合はそのファイル名から対応するCSSファイルをfs.readFileすればいいですが、SCSSファイルのwatchの場合は同じストリームから行うことが出来ません。
どちらの変更もwatchしたいので、ここは一旦一時ファイルとして /tmp に書き出してその変更をwatchするようにしています。

3では、リアルタイムプレビュー時にローカルの画像を参照するためです。
本番用ソースは別途ビルドすることが案件では多いため、タスクを分けておきました。
serve-imageタスクは /images に保存した画像をローカル確認用のディレクトリにコピーするだけのタスクです。
冪等性を意識してこの構成にしましたが、バージョン管理を工夫して保存場所を変更してもよいでしょう。

package.jsonのscripts

browserSyncはこちらでエイリアスを作っています。
最近はクセ^*3でgulpで入れないようにしているというだけで、gulpfileでreloadなどをしてもいいでしょう。

*3 よく利用するHerokuではdevDependenciesをビルド時に取得しないため、ビルド時間短縮のためbrowserSyncなどはdevDependenciesに入れるというクセ

ポート番号は自由に変更してください。
$ npm run browser で起動します。
watchタスクなどもエイリアスとして用意しているので、gulp-cliのない環境でも動くようにしています。

さいごに

いかがでしょうか？SCSSとEJSを利用することである程度のモジュール化やCSS設計が可能となりました。
泥臭いテーブルコーディングなども必要ですが、かなりの省力化をはかれたかと思います。

とはいえ、メールクライアントでは検証ツールを使ったデバッグが出来ませんし、Outlookなどはかなり「勘」に頼った修正が必要になることでしょう。
Gmailでもbodyタグがdivに差し替えられたりなど、いろんなトラップが待ち構えています。
gulp-inline-cssがOutlookの条件分岐内はコメントとして認識しているようでinline化を行ってくれない点も面倒なポイントかもしれません。

HTMLのコーディング、ブラウザ同様の標準化は先なように思えますが、引き続きやっていきましょう。
それでは。