無料ブログ「rentafree.net」の管理人ブログ

ブラウザの"戻る"の時に警告

マウスのチルトホイールや4ボタン以降のボタン誤操作で文章入力中にページが移動して編集中の文章が消えるのを防ぐために、
ブラウザの"戻る"時に警告を出すようにすることを検討してみたんですが、

ブラウザの"戻る"だけを検知して警告を出すことはできないので、
代わりに"beforeunload"イベントでページが閉じられる前に処理をする必要があるのですが、
これだと"戻る"以外にも<a><form>などでも発生してしまう。

<form>だけ回避するという事も出来なくはないですが、
イベント発生場所の取得もできないので全ての<a>でイベント処理をキャンセルすることはできなそう。

<form>以外でのページ移動の際に全て警告を出してもいいかなとは思うんですが、
下書き機能の自動バックアップもありますし、そもそも警告を出す必要性があまりないかなと思うんで、
この件は実装しない方向で・・・

Operaの改行処理を修正しました

ブログエディターの改行処理ですが、
ブラウザに任せると<br>ではなく<p>や<div>を挿入されてしまうため独自処理で<br>を挿入していますが、
Operaではrangeを<br>に置換してもキャレットが移動できないという問題があったため処理を回避してブラウザに任せていたため、<p>が挿入されていましたが、
なんか直っているようなんで、他のブラウザと同じ様に<br>を挿入するようにしました。

ただし、他ブラウザでは<br>の後ろに改行コードを挿入してソースモードで修正しやすいようにしていますが、
Operaで改行コードを挿入すると改行コードの後ろに文字を入力した場合に改行コードが&nbsp;に変換されてしまうようなので、
改行コードの挿入はしないで空のテキストノードを挿入するようにしています。


Operaの更新履歴にそれらしい変更が見当たらないのですが、
古いバージョンでは問題があるかもしれません。
現行最新バージョンの12.12では問題ないようです。

改行処理の不具合を解消しました

ブログエディターでEnterを押すと<br>を挿入しますが、
ブロック要素等の親要素の末尾に<br>を挿入する場合は<br>を2個入れないと次の行が有効にならないので、親要素末尾に<br>を挿入する処理を入れていましたが、
末尾でEnterされたかの判別ができなかったので、親要素末尾がテキストノードの場合は末尾に<br>を挿入するという処理にしていました。

この方法ではEnterした場所以外でも<br>が挿入されてしまう可能性があり、
こちらでも編集の際に問題が生じる場合があることに気づいていたので修正を試みていたのですが、
末尾でEnterされたかの判別に成功したので、末尾でEnterされた場合のみ<br>を挿入するように修正できました。


Firefox用の新エディターのみに修正を行いましたが、同じ処理が旧エディターにも入っているので、
引き続きFirefox以外(IE8以下及びOperaは置換処理非対応なので元々この処理はありません)では問題が生じるのですが、
旧エディターの方は、こちらで日常的に確認できないので、別の問題が生じると困るので同様の修正入れないことにします。

Firefox以外の新エディター対応は、他ブラウザがHTML5<menu>タグに対応しないとどうにもならないので今のところ無理です。


[追記]
旧エディターに修正を入れなくても他ブラウザが新エディターに移行したら新しい改行処理に移行しますし、
未修正の改行処理で不具合報告されても困るので、
旧エディターの方にも同様の修正を入れることにしました。
IEに関しては空のブロック要素でも1行となるようで、末尾<br>1個でも末尾行が有効になる様なので処理を除外しました。
また、IEはテキストノードに改行コードを入れることができなかったので改行コードの挿入処理を除外していましたが、
バージョン変わらずにこっそりアップデートが入っていたようで、有効になっていたので改行コード挿入処理の共通化を行いました。
アップデートしていないIE9の場合は問題が生じる可能性があります。

Wikiの行頭「)」の仕様を修正しました

Wikiの行頭「)」でinline-blockの<span>となりますが、
複数行の<span>の際に自動改行が効いていなかったので修正しました。

<span><div>内容</div></span>
の様に<span>内の最初の要素がWiki構文によるタグの場合、
元の仕様では、1行目に行頭「)」の内容なしの行を入れて2行目に別の行頭構文を使うことで可能でしたが、
この方法は間違いで、
1行目の行頭「)」では末尾改行をエスケープする必要があります。
(エスケープしない場合は先頭に改行が入ります。)

