Как оценить качество html-верстки
12-10-2018Время чтения ~ 9 мин.CSS, HTML, LESS, SASS 6341
В процессе обучения на html-курсах у меня постоянно возникает потребность оценивать качество html-верстки учеников. Данная тематика очень большая и неоднозначная: о неё спотыкались почти все, что так или иначе использует чужой код. Некоторые компании придумывают сложные чек-листы, чтобы хоть как-то форматизировать свои требования. Другие, наоборот, упрощают подход: сайт «не разваливается», уже хорошо. :-)
Обычно смотрят сразу на весь сайт, поэтому часто возникают требования имеющие лишь второсепенное отношение к html-верстке. Например использование H1-заголовка и SEO-оптимизация. В данном случае верстальщик не обязан знать всю контекстную составляющую сайта, а в большинстве случаев, это даже неизвестно. Например в шаблонах CMS наполнением занимается конечный пользователь.
Существуют и другие, совершенно «безумные» требования, вроде запрета использовать !important в CSS. То что это стандарт CSS, автор требования, видимо, не в курсе. Или только один css-файл на все страницы. C учётом lazy-загрузки данное требование можно трактовать исключительно как «вредное»...
Потихонечку я пришел к выводу, что оценивать html-верстку нужно в основном по качеству кода. Причем код бывает двух видов: первый — исходный, второй — готовый (скомпилированный).
Скомпилированный код формируется автоматически, а значит к нему нельзя выставлять никаких требований, вроде красивого оформления, отступов и т.п. Готовый код мы не можем использовать для оценки, поскольку это просто неудобно и нечитабельно. Хотя нет никаких сложностей пропустить его через онлайн-автоформатирование с любым понравившимся вариантом и получить красивый текст.
На сегодняшний день существует только одно требование: готовые файлы должны быть минимизированы, а значит физически отделены от исходных. Когда верстальщик сдаёт работу, то в комплект в обязательном порядке должны входить и исходные файлы.
К исходным файлам уже можно предъявить требование по форматированию кода. Здесь самое главное — это обеспечить высокую читабельность. Обычно речь идёт об отступах, которые формируют визуальные блоки. Будут ли это пробелы или табуляторы — не имеет никакого значения, хотя табулятор проще и для использования и настраивается в любой кодерской программе (то есть у верстальщика и проверяющего могут быть разные настройки по своим предпочтениям, пробелы же фиксированы).
Стиль кодирования желательно использовать какой-то общепринятый. Здесь также разные варианты, главное, чтобы начинающий верстальщик ознакомился с разными вариантами и стал их применять на практике.
Всё это приводит к первому важному критерию оценки: код должен быть аккуратным и читабельным. Неряшливость кода — больше демонстрирует неуверенность и неумение его создавать.
Хорошо оформленный код ещё ничего не говорит о его качестве. Например верстальщик написал css-класс из 10 стилей и красиво его оформил. Если на странице таких классов несколько десятков/сотен, то никто не будет проверять каждый стиль: скажем вместо padding нужно было использовать margin, а для выравнивания использовать не float, а flex. Погружаться в код, чтобы его полноценно изучить,- потребуется не только соответствующая квалификация проверяющего, но и немалого времени. Чтобы упростить эту задачу кодер, по возможности, должен комментировать свой код.
Поэтому следующий критерий — комментирование своего кода. Особенно это важно, когда известно, что код будут проверять или менять в будущем. Обычно при верстке комментарии размещаются в css/sass-файле, но не везде, а только там, где необходимо уточнить смысл (отвечать на вопрос «для чего это сделано?»). В PHP комментирование вообще является обязательной практикой, включая описание функций, параметров, алгоритма и т.п. В HTML комментирование не так актуально, но всё-равно в некоторых случаях это необходимо.
Покажу на простом примере с использованием атомарных классов Berry CSS. Вот такой простой блок (можете его загрузить в Builder и проверить):
<div class="bg-gray pad20"> <h3 class="bg-green mar0">Заголовок</h3> <div class="mar20-t">Текст</div> </div>
Здесь может возникнуть вопрос зачем верстальщик использовал класс mar0 (это margin: 0)? На самом деле это нужно, чтобы обеспечить 20px отступ, который задан у родительского блока, ведь H3 имеет ещё и свой 10px верхний отступ. Если померить линейкой, то без mar0 отступ окажется больше. Это неочевидный момент, который можно легко упустить из виду. Более того, может возникнуть ощущение, что css-класс вообще лишний. Но верстальщик сделал «пуленепробиваемый» код, где H3 можно заменить на любой другой тэг. Осталось только указать это в комментариях. Теперь код не только хорошо читается, но и понятен его смысл:
<div class="bg-gray pad20"> <!-- Обнуляем отступы, чтобы они определялись только родителем. Можно использовать другой тэг заголовка. --> <h3 class="bg-green mar0">Заголовок</h3> <div class="mar20-t">Текст</div> </div>
При этом описывать смысл bg-green или bg-gray нет необходимости — это очевидные классы, используемые по своему прямому назначению.
Другой критерий — это понимание основ HTML. Например при html-верстке использование BR вместо P — будет большой ошибкой. Также довольно большая проблема — «новые» семантичные html-тэги, вроде SECTION, ARTICLE и т.п. Использование данных тэгов всегда сопряжено с риском нарваться на критику по их неверному использованию. Верстка — это в первую очередь положение элементов, а семантика обычно требуется на уровне SEO. Поэтому более надежней будет верстать на «обычных» тэгах, а семантику расставлять на заключительных этапах, в зависимости от пожеланий клиента.
Ещё очень важно понимать структурный подход к html-верстке. Современная верстка — модульная, где каждый блок представляет собой некий «компонент» и в идеале должен без каких-либо переделок менять своё положение на странице. Такой подход базируется на разделении модульной сетки сайта от составляющих её блоков. Модульная сетка — это каркас, фундамент, который отвечает только за компоновку главных блоков. В CMS обычно это шапка, подвал, основной контент-блок и сайдбары. При этом модульная сетка может содержать общий контейнер для всех этих блоков — это необходимость, если нужно визуально их объединить (тень, фон или граница).
Очень часто верстальщики смешивают модульную сетку с внутренними блоками, иногда до фатальных зависимостей. Вместо этого нужно стремиться к тому, чтобы модульная сетка могла вообще меняться произвольно без переверстки внутренних блоков. Чем меньше между блоками/кодом зависимостей, тем лучше.
Отдельно стоит отметить верстку лендингов, где часто нет общего контейнера и модульной сетки как таковой (точнее это один общий BODY). Здесь верстальщик должен понимать, что каждый блок лендинга должен быть сверстан так, чтобы мог поменять своё положение на странице. Особо интересны случаи, когда блоки могут занимать разную ширину: в центре по всему браузеру, по центру с ограничением, по краям браузера и т.п. В этом случае модульная сетка как раз и описывает такое расположение, а внутреннее содержимое отвечает за поведение внутри этого контейнера.
Если блок не имеет своего layout-контейнера, то такой код «грязный». И хотя формально он может быть красивым и все стили на месте, но его поддержка и последующая переделка потребует больших усилий. Если такую работу будет выполнять уже другой верстальщик, то ему будет проще всё сделать с нуля самому, чем переделывать чужой код (правда не факт, что он сделает лучше ;-) ). Если верстальщик понимает структурный подход, то таких проблем просто не возникает.
Существуют ли критерии оценки качества CSS-кода (вне описанных выше критериев)? Здесь всё сложно... CSS позволяет решать задачи разными способами, поэтому сказать, что какой-то вариант лучше другого, проблематично. Единственным вариантом, пожалуй, будет выбор в пользу более простого и понятного кода. Если нужно задать отступ, то используем margin или padding, но не line-height. Первые простые и понятные, второй более сложный и не такой очевидный. То есть по возможности css-код должен быть как можно проще.
Мне иногда приходится разбирать сложные css-классы, где ученики использовали с десяток стилей. Как правило это обычное copy/paste с какого-нибудь старого сайта. Объяснить зачем нужные те или инные строчки ученик не может: если код работает, то вроде как всё правильно. Но потом оказывается, что такой код излишний, а задачу можно было решить гораздо проще, нужно было просто над ней подумать.
При именовании css-классов нужно придерживаться какого-то одного стиля или методики. Если всё в разнобой, неявные имена классов, то такой код «грязный» потому что его будет сложно поддерживать. Представьте себе, что этот код будет переделывать другой верстальщик, а значит он должен его понять. Львиная доля времени уходит не на исправление/доработку css-кода, а на поиск его классов в html-коде и sass-файлах.
Именно поэтому верстальщики массово и переходят на Atomic CSS.
Выбор методики — индивидуальные предпочтение, хотя во многих конторах будут свои требования по этому поводу, включая, например запрет на использование транслитерации.
В современных реалиях верстка должна быть адаптивной. Поведение блоков нужно задавать для разной ширины экрана и обязательно проверять в браузере (Ctrl+Shift+M в FireFox). Настройка адаптивности порой занимает больше времени, чем для обычного десктопа. Часто это приводит к появлению дополнительных css-классов, которые не всегда очевидные с первого взгляда. Верстальщик, после того, как настроил десктопную версию, должен отработать меньшие экраны. Если появляется горизонтальный скроллинг, это значит, что адаптивность скорее всего вообще не настраивалась. Бывают, конечно, сложные блоки, но горизонтальный скролл недопустим.
Затрагивая адаптивность, нельзя не упомянуть о требовании pixel perfect. С моей точки зрения попиксельное соответствие макету возможно, но с рядом оговорок — дизайнер должен проработать все экраны, а также использовать рендеринг шрифтов, скругления, тени и прочие дизайнерские элементы как в браузерах, а не как это делает фотошоп. Потому что когда дизайнер предусмотрел отступ 8px, а размер шрифта 14.8px при непонятном интерлиньяже, то «пиксель перфект» превращается в откровенный мазохизм.
Адаптивность — это «резиновая» верстка, где описывается поведение элементов (выравнивание, отступы и т.д.), причём часто на произвольных текстах и иконках. Задать здесь точные пиксельные размеры уже проблематично, поэтому на сегодняшний день требования к pixel perfect обычно сводятся к «как можно ближе к макету». Если перевести на числа, то в больших блоках (более 50px) точность 10..20px, а на малых 5..10px, вполне достаточна. Поэтому я думаю, что требование к pixel perfect на сегодняшний день мягко говоря неактуальна. В реальности такая точность просто не нужна.
Вот, собственно, и все критерии. Мало, потому что это все имеет непосредственное отношение к работе верстальщика. Всё остальное — это методики и инструменты. Нет никакого смысла обсуждать и требовать html-валидации кода — это и так очевидно. Нет никакого смысла указывать на необходимость использования resets.css или normalize.css — это очевидно даже новичку. Нет никакого смысла указывать на необходимость тестирования верстки на разных экранах — это даже не сколько тестирование, сколько непосредственный процесс верстки. В лучшем случае все эти дополнительные требования можно оформить в виде чек-листа, благо Интернет ими заполонён.
Впрочем возникает ещё один вопрос: как оценить профуровень самого верстальщика? Скорее всего лучшим способом будет его тестирование. Но не опросник/анкета, а практическое задание на верстку каких-то блоков или небольших страниц с обязательным комментированием своего кода. Можно усложнить задачу, например выдвинув требование на использование какого-то css-фреймворка или, наоборот, только свой «ручной» код. Такое тестирование может показать реальный уровень подготовки и способность решать поставленные задачи.