ブラウザでテキストエディタを構築する：canvas vs contenteditable vs textarea

デビッド・ブッシェルは、現代のソフトウェアの状態にうんざりし、ブラウザで独自のテキストエディタを構築することにしました。彼の実験は、<canvas>、contenteditable、<textarea>の3つのレンダリングアプローチを比較します。結果は、コードエディタやリッチテキスト入力を構築するすべての人に実用的な教訓を提供します。

Canvas：完全な制御、アクセシビリティなし

最初のプロトタイプは、<canvas>要素にすべてをレンダリングします。カーソル位置、矢印キーの移動、行のハイライト、テキスト入力をサポートします。しかし、canvasは何も無料で提供しません：テキスト選択、元に戻す/やり直す、複数行の貼り付け、オーバーフロースクロールはありません。ブッシェルは、隠されたネイティブのオーバーフロー要素を使用してレンダリングオフセットを駆動することでスクロールをハックしましたが、根本的な問題は残ります：canvasはスクリーンリーダーや支援技術に対して完全にアクセス不能です。

Contenteditable：無料のアクセシビリティ、パフォーマンスの癖

2番目のアプローチは、スクロール可能なdiv内でcontenteditable="plaintext-only"を使用します。これにより、ネイティブのテキスト選択、元に戻す履歴、アクセシビリティが無料で提供されます。Selection APIはカスタムカーソルのメトリクスを提供し、::selectionをスタイル設定できます。ただし、特定の文字数を超えるとパフォーマンスが予測不能に低下し、ChromiumはWebKitやFirefoxよりも悪化します。

Textarea：パフォーマンスの勝者

最終的なプロトタイプは<textarea>を使用し、長いテキストに対してはるかにパフォーマンスが高いことが判明しました。トレードオフ：textareaはCSS ::highlightを使用できないため、構文ハイライトには3番目のレイヤーのdivが必要です。ブッシェルは表示行にMicroLighterを使用しましたが、CSSハイライトが多すぎるとパフォーマンスの問題が発生すると述べています。彼は、表示行のみのハイライトを生成するためにTree-sitterを使用することを提案し、仮想化スクロールのための逆スティッキー技術に言及しています。

重要なポイント

ブッシェルのデモは最適化されておらず、完全にアクセス可能ではありませんが、ポイントを証明しています：canvasのような不利な位置から始めることは悪夢です。彼はプロジェクトを雨の日のために保管していますが、この探求は、すべてのウェブベースのエディタが直面するトレードオフを浮き彫りにしています。

彼はまた、絵文字や他のマルチバイト文字に関するUTF-16コードユニットのバグについて警告し、書記素対応の文字列処理にIntl.Segmenterを推奨しています。