Особенности реализации WYSIWYG редактора (contenteditable, iframe, hidden textarea+events)

#javascript #wysiwyg

Я видел несколько реализаций визуальных редакторов, таких как TinyMCE и CodeMirror.
Все могу разделить на 3 группы:


DIV c contenteditable=true - кажется в готовых проектах не используется в чистом виде
iframe + body[contenteditable=true] - Такой подход используется в TinyMCE, где редактор
находится в iframe
hidden texarea + Events + обычный DIV - такой подход используется в CodeMirror, как
я понимаю он постоянно держит фокус на скрытом textarea и читает события перевода каретки,
вставки и ввода данных, и добавляет их в обычный нередактируемый (contenteditable=false)
блок. Причем даже выделение текста делается с помощью цветного DIV.


В связи с этим у меня стоит выбор, какую реализацию выбрать и в чем ее особенности.

На данный момент мне надо:


Простое форматирование
Кастомную каретку
Адекватное копирование/вставку контента с сохранением форматирования
Возможно эффект плавного появления текста при печати


Использовать готовые разработки не могу.
Спасибо.
    

Ответы

Ответ 1

Очень рекомендую к прочтению (на англ.): https://stackoverflow.com/questions/10162540/contenteditable-div-vs-iframe-in-making-a-rich-text-wysiwyg-editor
(+ по ссылкам), мы во многом пересекаемся, но там пишут разработчики существующих редакторов.

Разница между iframe vs 


iframe более "тяжелый" (создается отдельный документ), и соответственно, более изолирован:


В iframe не попадет ничего из внешнего документа (в частности, стили). Это позволяет
вам реализовать WYSIWYG для более ограниченного набора функциональности, чем доступна
в Web. Простейший пример - будет ли ваш код готов к тому, что произвольные куски редактируемого
контента будут display: hidden из-за унаследованных стилей? Более сложный - как будет
работать каретка и выделение с унаследованными float? Ну и т.д.
Содержимое iframe не повлияет на внешний документ. Где-то приводился пример, что
баг браузера приводил к вставке контента "мимо" contenteditable - с iframe это будет
менее жесткий баг;
Народ пишет про безопасность. Сам не разбирался детально, но предполагаю, что может
быть связано с тем, что в дочернем фрейме можно запретить "случайное" выполнение левого
вредительского кода через что-нибудь вроде