Ответ 1
В начале я должен упомянуть, что я являюсь разработчиком ядра CKEditor, поэтому мое мнение не может быть полностью объективным:).
Состояние редактирования HTML AFAIK не изменилось за последние несколько лет. Производители браузеров потратили мало времени на исправление ошибок - настолько мало, что большинство старых ошибок на CKEditor trac, которые были вызваны проблемами браузера, по-прежнему актуальны, и большинство хаков, которые мы когда-либо создавали, все еще требуется. И я имею в виду не только IE 7 или 8, которые мы все еще поддерживаем, потому что на самом деле IE могут быть не самыми худшими. Я не проверял это точно, но я думаю, что благодаря общим улучшениям для DOM API в последних версиях IE они могут потребовать меньше хаков, чем другие браузеры, потому что их поддержка в редактировании кажется наиболее стабильной и полной. Например. для браузеров Webkit необходим самый уродливый хак (см. ошибка Webkit и закрыто CKEditor), и эта ошибка 5 лет. Что еще - это не краевой случай или маловероятный сценарий - эта проблема не позволяет создать весь диапазон выборов - например. внутри пустого встроенного элемента IIRC.
Итак, в отличие от веб-технологий в целом, редактирование HTML стоит там, где оно осталось 10 лет назад. Те же ошибки, те же недостающие функции, та же самая... разметка. Угадайте, что создано командой fontName? <font face=""> - да, не шутя. По крайней мере, браузеры здесь очень последовательны... Но последовательность очень быстро исчезает.
Как насчет спецификации? Там проект, но это совсем не помогает - он просто стандартизирует текущее состояние, которое, как мы знаем, выглядит не очень хорошо. И AFAICS, проект мертв.
И еще одна вещь, которая меня беспокоит - направление, в которое идет редактирование. Google использует contenteditable в Gmail (нет, Google Docs не построен на contenteditable), поэтому он не заботится о выходе HTML. Apple повторно использует компонент редактирования HTML в своем приложении электронной почты для iOS и, возможно, в Mail для MacOS (потому что я вижу то же конкретное поведение). Mozilla повторно использует Gecko в Thunderbird, и я бы не удивился, если Microsoft сделает то же самое в Outlook. Все они не заботятся о выходе HTML. Эти движки сделаны для понимания всех хрячей, а не для исправления, а проект редактирования HTML - это все.
Благодаря этому мы можем видеть новые проблемы, такие как этот. В отчете Сообщение об ошибке Blink/Webkit Я привел целый ряд неправильных (от наших POV-разработчиков, которые заботятся о HTML), при нажатии backspace. Он разработан, чтобы выглядеть красиво (хотя это не так), но API-интерфейсы HTML и редактирования не важны.
Мне все равно. Мне нужен редактор!
Решение для всего этого - это исправление всего после браузеров и/или замена их собственных реализаций нашими собственными. За последние 1,5 года я работал почти исключительно по фильтрации и нормализации ввода и вывода. В CKEditor 4.0 мы перезаписали все процессы вставки и вставки HTML, а в недавно выпущенном CKEditor 4.1 мы ввели Advanced Content Filter, который адаптирует входные данные к конфигурации редактора, Таким образом, чем меньше функций включено, тем меньше будет разрешено в HTML. Проверьте этот пример - попробуйте вставить/написать/создать crappy HTML.
Конечно, есть еще место для улучшений. Например. мы не можем фильтровать данные сразу во время редактирования. Если браузер (например, Webkit) создает беспорядок, мы можем исправить это на выходе, но на самом деле мы не решили это сделать, потому что фильтрация действительно сложна и может испортить производительность. Мы ограничиваем входные и пользовательские действия, поэтому в один прекрасный день мы будем внедрять наши собственные обработчики backspace/delete, чтобы браузеры не испортили наш HTML. Это единственное решение, и именно поэтому есть только 2 или 3 хороших редактора WYSIWYG.
В любом случае почти ничего не изменилось в реализациях редактирования HTML браузеров, но многое изменилось в мире редакторов WYSIWYG. Я советую вам проверить их снова, если вы основываетесь на своем опыте с нескольких лет назад.