x
 
Юрий Мазурский
31 октября 2019
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

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

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. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.

Поделиться
Отправить

Комментарии

Евгений Арутюнов
31 октября 2019

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

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

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

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

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

Алексей Самохин
31 октября 2019

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

Юрий Мазурский
5 ноября 2019

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

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

Ярослав Еременко
12 ноября 2019

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

Saemon Zixel
вчера

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


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

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

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

Вот такой веб 2.0.

Автотесты «на пальцах» Как следить за качеством кода? Часть третья: процессы 3 Автотесты «на пальцах» Как следить за качеством кода? Часть вторая: метрики




Недавно всплыло

Хочу научиться сторителлингу 2 Хочу научиться сторителлингу 12 2 В бюро есть таймтрекинг для сотрудников? 5