Несмотря на низкий порог вхождения, вёрстка является важным этапом в создании любого интернет-проекта. Качество вёрстки влияет на будущие трудозатраты:
- Насколько просто и быстро можно внести правки, особенно другой человек.
- Насколько она пригодная для SEO, и не потребуется ли её адаптировать отдельно.
- Насколько она валидная и кроссбраузерная, чтобы не терять клиентов, пользующихся другими браузерами.
И в этой статье я собрал основные требования, которые стоит предъявлять к вёрстке. Некоторые моменты также следует проконтролировать во время разработки дизайна и бэкенда.
1 Адаптивная вёрстка
Экраны посетителей всегда различались разрешением, цветопередачей, и плотностью пикселей на дюйм и другими параметрами. Но возможности проверить сайт абсолютно на всех возможных устройствах и при всех комбинациях настроек очень сложно. Но альфа-тестирование вёрстки упрощается с возможностями Chrome DevTools, где можно имитировать различные условия.
При ручном поверхностном тестировании я обычно учитываю реальную статистику, которая есть в открытом доступе.
Также есть онлайн-сервис от Google: search.google.com/test/mobile-friendly
2 Валидность HTML/CSS
Следование стандартам гарантирует корректный разбор вёрстки в браузерах. И даже если сайт отрисовался правильно в вашем браузере, и всё совпадает с макетом, то есть несколько нюансов, которые могут проявить себя в перспективе, ведь стандарты берутся не с потолка. К тому же, валидность вёрстки является одним из большого числа факторов ранжирования поисковых систем.
Проверить валидность HTML: validator.w3.org/nu/
Проверить валидность CSS: jigsaw.w3.org/css-validator/
3 Валидность CSS
Кроме официальных валидаторов W3C, которые проверяют лишь соответствие стандартам, существуют также сервисы, которые произведут анализ CSS-файлов и дадут советы по их оптимизации и организации.
- https://www.testmycss.com/
- https://csslint.net/
- https://www.onlinewebcheck.com/check.php
- https://www.cssanalyzer.com/
- https://www.quertime.com/article/top-20-online-tools-to-optimize-and-audit-css-codes/
Лично мне раньше нравился первый сервис.
Потом я стал устанавливать и использовать линтер локально, чтобы проверять CSS прямо во время разработки. Есть несколько популярных решений, я обычно использую stylelint.
4 Кроссбраузерность
Традиционно у верстальщиков установлены все популярные браузеры, каждый из которых имеет своеобразные особенности (разные движки, разные версии).
Ситуация упрощается тем, что большинство популярных браузеров работают на меньшем количестве движков, поэтому нет особой разницы между тестированием в Chromium и Яндекс.Браузере. Но вот Firefox и Safari требуют отдельного тестирования.
Кстати, тестировать в Safari получится только под MacOS или iOS, так как под Windows этого браузера давно нет.
А на помощь снова приходит статистика:
Что можно посоветовать верстальщикам: использовать autoprefixer и быть в курсе, какие фичи CSS поддерживаются целевой аудиторией проекта.
Есть ещё BrowserStack, где можно протестировать сайт на огромном количестве платформ и браузеров, но бесплатный период очень короткий, а цены могут превысить бюджет на вёрстку.
5 Вариативный контент
Часто при разработке дизайна упускается важный момент — содержимое может быть различного объёма (разрешение изображения, количество символов текста и т.д.). Анонс новости может быть не только в 4 строки, как красиво нарисовал дизайнер, но и в 3 или 5. Изображение в слайдере, загруженное контент-менеджером, может вдруг оказаться не эталонного размера или не с теми пропорциями, как нарисовано в макете, или вообще повёрнутым на 90 градусов. Или вообще не существовать.
Именно такие моменты и должен предусмотреть верстальщик. Дизайнер, конечно, тоже должен учесть такие ситуации и явно отобразить это в макете. Некоторые вещи также обычно принято решать и на стороне сервера, например, генерация миниатюр нужного разрешения и вывод изображения-заглушки, но хорошим тоном считается предусматривать это и на уровне вёрстки.
По отдельной договорённости верстальщик может предусмотреть такие ситуации, когда целые блоки сайта (шапка, подвал, новости, слайдер и пр.) могут скрываться или меняться между собой местами. В данном случае крайне желательно, чтобы из-за обмена местами двух блоков не поехали отступы.
6 Выбор фреймворка
Фреймворки служат для ускорения разработки. Самым популярным фреймворком является Bootstrap, который содержит множество готовых типовых решений (сетка, кнопки, типографика, формы, модальные окна и пр.).
Но у этого удобства есть обратная сторона — объём данных. Использование фреймворков может замедлить работу сайта, что особенно заметно на мобильных устройствах или при медленном соединении. Хотя, имея на руках исходники Bootstrap, можно собрать кастомную версию, содержащую только нужные модули.
7 Автоматизация
Если верстальщик использует препроцессоры (sass, postcss и пр) и средства автоматизации (webpack, gulp, grunt), то вам дважды повезло. Во-первых, это говорит о том, что верстальщик, вероятнее всего, хороший. Во-вторых, сопровождение проекта в таком случае становится проще.
Но если проект будет переходить из рук в руки, то стоит предупреждать последующих исполнителей об этом.
Был у меня случай, когда заказчик попросил внести правки на сайте. Я помнил, что при вёрстке сайта я использовал gulp и postcss, и уже было согласился, как вдруг заметил, что после меня этим сайтом уже занимался другой человек, который вносил правки не в исходники, а в итоговый бандл. И если бы я внёс правки в исходники, то изменения предыдущего умельца в бандле потерялись бы.
8 Производительность
Стоит с умом подойти к разработке дизайна и не увлекаться параллаксами, анимациями и прочими визуальными эффектами. Просмотр диафильма вместо плавной анимации может испортить впечатление от сайта.
9 Семантика
Если верстальщик лепит всё на одних div-ах, то это плохой верстальщик.
Интерактивные элементы вроде кнопок стоит реализовывать с помощью тега button, а не div или span. То же касается ссылок (a), выпадающих списков (select), навигации (nav), списков (ul, ol с элементами li внутри), article, header, footer, h1, h2 и так далее. Несоблюдение рекомендаций может плохо сказаться на SEO.
В таком случае будет проще осуществлять навигацию посредством клавиатуры или программ для слабовидящих (JAWS, NVDA и VoiceOver). Про доступность у меня отдельная статья: https://quasi-art.ru/library/it/the-web-accessibility-basics.
10 Методология
В основе вёрстки должна быть какая-то методология именования классов. Она позволяет держать стили в порядке. Бывает такое, что цвет кнопки хочется изменить только в одном месте, а в итоге меняются все кнопки, да ещё и цвет ссылок — нарушена специфичность и сопровождабельность (maintainability). Самой известной методологией является БЭМ от Яндекса.
