Состояние удовлетворенного

Я подозреваю, что он находится в таком состоянии по нескольким причинам:

1.) Стандарт HTML5, который определяет его, не определяет, что он должен выводить, оставляя каждую реализацию решать за себя.

2.) Редактор не знает, нужно ли вам точное представление или семантическое. Часто это компромиссы.

3.) Похоже, Mozilla перетащила старый код Netscape Mail / Composer в свою реализацию designMode, а затем перетащила его в contentEditable. Он по-прежнему использует те же пунктирные очертания и маленькие красные ручки, которые существовали 10 лет назад, и я подозреваю, что огромное количество устаревшего кода.

4. Похоже, что Internet Explorer делал то же самое, а IE вообще никогда ничего не делал должным образом. Он по-прежнему тянет за собой свое наследие в виде причуд и режимов «совместимости».

5.) На самом деле он используется только в системах CMS и форумах / комментариях, и обычно они имеют довольно тяжелые оболочки вокруг реализации. Я не видел особого использования в других местах, особенно «голых».

6.) Есть несколько успешных онлайн-текстовых процессоров и еще меньше приложений WYSIWYG или верстки страниц. Нет необходимости создавать точных редакторов. Что еще хуже, Microsoft продает автономное программное обеспечение, такое как Word и Expressions, которым определенно повредит рост количества онлайн-редакторов, особенно высококачественных бесплатных.

7.) У Microsoft есть наследие создания инструментов, которые генерируют неверный и раздутый HTML-код, который до сих пор существует в Outlook 2010 и пакете Office.

8.) Иногда одна и та же команда выбора и редактирования может быть применима к нескольким возможным объектам, занимающим одно и то же пространство, и редактор никогда не может точно знать, какой из них вы хотели изменить. Также команда редактирования может вызвать разделение элемента неопределенным или неожиданным образом (опять же, он не будет знать, какой из них вы предпочтете).

Я не верю, что contentEditable когда-либо будет так же хорош, как вырезание собственного HTML или использование специального инструмента. Я бы просто сосредоточился на работе с некоторыми базовыми инструментами для исправления ошибок (например, HTMLTidy) над результатом и остановился бы на этом.

Это сложный вопрос, который все решают по-своему.

Я знаю о следующих возможностях:
* Просто отпустите (худший вариант)
* Попробуйте исправить HTML самостоятельно (TinyMCE и CKEditor пытаются сделать это с помощью различные показатели успеха)
* Используйте плагин, такой как XStandard
* Используйте DOM, чтобы создать свой собственный редактор - сделайте каретку из DIV, обработайте выделение, редактирование и все остальное самостоятельно. Вот как это делает, например, Google. Однако для этого требуется много кода.

Для браузеров, поддерживающих contenteditable, решение можно довольно легко найти; используя, например, jQuery для сохранения данных и присоединения новых элементов к редактируемому контенту (с помощью кнопок, очевидно) можно получить простой редактор WYSIWYG с очень небольшими усилиями.

Одна проблема, которую может быть немного сложнее решить, - обеспечить правильное размещение этих новых элементов. Однако это было решено для Webkit, и я уверен, что это возможно и в других браузерах.

Редактор, использующий contenteditable, будет и легко развернут, и легковесен, действительно ли это что-то стоящее разработки, ИМХО.

Изменить: перечитав ваш вопрос, я понял, что вы действительно искали работающее решение, отличное от contenteditable. Я не знаю почему; AFAIK contenteditable создает допустимую разметку, и если вы получите полный контроль (позволяя пользователям вставлять элементы и изменять их свойства через ваш пользовательский интерфейс), это также будет семантическим. Насколько мне известно, текущие редакторы WYSIWYG не используют contenteditable, но я могу ошибаться.

Я думаю, что ваша проблема заключается в попытке использовать такой инструмент, как Google Docs, как указано в предыдущем комментарии, вместо инструмента, который действительно ориентирован на редактирование HTML.

Да, оба типа являются WYSIWYG, но я не думаю, что целью GDocs является создание хорошего HTML, вместо этого они сосредоточены на предоставлении альтернативы MS Word, даже если им придется идти и создавать странный HTML по пути.

Я не могу поверить, что вы изучали это в течение нескольких недель и еще не используете CKEditor или TinyMCE. Оба решения включают в себя варианты использования атрибутов, классов или стилей для вывода, просто посмотрите на образцы, немного почитайте документацию и настройте ее в соответствии с вашими потребностями.

Я ответил на очень похожий вопрос в редактируемых текстовых редакторах содержимого - почему ситуация выглядит вот так и что мы, авторы редакторов WYSIWYG, можем с этим поделать.

Да, я знаю, что этому вопросу 2 года, но он все еще актуален.

Medium.js !!

Medium.js сохраняет HTML-код contenteditable семантическим, простым и чистым. Medium.js также поддерживает заполнители, автоматическое создание HR (или BR, или P), события, горячие клавиши, внедрение простых и сложных элементов и многое другое!