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

Часть 1: общие и методологические

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

Общие, методологические

Некритичное восприятие материалов, наподобие этого

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

Важный момент: всегда оценивайте аргументацию, ибо любое утверждение, выдвинутое без аргументов, может быть отброшено без аргументов.

Повтор ошибки

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

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

Игнорирование новостей и тенденций

Одно из важных качеств любого специалиста — кругозор (спасибо автору фразы, Алексею Симоненко). Поток новой информации титанический: новые фреймворки, спецификации, возможности браузеров, записи выступлений на конференциях и прочее.

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

Следование новым веяниям без достаточных оснований

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

Пример: статьи о том, что jQuery никому не нужен и всё можно сделать без него. Это, отчасти так, однако важно понимать: jQuery уместен во многих ситуациях (разработка с учетом древних браузеров, необходимость использовать несколько jQuery-плагинов, отсутствие на проекте React/Angular/Vue), прост в освоении, имеет огромное сообщество и экосистему.

Вы можете бесконечно любить React, но что в этом толку, если у заказчика IE8… (Да, да, в 2017-м году он еще встречается в тех. заданиях при работе над внутренними корпоративными сервисами и, полагаю, над муниципальными проектами).

Вера веб-евангелистам

Я со смешанными чувствами воспринимаю некоторые заявления веб-евангелистов, звучащие оторвано от практики (моей практики (проекты средних размеров: 5-30 страниц, 20-150 блоков)). В самом печальном случае это выглядит как «парадокс веб-евангелиста»: учит других тому, чем сам не занимается.

Пример: не использовать систему сборки и процессинг стилей в процессе разработки, собирать только «перед продакшеном», ведь и импорты, и переменные (custom properties) уже есть в CSS, можно переслать любому участнику проекта архив и это будет работать без всяких NodeJS, компиляции Sass и прочего. Звучит отлично. Для «сайтов хомяка», над которыми, почему-то, трудится команда из более чем из 2-х человек. Насколько удобно при этом тестировать кроссбраузерность (в т.ч. на других устройствах) — ясно (про пересылку архива во времена существования Github pages промолчу). По поводу сборки у нас с Александром Першиным (он не веб-евангелист, кстати) состоялась весьма любопытная и продуктивная дискуссия в комментариях в ВК.

Другой пример, упомянутый одним англоязычным разработчиком: «если css-grids в браузере не работают, пользовательский опыт не обязательно будет негативным, он просто будет другим». Как именно такой «другой опыт» будет воспринят заказчиком — нетрудно предположить. Тут можно возразить, что раскладок не так уж много, можно сверстать их на флексах, улучшить гридами, отдебажить и использовать, однако любая модификация означает необходимость тестировать уже не одну технологию, а две. Причем, непонятно зачем в такой ситуации css-grids.

Повторюсь: если вам предлагают какой-то новый подход, изучите его и со стороны накладываемых ограничений, вероятных проблем. Решите стоят ли они получаемой выгоды, ускоряет ли это работу, способствует ли упрощению модификации проекта.

Вера анонимам и кликабельным заголовкам

Не верьте анонимам. Находя ответы на форумах, смотрите кто отвечал и каков рейтинг ответа (пример: рейтинг ответов на stackoverflow.com). Увы, даже при высоком рейтинге ответ может содержать чушь (вероятность несколько ниже).

Статьи с названиями «20[любая цифра] лучших[превосходная степень] плагинов[инструментов/решений/способов_что-то_сделать] для [что-то]» должны вас настораживать. По крайне мере, среди инструментов, обычно, есть 1-2 (редко больше) хороших решений, одно из которых наиболее мощное и универсальное, расширяемое, имеет развитую экосистему, большое сообщество и пр. Прочие — либо узкоспециализированные, либо ощутимо хуже.

Отсутствие анализа альтернативных решений