ハイブリッド・テンプレートを修正しました

新しく作ったカラム数可変のハイブリッドテンプレートですが、
タブ操作で移動済みの要素をresizeイベント時に戻していましたが、
開いている状態の要素を移動するのは問題があったので開いているタブは除外していましたが、
resizeイベント時ではなくMediaQueryListで処理するように変更しました。

これにより、MediaQueryList対応ブラウザでは1カラムでタブを操作してから2カラム以上に戻しても、
全ての要素が正常な位置に表示されるようになりました。

ただし、タブの操作状態は変更しないので、更に1カラムに戻した場合にタブが開かれた状態で要素が閉じている状態になる可能性があります。
この場合は、再度タブを閉じてから開けば表示されます。

また、IE9がMedia Queriesに対応していますがMediaQueryListには非対応なので、
IE9では1カラムでタブを操作してから2カラム以上に戻した場合、
操作済みのタブの要素は全て異常な位置に表示されます。
IE10は対応です。

公式JavaScriptのタブAPIを修正しました

Wikiの方にも公式JavaScriptを用意して簡単にタブUIを作れるようになりましたが、
タブグループが複数ある場合でも別のタブを開いた際に、すでに開いているタブが閉じられる仕様でしたが、
別のタブグループのタブは閉じられるべきではないので修正しました。

ブログの方も同じ修正をしています。

タブグループは、タブAPIの第4引数の移動先で確認し、
開いているタブを移動先単位で別々に記憶して、
同じ移動先のタブが開かれた場合のみ既に開いているタブを閉じます。
第4引数が省略されている場合は全て同じタブグループとみなされます。

互換性には問題がないはずです。

Wikiのハイブリッドテンプレートができました

朝告知していた、画面サイズによってカラム数が変化するテンプレートのWiki版ですが、
できましたので公式テンプレートに追加しました。

まず、Wiki構文でタブUIを作成できるようにしましたが、
http://wiki.rentafree.net/%E3%83%95%E3%82%A3%E3%83%BC%E3%83%AB%E3%83%89
にて解説しています。

ブログと違いプラグインというものがなく、サイドバーもWiki構文で作成するので、
ハイブリッドテンプレートの使い方はブログと違い難しくなっています。
後ほどテンプレートの説明ページを作成しようと思います。

Wikiにもハイブリッドテンプレートを用意しようかと・・・

ブログ公式テンプレートに新たに用意した、カラム数可変のハイブリッドテンプレートは、
ハイブリッドを標準にしようかと検討したくらいで良くできたと思っているのですが、
(レイアウトが変化することを理解せずに使用されたくないので標準にはしませんでしたが)
モバイル機器で通常のWEBサイトを見ることが多くなっていますので、
ブログではなく、Wikiの方も同様にハイブリッドテンプレートを用意できないか検討しています。

ブログはサイドバーにはプラグインしか設置できないので、プラグイン単位にグループ化することができますが、
Wikiの場合はサイドバーに何が入っているのかわかりませんので、システムを変更して構文を拡張する必要がありますが、
一応構想はできていますので、近いうちに実際に検証してみようと思います。

新しい公式テンプレートに問題が生じる場合がありました

画面サイズによりレイアウトが変化する新しい公式テンプレートですが、
タブの処理によって移動された要素をresizeイベント発生時に元の位置に戻す処理を行なっていましたが、
タブレットの仮想キーボードが表示される場合に縦が変化するのでresizeイベントが発生し、
検索プラグイン等の入力が必要なプラグインの利用が不可能になっていました。
他にもプラグイン表示後に高さが変化するプラグインや、スクロールバーの有無が変化してサイズが変化する場合にタブでのプラグイン表示ができませんでした。


この問題は良い解決方法が思いつかないのですが、
resizeイベント発生時に移動されている全ての要素を戻さずに、
移動されていて非表示のプラグインのみ戻すように変更しました。

この変更で1カラム時は問題が生じなくなりますが、
1カラムでタブを開いている状態で画面サイズを変更して2カラム以上に戻した場合、
2カラムでは開いているタブの要素がサイドバーの一番下に落ち、
3カラムでは記事上に表示されてしまいます。

問題がありますが、
画面サイズの変更により1カラムから2カラム以上に戻るという事が通常はありませんし、
1カラムで検索プラグイン等が利用不可になる方が問題が大きいと思いますので、
このような修正としました。