Школа
Веб-разработка

Принципы надёжной вёрстки

31 окт 2019
👁 10690   🗩5
Веб-разработка

Принципы надёжной вёрстки

31 окт 2019
👁 10690   🗩5
Юрий Мазурский
Разработчик и дизайнер
Полезно
 19
19
Непонятно
 1
1
Войдите в Бюросферу, чтобы голосовать

Мы рассмотрели несколько приёмов, как упростить себе задачу вёрстки ХТМЛ‑страницы. Пришло время расширить и обобщить эти приёмы и сформулировать универсальные принципы надёжной вёрстки. Почему именно надёжной? Потому что вёрстка — очень текучая субстанция, которая должна адаптироваться к большому количеству условий, и надёжность — её критичное качество. Страница не должна разваливаться ни при каких обстоятельствах и должна работать на любых устройствах и ширинах экрана.

1. Учитывать иерархию макета

Иерархия блоков в вёрстке должна совпадать с логической иерархией дизайн‑макета. Практически всегда любой блок подчинён другому или зависит от каких‑то параметров родителя.

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

2. Разделять ответственность элементов

Каждый элемент может выполнять несколько функций на разных уровнях. Обычная ссылка в тексте ведёт на другую страницу. Но пункт меню одновременно и ссылка, и элемент, который должен располагаться в определённом месте в шапке сайта.

Допустим, наш пункт меню выглядит как любая другая ссылка на сайте. Как его спозиционировать? Можно спозиционировать сам элемент a внутри шапки, а можно добавить к нему обёртку и делегировать функцию позиционирования ей. В первом случае придётся «загрязнять» стили элемента ссылки параметрами позиционирования. Во втором мы разделили ответственность ссылки и её обёртки.

Ссылка — рок‑звезда, а обёртка — водитель, который доставит её в нужное место в шапке.

Всё в одном элементе
<a href="/contacts" class="menuLink">Контакты</a>
Ответственность разделена
<div class="menuItem">
  <a href="/contacts">Контакты</a>
</div>

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

3. Минимизировать количество кода

Один и тот же блок можно сверстать разными способами. Нужно всегда выбирать способ, при котором будет задействовано минимальное количество разметки и стилей. Периодически полезно пересматривать старые куски кода — возможно с развитием продукта и технологий вёрстку можно упростить.

Вопросы, которые стоит задавать себе:

  • Можно ли уменьшить вложенность элемента?

  • Можно ли стандартизировать стили похожих элементов?

  • Можно ли использовать сокращённые ЦСС‑свойства?

4. Структурировать код

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

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

Плохо
<form><label>Электронная почта</label><input type="text" value="" />
<button class="button_blue"><b>Зарегистрироваться</b></button></form>
Хорошо
<form>
  <label>Электронная почта</label>
  <input type="text" value="" />
  <button class="button_blue">
    <b>Зарегистрироваться</b>
  </button>
</form>

Например, БЭМ

Для повышения осознанности перед началом проекта стоит выбрать правила именования компонентов и форматирования кода и строго придерживаться их, даже если кажется, что в отдельном месте «и так всё понятно».

Например, БЭМ

5. Не использовать инлайновые стили

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

6. Сверяться с макетом

PerfectPixel — расширение для Хрома, которое накладывает картинку поверх страницы. С его помощью можно буквально подгонять вёрстку под макет.

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

PerfectPixel — расширение для Хрома, которое накладывает картинку поверх страницы. С его помощью можно буквально подгонять вёрстку под макет.

P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.

Веб‑разработка
Полезно
 19
19
Непонятно
 1
1
Войдите в Бюросферу, чтобы голосовать
Отправить
Поделиться
Поделиться
Запинить
Твитнуть

Комментарии

Евгений Арутюнов

«Верстать на глаз нельзя»

А я думаю, что можно, и даже необходимо. Только нужно затачивать глаз. Но глаз нужно затачивать в любом случае, не только для вёрстки. (Затачивается он в том числе вёрсткой «пиксель в пиксель», поэтому запретить конкретному отдельно взятому новичку верстать на глаз — это нормальная практика.)

Принцип «не верстать на глаз» подразумевает, что макеты нарисованы дотошно и во всей полноте ситуаций. Но рисовать такие макеты — сомнительное дело. Я за то, чтобы макеты были нарисованы в минимально достаточном виде: с целью ухватить какую‑то эстетическую находку, обсудить поведение, понять главное. Чем быстрее вы переходите от картинок к вёрстке и дальше к продукту — тем быстрее вы переходите от фантазий к реальности.

Маленькие штучки лучше рисовать красиво и верстать потом «пиксель в пиксель». Они более критичны к точности пропорций и меньше влияют друг на друга.

Лейаут страницы и всякие прямоугольные модульные сетки лучше сначала рисовать, как рисуется, чтобы не загонять себя в рамки какой‑то колоночной математики. А затем собирать заново, поглядывая на макет, но руководствуясь логикой адаптивности. То есть, я буквально предлагаю на этапе рисования макета «забыть» про всю адаптивность и резиновость, забыть даже про вертикальные размеры экранов, про «что помещается», «что куда приклеивается», как там оно ведёт себя при скролле. А «вспомнить» только в процессе вёрстки — который должен наступить как можно раньше.

Хорошо, когда label с for или является обёрткой для инпута, который он описывает.

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

Точно верстать на глаз сразу же не получится, нужно тренироваться, как вы и написали. Разумеется, опытные верстальщики значительную часть макетов так и верстают. Принципы нужны, чтобы не забыть про важные аспекты вёрстки. Если вы уверенно ставите элементы на глаз, конечно нет никакого смысла в механическом выполнении этого пункта.

При «утилитарном» подходе к вёрстке классы CSS отражают общие «функции», а не оформление какого‑либо отдельного логического элемента:
https://tailwindcss.com/docs/utility-first/

Иногда проект создаётся годами. И CSS‑стилей становится так много, что новичку уже тяжело разобраться, что есть и что для чего использовать. Даже бывает, что и про БЭМ никто не знает. Тогда inline‑стили — вполне удобная и рентабельная практика. Особенно, когда дизайн не менялся и меняться не будет. А если будет меняться, то всё будет перевёрстываться. Тяга сделать всё идеально и по‑новому непобедима :‑)

Цель рубрики — обсуждение вопросов дизайна, веб-разработки, переговоров, редактуры и управления.
Комментарии модерируются. Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры.

Рекомендуем другие советы