Выбираете какой-либо инструмент (галерея фотографий, оптимизатор CSS, линтер JS etc.)? После анализа возможностей посмотрите как его оценивают представители сообщества Проще всего с репозиториями на Github (см. кол-во звездочек) и npm-пакетами (см. кол-во установок). Так же, стоит поискать статьи и видеообзоры сравниваемых инструментов (часто комментарии к материалу не менее интересны, чем сам материал). Не лишним будет оценить и активность разработки инструмента.

В моей практике анализ альтернатив несколько раз приводил к заимствованию/портированию возможностей и почти всегда — к расширению знаний.

Отсутствие тестов на кроссбраузерность

Смертный грех веб-разработчика: не определить целевую аудиторию и, соответствено, необходимую кроссбраузерность. Прямой путь в ад к отсутствию работы по причине чудовищно скверной кармы репутации.

Тактика тестирования незамысловата: верстаем под самый распространенный в ЦА браузер (при прочих равных сейчас это Chrome), далее проверяем под прочими в порядке уменьшения распространенности. Безусловный лидер — IE. Далее по частоте возникающих проблем в моем рейтинге Safari (как мобильный, так и настольный) и Firefox.

Технологически для настольных «зеленых» браузеров проблем нет, для IE и Safari лучше использовать виртуальные машины с отдельными ОС и конкретными версиями. Мобильные лучше тестировать или на реальных устройствах, или в эмуляторах. Так же, есть замечательные платные сервисы, самый известный — browserstack.com.

Бездумное подключение шрифтов

Пока нет хорошей кроссбраузерной поддержки font-display и/или поддержки font loading api, с подключаемыми к странице шрифтами у нас есть некоторые проблемы (FOUT/FOIT/FOFT), не стоит усугублять их некорректной очередностью подключения форматов или неоправданно большим размером файлов шрифтов.

Помните, запросы за шрифтами по умолчанию «поздние», но эту сложность можно обойти (почти без костылей или с костылями в мундире JS). Хорошая статья по теме

JS-анимации там, где можно обойтись CSS-анимацией

Есть холивар: какие анимации лучше, сделанные на JS или на CSS? Я сторонник CSS-анимаций (там, где это возможно), особенно, когда можно переложить подсчеты таких анимаций с CPU на GPU (то есть, подсчет будет выполняться вне основного потока, который может быть забит другими задачами, а область перерисовки страницы будет минимальной).

CSS-анимации будут обсчитываться на графическом процессоре, если aнимируются opacity и/или transform , у элемента есть transform: translateZ(...) , на родителе есть filter , фрагмент спозиционирован по z над другим фрагментом и в некоторых других случаях. Видео отличного доклада по теме

Работа без git

Git — простая система контроля версий, «машина времени» для вашего проекта. Позволяет в ходе рабочего процесса «сохраняться» как в играх. Можно использовать в терминале или через приложение с GUI. Уберегает от потери кода (можно откатиться к любому «сохранению»), облегчает синхронизацию между вашими рабочими машинами и/или членами команды, и многое другое. Плейлист с короткими и толковыми скринкастами про git

В паре с Github или Gitlab обрастает множеством приятных мелочей, типа код-ревью, построчного комментирования изменений и возможности показывать клиенту готовую вёрстку по ссылке.

Высокомерное отношение к фреймворкам для верстки

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

Bootstrap, Foundation и прочие (сравнительная таблица фреймворков) фреймворки хороши, когда нужно быстро и недорого сделать сайт стартапу, сделать админку или какой-то закрытый проект, но они гораздо полезнее при изучении верстки, поскольку многое в том же Bootstrap сделано хорошо или очень хорошо (лично у меня главные претензии к нему — отсутствие БЭМ-а и переусложненный код в препроцессорных файлах).

Однако, если у проекта есть дизайн, использование фреймворка может не столько ускорять вёрстку, сколько затруднять ее, если дизайнер не использовал элементы фреймворка при работе.

