Ошибки и спорные вопросы в HTML-CSS вёрстке

Набор подходов и решений в области HTML-CSS-верстки, которые я считаю спорными или ошибочными (ошибки описаны мои, моих коллег, студентов). Все статьи цикла:

• Часть 1: методологические и организационные
• Часть 2: разметка
• Часть 3: стили

Разметка

Прежде чем продолжить, познакомьтесь с первым пунктом первой части этой серии статей (если коротко: некритическое восприятие подобных подборок является ошибкой).

Написание заведомо невалидной разметки

Пишете на каком-либо языке — соблюдайте правила языка.

Серьезные синтаксические ошибки разметки чреваты парадоксальным результатом при построении DOM. К примеру, даже если вы напишите внутри тега p тег div, в DOM вы увидите иную картину.

Положа руку на сердце, нельзя сказать, что обязательная валидность критично необходима (для HTML браузеры многое прощают), однако уподобляться горячему южанину на русском сайте знакомств («Я влодеть базовы руский давай делать секс») — некомильфо.

Современный валидатор разметки.

Неуказание doctype и/или кодировки

Чревато проблемами с отображением. В первую очередь, в старых IE (выбирают режим работы, исходя из doctype). Уже несколько лет мы используем HTML версии 5 с простым и понятным doctype.

Кодировка, в которой будет показана страница зависит не только от указанной в разметке (браузер может учесть полученные с сервера заголовки ответа и/или определить кодировку самостоятельно), но указать ее нужно: при прочих равных это позволит избежать проблем отображения. Метатег с кодировкой должен быть первым, что браузер встретит внутри head.

Игнорирование микроразметки

Как разумно заметил в комментарии к первой части этой статьи Игорь Тимохин, микроразметка (Schema.org, OpenGraph) — это не сложно и очень полезно для SEO.

Мне лично кажется, что микроразметка может уйти в прошлое в ближайшие несколько лет, ибо если специализированные ИИ-системы умеют распознавать лица на фото и менять эмоции на изображениях лица, отчего бы другим ИИ-системам не определять и семантический смысл элементов страниц? (Уверен, что такие системы уже используются поисковыми гигантами.)

Дополнение: признаюсь, я крайне редко добавляю микроразметку при работе.

Отсутствие логичной иерархии заголовков

Иерархия важна как для SEO, так и для восприятия страницы в случае отсутствия стилей (не загрузились по каким-то причинам). Добавляю по подсказке Вадима Макеева: заголовки, так же, очень важны для доступности страницы.

Проверить логичность иерархии можно в ходе проверки валидности документа (проставить чекбокс «outline»).

Отсутствие знакомства с рекомендациями для веб-мастеров

Если сайт будет запущен, владелец может захотеть вывести его на высокие позиции в поисковой выдаче. Верстка с учетом рекомендаций веб-мастерам поможет этому и улучшит вашу карму в глазах заказчика (критично для фрилансера). Помощь вебмастеру от Яндекса, рекомендации от google.

Набор разметки вручную

Если вы не используете какой-либо HTML-препроцессор, предпочитаете сами писать разметку, лучше делать это как можно быстрее. Очень странно набирать теги и атрибуты вручную, без emmet.

Emmet — это не только ценный мех разворачивание аббревиатуры в структуру тегов, в нём есть фильтры, удобное редактирование/убирание тегов, перемещение курсора между ключевыми точками и еще уйма вещей (см. документацию, в ней все показано с интерактивными примерами).

Использование сниппетов, так же, сильно ускоряет написание. Хорошо иметь сниппеты разметки для фрагментов форм (текстовое поле, радиокнопка etc.)

Игнорирование кодгайда

Даже если вы работаете как фрилансер, нужно выбрать и соблюдать единый кодгайд на всех проектах. Код должен быть красиво форматирован и написан с соблюдением четких правил, поскольку это:

• упрощает поиск ошибок,
• снижает вероятность поломки при модификации,
• ускоряет чтение кода.

Примеры кодгайдов: руководство по написанию кода школы Epic Skills (целиком написано мной), Стиль кода Академии HTML (немного приложил руку), Code Guide by @mdo (кодгайд от Марка Отто (автор Bootstrap), именно этим материалом вдохновлены две предыдущие ссылки).

