Страницы

Поиск по вопросам

среда, 5 декабря 2018 г.

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

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


Ответ

Очень рекомендую к прочтению (на англ.): 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 это будет менее жесткий баг; Народ пишет про безопасность. Сам не разбирался детально, но предполагаю, что может быть связано с тем, что в дочернем фрейме можно запретить "случайное" выполнение левого вредительского кода через что-нибудь вроде