Статьи

Трагическая комедия, которая является Rich Text Editing в Интернете

Rich Text Editor

Проблема заключается в следующем: клиенты хотят текстовый процессор, а разработчики хотят чистый семантический HTML. Ответом должны были быть текстовые редакторы веб-страниц. Еще в IE4 Microsoft предложила расширенный компонент для редактирования текста; Mozilla также реализовала аналогичный редактор, и другие браузеры тоже сделали это. Эти встроенные компоненты редактирования не имеют пользовательского интерфейса и доступны только через JavaScript; отсюда и набор текстовых редакторов JavaScript, появившихся после реализации Mozilla.

Итак, редактирование текста в браузерах уже более десяти лет. Проблема решена? Мы даже не близко. Вы видели HTML-код, выводимый этими редакторами? Давайте начнем с очень простой задачи: сделать текст жирным. В IE и Opera вы сгенерируете этот HTML:

<STRONG>some text</STRONG> 

В Mozilla, Safari и Chrome это результат:

 <b>some text</b> 

В Mozilla, Opera, Safari и Chrome есть свойство styleWithCSS именем styleWithCSS . Хотя в Opera нет никакой разницы, если она включена, Mozilla сгенерирует:

 <span style="font-weight: bold;">some text</span> 

Safari и Chrome будут генерировать:

 <span class="Apple-style-span" style="font-weight: bold;">some text</span> 

Но это становится еще хуже. Если вы сделаете текст жирным в Mozilla, Safari или Chrome с включенным styleWithCSS , IE и Opera не смогут удалить жирный шрифт. Если вы сделаете текст жирным, используя IE или Opera, а затем попытаетесь удалить жирный шрифт в Firefox, невероятно, что <STRONG> станет <strong style="font-weight: normal;"> .

Есть так много примеров ужасного HTML, что трудно понять, что вытащить в качестве примера. Посетите расширенные текстовые тесты на Browserscope и протестируйте несколько браузеров; это очень поучительно. Вы увидите использование тега шрифта, сочетание прописных и строчных букв в одном и том же теге, некоторые атрибуты в кавычках, а некоторые нет, <br><br> для разбиения на абзацы и использование кавычек для отступа. Вы обнаружите, что реализации браузера сильно отличаются. Есть даже множество обстоятельств, которые могут привести к этому кусочку невыразимого ужаса:

 <SPAN style="BACKGROUND-COLOR: rgb(255,0,0)" class=Apple-style-span><FONT style="BACKGROUND-COLOR: #0000ff">foo bar baz</FONT></SPAN> 

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

Находиться в этом состоянии в 2010 году ужасно. Что HTML5 собирается с этим делать? Следующая фраза повторяется по всему разделу contentEditable :

«Точное поведение зависит от UA, но пользовательские агенты не должны, в ответ на запрос обернуть семантику вокруг некоторого текста или вставить или удалить семантический элемент, генерировать DOM, который является менее совместимым, чем DOM, до запроса «.

Хорошо, что в стандарте подчеркивается, что пользовательские агенты в первую очередь не должны причинять вреда, но все же они довольно расплывчаты, а детали реализации остаются зависимыми от UA. Я бы согласился на небольшую согласованность между браузерами. Существует возможность добавления «расширенного текстового поля» в список стандартных элементов управления формы, и пользовательские агенты могут отображать панель инструментов по умолчанию для стандартных задач редактирования.

Как вы думаете? Должно ли поле расширенного текста стать частью стандарта или мы должны полагаться на JavaScript, чтобы разобраться с этим? Является ли многофункциональный текстовый редактор правильным подходом для редактирования контента в Интернете?