Работа без БЭМ

Если сравнивать методологии, серьезных конкурентов у БЭМ нет: самодокументирование и имитация пространства имен впервые появились именно в нём. Я коротко описал свои принципы работы с этой методологией тут: Как работать с CSS-препроцессорами и БЭМ. Полный стек лично у меня не прижился, главным образом из-за скорости работы его инструментов. Сейчас я использую что-то отдалённо напоминающее инструменты полного стека.

Реальными альтернативами БЭМ могут считаться веб-компоненты (дают, в числе прочего, настоящую изоляцию), но им нужна поддержка браузеров, которая пока плохая. Ещё есть CSS-модули, но они требуют особого инструментария и применимы не на всех проектах.

Игнорирование семантики тегов

Часть тегов универсальны, часть имеют семантику (разной степени). К примеру, есть div — универсальный блок, а есть section — часть чего-либо (к примеру, большого «подвала»), которая при вырывании из контекста частично теряет смысл, и есть article — блок с наиболее выраженной семантикой (будучи вырван из контекста, сохраняет осмысленность полностью).

Всегда нужно применять наиболее подходящие по смыслу теги: списки, таблицы, параграфы, заголовки и пр. должны использоваться по назначению. Это улучшает индексацию сайта (и вообще понимание страницы роботами) и доступность.

Истиной в последней инстанции в вопросе использования тегов является спецификация.

Игнорирование и подмена функциональности тегов

Пример: если на странице есть флажок (чекбокс) и текст рядом, клик по тексту должен менять состояние флажка. Увы, не всегда это так. Встречал решения, когда автор страницы с помощью JS отлавливает клик и по такому событию проставляет/снимает отметку, вместо использования тега label, связанного с input-ом. (Сам предпочитаю писать input внутри label.)

Гораздо чаще, впрочем, встречаюсь с подменой ссылки на кнопку (и наоборот) или даже на какой-либо изначально неинтерактивный элемент. Не делайте так, это осложняет управление страницей без мыши и ухудшает доступность.

Именование классов транслитом, КАПС, избыточные сокращения в классах

Транслит — это странно (столь же странно, как веб-разработчик без знания английского языка). КАПС бывает применим лишь в тестовом режиме (имена классов со словами TEMP, TODO и подобными) и в случае блондинистости автора.

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

И транслит, и КАПС, и избыточные сокращения снижают скорость чтения (да и чисто эстетически это — не то, что вы хотите видеть в коде).

Дублирование блоков для представления на разных размерах вьюпорта

Бывает, что фрагмент страницы показывается в разных местах макета на разных ширинах. Нередко удается сверстать страницу с таким фрагментом без дублирования (более всего помогает свойство order, в меньшей степени — абсолютное позиционирование (проблемы с переполнением)).

Самый печальный пример такого дублирования — главная навигация, представленная в разметке в варианте для «мобильных» и в варианте для «настольных» (чуть дольше грузится, возможны проблемы с фокусом на ссылках, сложно использовать Critical Path и пр.).

Используйте дублирование разметки только если никакие другие способы не позволяют реализовать задумку дизайнера.

Работа без процессинга разметки

Для средних по размеру проектов я считаю важным использовать процессинг разметки. Простейшим вариантом было бы написание разметки повторяющихся фрагментов в отдельных файлах и вставка их в нужные места при сборке страниц (простейший способ: gulp-file-include).

Примеры включаемых фрагментов разметки:

• код внутри head (не весь) и перед /body, где подключаются общие ресурсы,
• «шапка» и «подвал»,
• карточка товара, выводимая несколько раз на нескольких страницах,
• блоки, из которых набираются формы,
• модальные окна, присутствующие на большинстве страниц.

При включении можно передавать в подключаемый файл какие-либо данные (название товара, цену, имя поля формы и пр.).

Однако есть и более продвинутые варианты с HTML-процессорами. Один из самых известных — Pug. Переменные, циклы, экстенды, инклуды, примеси и пр. позволяют комфортно работать с проектами, в которых много повторяющихся частей и более двух общих раскладок блоков по странице. Минусами может стать синтаксическая табуляция и некоторые сложности с выведением пробельных символов между строчными тегами.

Читать далее: Ошибки и спорные моменты стилизации