Отсутствие автоматизации рутинных задач

Неполный список возможностей автоматизации:

  • сборка HTML (с шаблонизатором или с простой вставкой HTML-фрагментов),
  • обработка стилей (компиляция Sass/LESS/Stylus, постпроцессинг с PostCSS),
  • сборка спрайтов и SVG-библиотек,
  • оптимизация разметки/стилей/изображений/скриптов,
  • менеджмент зависимостей для JS,
  • автопроверка валидности и кодгайда,
  • локальный сервер (пересобирающий то, что вы толькочто модифицировали и обновляющий страницу в браузере, позволяющий открыть страницу с любого устройства внутри локальной сети).

Но можно использовать лишь редактор и браузер. Если у вас много свободного времени.

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

Отсутствие оптимизации

В работе веб-проектов довольно много узких мест, как в области сетевой передачи (сейчас, в эпоху HTTP1, главное: 1 файл = 1 отдельное соединение с сервером), так и на стороне браузера (нюансы скорости работы JS, отправка запросов за ресурсами, кеширование, баги/фитчи интерпретации CSS и пр.)

Сейчас (осень 2017) мы стараемся передавать как можно меньше файлов и делать сами файлы меньше. У меня нет уверенности, что до повсеместного внедрения HTTP2 хоть что-то изменится.

Отсутствие заготовки стартового проекта(ов) для типовых задач

Приятно и быстро начинать проект со знакомой заготовки с привычным окружением и инструментами. Еще лучше, если в такой заготовке есть ваша кросспроектная библиотека компонентов. Без такого стартового проекта придется каждый раз «изобретать велосипед».

Уделите некоторое время на описание своего стартового проекта, чтобы сторонний разработчик тоже мог запустить его у себя — это позволит другим специалистам продолжить работу над проектом, когда вы его покинете.

Моя заготовка для несложных проектов по вёрстке и демка её блоков.

Игнорирование проблем дизайна

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

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

Если возможно, стоит исправлять подобные сложности и/или обращать на них внимание дизайнера и заказчика.

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

Игнорирование SEO

В разрезе вёрстки это можно сформулировать как игнорирование семантики. Главное, что вы можете сделать для будущей «раскрутки» сайта — использовать семантически подходящие теги и не использовать неподходящие. Второе по важности — добавлять метатеги для соц. сетей. Если среди читателей будут SEO-специалисты, прошу поправить меня.

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

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

Слепое следование методологии или необоснованный отступ от неё

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

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

Переусложнение/переупрощение рабочего процесса

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

  • Сборка разметки (простейшее включение фрагментов в страницы при сборке («шапка», «подвал» и другие неизменные части вставляются на страницу) или несложный препроцессинг, к примеру, с Pug).
  • Обработка стилей (пример: Sass как наиболее функциональный (и живой) CSS-препроцессор, плюс постпроцессинг с плагинами PostCSS). Акцентирую: Не пытайтесь программировать на CSS-препроцессорах! Особенно если не умеете программировать.
  • Сборка растровых спрайтов и SVG-библиотек (svg>symbol ).
  • Минификация стилей/скриптов/изображений/шрифтов.
  • Локальный сервер, позволяющий открывать папку сборки как сетевой ресурс по HTTP.

Отсутствие знаний о работе браузеров

Трудно переоценить знание того, как работает ПО, через которое посетители смотрят результат вашей работы. Как и когда загружаются ресурсы, как показываются векторные объекты, какие события происходят при изменении разметки скриптами, какие возможности HTML/CSS/JS поддерживаются, не поддерживаются или работают криво — знание таких особенностей помогает как в устранении проблем, так и на этапе оптимизации.

Заключение

Вероятно, для вас более заметны и актуальны какие-то другие ошибки. Напишите в комментариях какие именно.

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

Понравилась статья? Ставьте лайк, делитесь в соц. сетях или купите мне кофе.