Угрозы надежности состояния контента во время правок визуального редактора
Редактирование кода сайта через визуальный редактор несет в себе скрытую угрозу для качества кода:
1. Конфликты стилей
Это вероятные ошибки, связанные с неоднозначным определением правильной инструкции, при наличии нескольких их вариантов
Современные браузеры чаще всего нормально распутывают этот клубок, лишь слегка замедляя процесс отрисовки. Но старые версии одних и тех же браузеров, разные вебдрайверы (например, Хромиум и firefox), разные устройства (ПК, Android, iPhone) — могут по-разному интерпретировать код сайта в силу особенностей поддержки тегов и их атрибутов. Получается, что код один и тот же, но он приводит к разным результатам.
2. Затруднения поддержки
Это может показаться не значительным, но на практике сильно снижает производительность
Реальные примеры
Список УТП на сайте turboremont36.ru
<h2 class="wp-block-heading has-text-align-center" id="не-боимся-пускать-клиентов-в-ремзону"><strong><span style="
font-size: 14pt; font-family: verdana, geneva; color: #ff6600;"><span style="font-size: 24pt;">Не боимся пускать клиентов в
ремзону</span></span></strong></h2>
Оно же, но с восстановленной структурой
<h2 class="wp-block-heading has-text-align-center" id="не-боимся-пускать-клиентов-в-ремзону">
<strong>
<span style="font-size: 14pt; font-family: verdana, geneva; color: #ff6600;">
<span style="font-size: 24pt;">Не боимся пускать клиентов в ремзону</span>
</span>
</strong>
</h2>Что здесь не так:
1. Значение id указано русскими буквами. Это нарушает общепринятые соглашения, и повышает вероятность некорректной отработки: скриптов, использующие поиск по селекторам; стилей с относительными путями; вызывает повышенный интерес линтеров и т.д. (я даже не знаю что может быть еще, но интуиция подсказывает — так лучше не делать). К тому же нет ни стилей, ни скриптов на сайте, которые бы взаимодействовали с этим id
2. Одновременно используются классы и повторяющиеся стили. Вообще, рекомендуется выносить в параметры класса те стили, которые несколько раз используются для однородных тегов (в том то и смысл классов как таковых). Если нужные особые стили именно для span и не хочется отдельно добавлять для него класс, то легко можно определить через стиль селектор вида .wp-block-heading > span.
В результате, при необходимости исправить атрибут стиля всех элементов, приходится менять каждый тег (а можно было просто изменить класс). Плюс код перегружается и становится менее читаемым
3. Дубли span. Тоже перегружает, путает и затрудняет поддержку
4. Перезапись атрибутов стилей font-size. Сначала задается значение 14pt, потом — 24pt. Путает, перегружает
5. Применение тега <strong> не по назначению. Вообще он предназначен для выделения важного текста. И да, большинство браузеров определяют важный участок жирным начертанием. Но на старых браузерах текст интерпретируется как выделенный жирным + подчеркнутым
6. Не грамотное использование неразрывного пробела. В тексте используется сигнатура между "пускать" и "клиентов". Значит, пользователь визуального редактора позаботился о динамическом представлении текста на малых экранах. Но ее нет между предлогом и "ремзону" в конце предложения (вероятно из-за ошибок конструктора)
Если нам нужно однозначно пометить текст как жирный, лучше было бы использовать тег <b> или (еще лучше) добавить атрибут font-weight в тот же класс wp-block-heading
7. Весь код на одной строке. Это грубое допущение, которые не исправить в полной мере, потому что код, внедренный в визуальный редактор «ломается», теряя отступы и переносы строк. Как следствие — ломается визуальная структура, по которой можно было бы ориентироваться
Перед внесением правок в код сайта приходится или вручную снова и снова восстанавливать структуру, или терпеть плохую читаемость
Как это должно было выглядеть
<h2 class="wp-block-heading has-text-align-center">Не боимся пускать клиентов в ремзону</h2>Или (если span действительно нужен)
<h2 class="wp-block-heading has-text-align-center">
<span>Не боимся пускать клиентов в ремзону</span>
</h2>