HTMLのcontenteditable属性
HTMLにcontenteditableという属性があります。trueにすると、そのタグ内がブラウザ上でそのまま編集できるようになります。
面白そうなので使ってみましたが…。という話です。
テキスト編集ツール
まずはアウトプットのご紹介です。
習作がてら、ブラウザで閲覧しているページをそのままテキストだけちょこっと更新できるツールを作りました。
- 編集ボタンを押すと、あらかじめ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
[ ページ先頭へ ]