HOME備忘帳

HTMLのcontenteditable属性

HTMLにcontenteditableという属性があります。trueにすると、そのタグ内がブラウザ上でそのまま編集できるようになります。

面白そうなので使ってみましたが…。という話です。

テキスト編集ツール

まずはアウトプットのご紹介です。
習作がてら、ブラウザで閲覧しているページをそのままテキストだけちょこっと更新できるツールを作りました。

HTMLテキスト編集ツール リトルビット

サーバ側(perl)クライアント側(javascript)共に、動作するファイル一式を公開していますので、興味があればご覧ください。
かなり機能限定していますが、もし何かに使えるなら、個人でも商用でも自由に(自己責任で)使っていただいて構いません。

[ ページ先頭へ ]

contenteditableとは

contenteditable属性は、IE5の独自仕様として実装されたのがはじまりだそうです。
その後HTML5でも採用されているらしいです。

ぐぐると、リファレンス系のサイトが多数ヒットします。

お恥ずかしながら、私は昨年ぐらいまで存在を知りませんでした。

単純ではない

私の個人的感想としては、イマイチ使えない奴だなー、です。

javascriptなどでcontenteditable="true"とやれば、<ul>だろうが<p>だろうが<span>だろうが、いきなり編集可能に。こんなに面白いのに、なぜみんな使わないんだろう!
…と思ったのは最初の一瞬だけでした。

基本的な編集機能(文字入力や削除、改行など)はブラウザが面倒を見てくれるものの、それだけしかしてくれません。フォーム要素ではないので、中身をサーバに送りたいなら、送る処理を自分で書く必要があります。

そこは特性上仕方ない面もありますし、jQueryなどの力を借りれば要素の内容をサーバに送信するぐらい簡単に実装できます。

が、メリットである編集機能がさっぱりです。
気の利いたことは一切できません。

いくつかのショートカット、たとえば「Ctrl+B」で太字(久々に見た<b>タグ)が使えますし、書式つきのテキスト(たとえば他のHTMLページの内容)をコピーすると、そのままの書式でペーストできますが、それだけです。

高機能なWYSIWYGエディタを無料で利用できる昨今、あまりに貧弱に感じるのではないでしょうか。

また、改行の扱いが微妙です。
直感的に正しく動いてくれるケースもあれば、新しいdivタグを作って入れ子にしてしまうケースもあり、ブラウザ実装次第でかなり厄介です。
Shift+Enterでは大抵、無難に<br>タグを使ってくれるようですが、裏技的でユーザーフレンドリーとは言えません。


ALOHA Editor が諦めた

編集機能の貧弱さは、必要に応じてスクリプトで追加すれば良い、という考え方もありますが。

例に出そうと思ったALOHA Editorというツール、私がcontenteditableの存在を知るきっかけになったものなのですが、今はcontenteditableでの開発をやめていました。(いい感じに出来ていたのに)

理由は「ブラウザのAPI仕様がアレすぎ。俺たちの理想を追求するには、別のアプローチの方が良くない?」みたいなことっぽいです。
(雰囲気だけで読んでます。原文こちら↓)
http://www.alohaeditor.org/Content.Node/blog/goodbye-contenteditable.html

(結果、ALOHA Editor 2 というコンセプトはそのままだけどcontenteditableは使わない別物が公開されていて、これはこれで面白そうですが)

私も冒頭で紹介したテキスト編集ツールを作る時、いろいろアレな部分の片鱗を実感しました。
ALOHA Editorの、こういうの作るならcontenteditableじゃなくていいや、って決断は正しいと思います。

何かに使えないか

とはいえ、折角存在するのに勿体無い。

昨今ふつうに利用されているDOM操作も、DirectHTMLとか呼ばれていた時代には色物扱いでした。contenteditableが脚光を浴びる日が来ないとも限りません(来ない気がします)。

編集機能を充実させるのが大変すぎるなら、逆のコンセプトで。
いっそ、テキスト以外は編集できないようにしたら。
…という発想で作ったのが冒頭のツールです。

[ ページ先頭へ ]

ツール仕様(蛇足)

わざわざcontenteditableを使う以上、そのメリットを生かさないと意味がありません。

冒頭のツールの仕様に関する蛇足説明です。

「ここ」を編集

contenteditableのメリットのひとつは、閲覧している状態から、シームレスに編集に移行できることだと思います。自分がどのページの、どの部分を編集しているか、これ以上なく明白です。
見知らぬ管理画面にログインして、「あのページは「お知らせ」か「トピックス」かどっちだろう?」と悩む必要はありません。

つまり、contenteditableを使った編集ツールの対象ユーザーは、「実際のサイトと管理画面メニューの対応を考えなくて良い」のがメリットになる方です。

そんなユーザーにとって良いインターフェイスとは、とにかく迷わないことではないいでしょうか。
迷わせないために、選択肢(メニュー)を出来るだけ少なくしました。

あった方が良さそうな機能のほとんどを、単純さを重視して捨てました。
パスワード変更すら無いのはやりすぎ感もありますが、対象ユーザーを想像して思い切って端折ってしまいました。

見たまま編集、そのまま保存

contenteditableのもうひとつのメリットは、閲覧時と編集時の見た目が変わらないことだと思います。

CMSなどのリッチエディタでも、編集中に実際のページを再現するのは難しく、ほとんどはプレビュー機能で回避します。
contenteditableの場合、再現などというレベルではなく、まさにそのページそのものを表示した状態で編集できます。

しかし「見た目が変わらない」のはデメリットでもあります。
もし本当に何も変わらなかったら、ユーザーは「編集できる状態になったのか」「どの部分が編集できるのか」さっぱり分からなくて困ります。

そのため、今回のツールではモーダル風の見た目にしました。
ページ全体に半透明レイヤーを重ねた上で、編集可能ブロックを「白背景・黒文字」に変更するCSSを動的に読み込んでいます。

結果、編集可能ブロックがハイライトされるので、機能を伝えることはできると思います。が、デザインによっては「そのまま編集」というメリットを損なう可能性もあります。
対象ページのデザインを動的に解析して最適な色を使う、などすればスマートでしょうが、今回は適当に妥協しました。

リッチ編集させない

contenteditableのメリットとは言いがたい貧弱な編集機能は、もはや邪魔ですらあります。

ペースト時のイベントを、ツール側で書いたものと置き換えました。書式を無視して文字データだけを貼り付けるためです。
本来のペーストと全く同じ動作にできればベストだったのですが、微妙な問題が多すぎて「なんちゃって」止まりです。
まずいことに、IEだと「クリップボードの中身を見ようとしてるけどいいの?」と警告が出ます。
このツールのユーザー像を考えると避けたい事態ですが、いまのところ解決方法は見つけられていません(なにか良い方法があればぜひ教えてください)。

ショートカットによる編集は、とりあえず放置しています。
処理の選り分けが面倒、コピペに比べて悪影響が出る可能性が低い、スタイルシートの工夫で簡易編集機能として活用する道も無くはない…といった判断です。

改行については回避が難しいです。
サーバ側で編集内容を受け取った後に冗長なタグを消す、ぐらいの対処になるでしょうが、今回は実装していません。ショートカット同様、致命的な悪影響は出にくいので放置しました。
編集可能にするタグを、出来るだけ「内側」にすることで、ある程度防げると思います。

[ ページ先頭へ ]

参考

HTML5 W3C Recommendation 7.6 Editing

昔からある属性ですし、今も載ってるので、すぐすぐ廃止されそう感は無い気がします。単に放置されてるのでしょうけど。

最終更新日:2015/07/28

[ ページ先頭へ ]