ページ離脱防止機能を実装する
beforeunloadイベントを利用して実装
先日、とあるCMSの管理画面にて、記事入力途中・画像入力途中でのページ離脱防止機能の実装を行いました。
要件としては、Google Chromeのみで、離脱時にアラートを表示するというものでした。
ページ遷移前に発火するbeforeunloadというイベントを利用した実装を行なったのですが、僕自身このイベントに真正面から向かい合って実装に取り組んだことがなかったので、ところどころ小さな落とし穴があったため、その備忘録としてこの記事を書かせていただきます。
ちなみに、beforeunloadイベントの詳細はこちらを参照ください。
テストは必ず入力フィールドのあるページで
とても基本的な落とし穴ですがテストは必ず入力フィールドのあるページで行なってください。
Google Chrome公式でもRequire user gesture for beforeunload dialogs
と記載されています。
文字入力や画面になんらかのアクションがないと、離脱防止は動きません。開いて何もせずに「戻る」を押してしまうと、何も起きずに離脱してしまいます。
https://donow.jp/skillup/?p=3271
僕はこれに気づかず、入力フィールドのないページでなんどもブラウザバックボタンを押しては、何も起こらないことに首をひねってしまいました。
window.onbeforeunloadイベントプロパティに関数を登録
イベントハンドリングにはaddEventListenerメソッドやonメソッド(jQuery)などの方法がありますが、後述する理由によりwindow.onbeforeunloadイベントプロパティに関数を登録する方法を採用しています。
Chromeとそれ以外のブラウザとで若干方法が異なりますが、必ずreturnをするかe.returnValueを指定してください。
同時に指定することも可能ですが、とにかくreturnをしないと離脱防止は動きません。
window.onbeforeunload = function(e){ return "このページを離れますか?"; // Google Chrome以外 e.returnValue = "このページを離れますか?"; // Google Chrome }
また、Google Chromeのみ、カスタムメッセージ(つまりreturnValueやreturnに渡している文字列)は設定できず、ブラウザデフォルトのメッセージしか表示ができない仕様になっているそうです。
この件についてはこちらの記事をご参照ください。
フォームのsubmit時は無効にする
beforeunloadイベントはすべてのページ遷移時に発火するので、当然ながらフォームのsubmit時も発火します。
ユーザビリティのため、フォームのsubmit時は無効にするのが好ましいでしょう。
方法としてはフォームのsubmit時にbeforeunloadイベントとそれに対応する関数との紐づけを削除するのですが、removeEventListenerメソッドでもoffメソッド(jQuery)でもその紐づけを切ることができませんでした。
そこで、window.onbeforeunloadプロパティにnullを代入することで対応しました。
$('form').on('submit', function(e){ e.preventDefault(); window.onbeforeunload = null; // 関数を削除 var $this = $(this); var isPassed = confirm('記事を登録しますか?'); if (isPassed) $this.submit(); });
記事の登録時には確認ダイアログを表示してほしいとの要件であったため、このような実装になっています。
これらをまとめると、以下のようになります。
window.onbeforeunload = function(e){ return "このページを離れますか?"; // Google Chrome以外 e.returnValue = "このページを離れますか?"; // Google Chrome } $('form').on('submit', function(e){ e.preventDefault(); window.onbeforeunload = null; // 関数を削除 var $this = $(this); var isPassed = confirm('記事を登録しますか?'); if (isPassed) $this.submit(); });
ファイル名一覧から新規ファイルを作成
例えば、以下のようなテキストファイル(filelist.txt)があるとします。
aaa.html bbb.html ccc.html ddd.html eee.html
このリストをもとに新規ファイルを作成するには、毎回無題の新規ファイルを作成しそのたびにリネームをするという非効率な作業が必要になりますが、 xargsというコマンドを利用することで短時間で解決することができます。
cat filelist.txt | xargs -n 1 touch
xargsコマンドの使い方は以下を参照ください。
今回のような使い方のほかに、特定のファイルを検索し、そのファイルに対してリネームや削除を行うなどといったケースでも利用されます。
また、上記の例ではシンプルに空のファイルを作成するのみですが、cpコマンドのように引数を複数とる場合は、「-Jオプション」または「-iオプション」を使用して任意の文字列に置換をします。
下記は、新規作成ではなくテンプレートファイル(__temp__.html)をコピーしつつ、そのファイル名をファイルリストから命名するコマンドになります。
このとき、ファイルリストから取得したファイル名は「%」という文字列に置換されています。
cat filelist.txt | xargs -n 1 -J% cp __temp__.html %
Canvasでの認証エラー
toDataURL, getImageDataなど、Canvasで画像のピクセルデータを取得したり保持しているピクセルデータを出力する際、画像を格納しているディレクトリにBASIC認証がかかっていると認証エラーを起こします。
その際はCanvasで操作するimageオブジェクトにcrossorigin 属性を指定します。
(変数imageには画像のパスを与えられたimageオブジェクトが格納されているとします)
image.crssorigin = "use-credentials";
基本的には同一ドメイン間での画像の操作を前提としているため、このような一手間が必要になるそうです。
ちなみに単純に別ドメインの画像を操作する際は以下で可能になります。
image.crssorigin = "annonymus";
この属性についての詳細は下記をご参照ください。
Photoshopのような画像合成はフロントエンドでどこまで可能か
モダンブラウザに限定すれば実装は容易
Photoshopには描画モードという機能があり、例えば「乗算」「オーバーレイ」「スクリーン」などの描画モードを用いることでデザインの表現を大きく広げることが可能になります。
これまで描画モードを利用した表現はブラウザで再現することはできなかったため、たとえば描画モードの設定値に若干の修正を加えた時は毎回画像を切り出し直さなければならず、手間がかかっていました。
なぜかというとPhotoshopでの描画モードはいわゆる画像合成そのものであり、これまでのブラウザの技術はそれを実現するほどの水準に達していませんでした。
しかし現在ではブラウザの技術が大幅に進化し、画像合成がCSSまたはJavascriptで行うことができるようになりました。
mix-blend-mode
先に結論から申し上げますと、モダンブラウザに至ってはCSSのみで合成が可能です。
しかも非常に実装は容易です。
CSS3で登場したmix-bled-modeというプロパティを用いることで、Photoshopに用意されている描画モードの多くをカバーできます。
以下は、モノクロ画像と7色のグラデーションを、描画モード「スクリーン」で合成したデモです。
ソースをご覧いただければ、たった一行の指定で合成を実現できることが分かります。
See the Pen Composition Demo - 01 by Shin Imae (@shinimae) on CodePen.
より詳しく知りたい方や、他のブレンドモードのデモをご覧になりたい方は、以下をご参照ください。
記述も簡潔で、実装の垣根がぐんと下がっていますが、残念ながら冒頭で申し上げた通りIE/Edgeはこのプロパティに未対応です。
以下が各ブラウザに置けるmix-blend-modeの対応状況一覧ですが、Edgeですら対応はままならない状況です。
Can I use... Support tables for HTML5, CSS3, etc
ではIE/Edgeでは合成が無理なのかというと決してそんなことはなく、Canvasを利用するのが最も近道になります
globalCompositOperation
Canvas APIには二つの要素を重ねて描画した際に、その重なり方を制御できるglobalCompositOperationというプロパティが存在します。
こちらは非常に使い勝手がよく、要素を重ねる際にこのプロパティに重なり方を指定する任意の値を代入するだけで、合成をしてくれます。
以下はglobalCompositOperationを用いてスクリーン合成を行なったデモです。
Canvasのスケーリングこそ行なっていますが全体的には比較的シンプルなコードで実装できていることが分ります。
See the Pen Composition Demo - 02 by Shin Imae (@shinimae) on CodePen.
globalCompositOperationのリファレンスを以下にご紹介しますが、こちらを参照いただくとmix-blend-modeと同様の合成方法がAPI側ですでに用意されていることが分ります。
しかし残念なことに、このうちいくつかはIE/Edgeは未対応です。
今回実例に用いたスクリーン合成もその一つですので、上記のデモをIE/Edgeでご覧いただくと合成できずにグラデーションで塗りつぶされてしまいます。
また振り出しに戻ってしまいました。
ビットマップ演算
IEも含めた全ての環境で同様の表示を実現するには、globalCompositOperationが内部的に行なっているビットマップ演算を行うしかありません。
1ピクセルごとの色の情報を取得し、それを操作して新しくイメージデータを生成します。 まさしくPhotoshopの内部で行われていることをそのまま実装する形になります。
ややとっつきにくさがあるかもしれませんが、いくつかのポピュラーな合成アルゴリズムについて下記で解説されています。
合成と聞くととても複雑なことをしているかのようですが、実際のところは二つの色情報を四則演算しているに過ぎず、その実態はとてもシンプルです。 乗算や加算をはじめ(列挙されていませんが)グレースケールやネガポジ反転などは、今回取り上げているスクリーン合成に比べると非常に初歩的なアルゴリズムとなっています。
話を戻して、スクリーン合成のアルゴリズムについても上記で解説がされているため、それを参考に合成した結果が以下になります。
See the Pen Composition Demo - 03 by Shin Imae (@shinimae) on CodePen.
mix-blend-mode対応の判別
@supportsルールが使えるならばとても楽なのですが、例のごとくIE/Edgeが対応していないため、Javascriptにて対応状況を判別する必要があります。
if (typeof window.getComputedStyle(document.body).mixBlendMode !== 'undefined') { // supported. }else{ // not supported. }
出典はこちら。
おわりに
最終的にCanvasによるビットマップ演算という結論に達しましたが、とりわけモバイルブラウザを念頭に入れると、このCanvasを用いたレンダリングがとても高負荷なものであることは言うまでもありません。
前セクションで紹介したmix-blend-modeを利用した実装であればある程度のの負荷にも耐えうるものの、IEを対象に含めると先述したような(決しては容易とは言い難い)ビットマップ演算が必要不可欠なものになることは忘れてはいけません。
ページロード時に一度だけ合成を行う場合はこれで十二分に対応ができますが、例えばグラデーションの開始位置が徐々に変わるなど、合成具合が連続的に変化する場合(つまりms単位でCanvasで合成を繰り返さなければいけない場合)は、環境によってはCanvasの最適化を行なってもなお致命的にパフォーマンスが落ちることがあるので、注意が必要です。
フロントエンドでの画像合成をどこまで実現するか、その対応範囲を制作前に規定する作業はまだしばらく必要になりそうです
Windows環境でWebフォントが崩れる
ブラウザを問わずWindowsでのみ崩れる
Webフォントサービスを利用していた際、Windows環境にてブラウザを問わずフォントが崩れるという現象がありました。
▼Windows環境での表示
▼本来の表示
遠目にはわかりにくいのですが、太字の部分においてWindowsの環境では若干文字のベースラインがずれてしまいガタガタとした表示になっています。
Windowsではフォントによっては滑らかに表示できないという癖があるようです。
そんな時は(本来CSSアニメーションを滑らかにするハックですが)以下のスタイルを指定することで解決します。
transform: rotate(0.1deg)
若干ボケてしまったり、フォントが太って見える場合もありますが、少なくともガタガタとした表示だけは回避することができます。
必要があればユーザーエージェントをもとにWindows環境にのみ上記のスタイルを設定するとベターです。
gulpでSassをコンパイルするとcharset指定が削除される
ファイル中にマルチバイト文字があるか確認
gulp-sassモジュールを利用してsassをコンパイルしていると、以下のようにscssファイル中に文字コードを指定していても削除されてしまうことがあります。
@charset "UTF-8";
scssファイル中にマルチバイト文字があるかどうか確認してください。
どうやらgulp-sassはマルチバイト文字が存在するファイルにのみ文字コード指定を出力するようです。
ですので、コメントに日本語を記入してしまえばこのようなことにはならないのですが、このような理由で運用上ルールを追加するのはナンセンスです。
そこで、gulpの他モジュールの力を借りてこれを解決します。
使用するのはまず、gulp-headerモジュールです。
このモジュールは対象となるファイルの先頭に任意の文字列を挿入する機能を持っています。
こちらを用いて、以下のようなタスクファイルを作成します。
var gulp = require('gulp'); var sass = require('gulp-sass'); var header = require('gulp-header'); gulp.task('sass', function(){ gulp.src('path/to/scss/*.scss') .pipe(sass()) .pipe(header('@charset "UTF-8";\n\n')) .pipe(gulp.dest('dest/to/css')); });
コンパイルしたcssの先頭に「@charset "UTF-8";」の文字列を追加していいます。
しかしこれだけでは不十分です。
なぜならこのままだと実際にコメント中に日本語が入っていたり、またCSSのプロパティにおいてマルチバイト文字が使われている場合、すでに文字コード指定が出力された上にさらにgulp-headerにより文字コード指定が重複して出力されてしまいます。
具体的には次のような記述があるケースです。
■コメント中の日本後
// これは日本語によるコメントです
■font-familyの指定
body{
font-family: "游ゴシック体", YuGothic, sans-serif;
}
■アイコンフォント等における擬似要素での指定
.icon:before{
content: "\e006";
}
そこで、どのような場合でも文字コード指定が重複して出力されないようにしなければなりません。
マルチバイト文字の存在を判別することは現状Node.jsではできないため、ファイル中の文字列置換を行うgulp-replaceモジュールを併用します。
var gulp = require('gulp'); var sass = require('gulp-sass'); var header = require('gulp-header'); var replace = require('gulp-replace'); gulp.task('sass', function(){ gulp.src('path/to/scss/*.scss') .pipe(sass()) .pipe(replace(/@charset "UTF-8";/g, '')) .pipe(header('@charset "UTF-8";\n\n')) .pipe(gulp.dest('dest/to/css')); });
コンパイル結果から一度文字コード指定を取り除いた上で、改めて文字コードを追加しています。
若干冗長ではありますが、gulpではこれが精一杯の対応となります。