"span"要素を使用してカスタムWebベースのテキストエディタを作成する - 悪い考えですか？

Question

埋め込みテキストエディタの機能を完全に制御する必要のあるWebアプリケーションのアイデアがあります。テキストエディタは、すべてのブラウザで同じという正確にを機能させる必要があります。この場合、標準contenteditableの機能は私のニーズには十分ではありません。

私はカスタムテキストエディタを実装するさまざまな方法を試してきました。私の最初のアプローチは、キャ​​レット挿入のためのマウスクリックを検出することでした（これを実現する方法がないので、キャレットは表示されません）。これはかなりうまくいきましたが、残念ながらキャレットを表示する方法はありませんでした（別名I-ビームの点滅）。

これは、私の点滅キャレットもカスタムメイドでなければならないことを意味します。私は、すべてのブラウザで互換性のある方法でこれを実現する2つの良い方法について考えることができます。

1. GoogleのGoogleドキュメントと同じように、JavaScriptでカスタムレイアウトエンジンを実装するのが最初の選択肢です。

2. 2番目の解決方法（おそらくもっと簡単です）は、各文字を独自の<span>要素内にカプセル化し、特定の文字の間に偽のキャレットを配置することです。これは、多くのスパン要素が存在することを意味しますが、ブラウザレイアウトエンジンを利用しながら必要なものを確実に達成することができます。このアプローチのもう1つの利点は、ブラウザ固有のテキスト選択ハックに頼る必要がないことです。

私の質問は、オプション2は本当に悪い考えですか？もしそうなら、なぜですか？

Answer 1

まず第一に、あなた自身のエディタで作業する必要がありますか？ FirepadとEtherpadがあり、かなりの共同編集があり、おそらくcontenteditableに基づいていないよりオープンソースのエディタがあります。このようなエディタを作成するのは本当に難しいので、時間を無駄にするのは意味がありません。

しかし、実際に自分のソリューションで作業したい場合は、正確にはと同じ動作がすべてのブラウザで必要です。 contenteditableを避けることができても間違っている可能性があることは間違いありません。

とにかく、答え：

1. 最初のオプションは、最初に非常に困難で時間がかかるが、それはあなたの第二のものよりもはるかに多くの電力を提供します。例えば。 CSS30の実装を待たずにページ区切りを実装することができます（正確にはすべてのブラウザで同じ動作にしたいので、決して頼ることはできません）。実際、ブラウザのレンダリングの違いの大部分を回避することができます。しかし、あなたはまともなJS開発者と数ヶ月（少なくとも）のチームを持っていない限り、私はそれについて考え始めることさえしません。

2. DOMを再利用する第2の解決策は、より現実的です。最初にいくつかのパフォーマンステストを行いますが、文字単位でスパンを設定すると、マウスクリック後にキャレットを配置する場所を簡単に見つけることができます。それがなければ、いくつかのトリックが必要です...私は知らない。あなたは本当に長い文書を編集したいのでなければ、EtherpadとFirepad（それはAce code editorを使用しています）がそれをどのように処理するかを調べることができますが、まだラッピングは最も簡単な選択であり、少なくともまともなブラウザではパフォーマンス上の問題を起こすべきではありませんいくつかの最適化を開始することができます）。