RTEライブラリの仕組みとそれを支えるブラウザ機能

RTEの状態をドキュメントで表す

ドキュメントが満たすべき条件をスキーマで定義

何の要素の中に何個以上何の要素が入っているべき、とか

contenteditable

IMEや矢印キー、rtlなどはブラウザに任せたい

フロントエンドだけで戦わない、既存 wiki サービスへの WYSIWYG エディタ導入記

「見たまま」であることで起きる問題

コピペで入力の制限が超えられる

リストのネスト数制限とか

カーソルが意図しない位置に出る

Undoできないコマンドが生まれる

ユーザーの操作とトランザクション（操作の単位）を一致させる必要がある

ビューとのやり取りの設計が難しい

Context APIを使う必要性

大体見たままならOKで、残りをバックエンドで行う案

ページ構造の中で考えるリッチテキスト

サイトビルダーの複雑化

Movable Types→WordPress→Drupal

リッチテキストvsブロックエディタ

ブロックエディタ: WordPressやNotionみたいに、用意された要素を積み上げるエディタ

テンプレートの見出しと本文の見出しのレベルで競合してしまう問題

複数RTEがあるときの情報構造なども

ノーコードで簡単に作れるのがポイントなのに、複雑さをユーザー側に渡してしまっている

コンテンツデータモデル

Webサイトで本当はどういうコンテンツモデルが必要なのかを考えて、情報設計するのが大事

本文がRTEである必要性がない可能性

バックエンドでのバリデーション

サービスのフロントエンドから投げたものはバリデーションしない

外部からAPIなどで投げられたものはある程度バリデーションする

microCMSはこの形式

表現に制約を設けたくないvs邪悪なコンテンツデータを保存したくない

Tiptapで校正機能を作った時に考えたこと

Markで実装

WYSIWYG ルビ入力の概要と Chromium のバグを修正した話