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

Типовые решения в вёрстке. Как форматировать ХТМЛ

3 сен 2020
👁 7345   🗩9
Веб-разработка

Типовые решения в вёрстке. Как форматировать ХТМЛ

3 сен 2020
👁 7345   🗩9
Юрий Мазурский
Разработчик и дизайнер
Полезно
 14
14
Непонятно
 1
1
Войдите в Бюросферу, чтобы голосовать

Как и любой другой код, ХТМЛ и ЦСС нужно форматировать. Отформатированный код проще читать и понимать.

Есть много подходов к форматированию кода, но де‑факто есть негласный устоявшийся стандарт, которого с незначительными вариациями придерживается большинство профессиональных разработчиков. В Гугле формализовали этот продукт коллективного разума и превратили в стандарт оформления кода для использования в проектах компании. Он описан в стайлгайдах Гугля — их можно использовать как шпаргалку. Мы рассмотрим главные принципы.

Делать отступы двумя пробелами и не использовать табы

<ul>
  <li>Да
  <li>Нет
</ul>
.example {
  color: blue;
}

Не использовать прописные буквы в именах элементов, атрибутах и стилях

Плохо
<A HREF="/">Главная</A>
Хорошо
<img src="logo.png" alt="Мяу">
img {
  BORDER: 1px solid #56AAF1;
}
img {
  border: 1px solid #56aaf1;
}

Использовать кодировку UTF‑8

Чтобы задать кодировку страницы, нужно добавить директиву в блок head:

<meta charset="utf-8">

Максимально разделять представление, структуру и поведение (скрипты)

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

Плохо
<head>
  <title>Примесь как дуализм</title>
  <link rel="stylesheet" href="reset.css" media="screen">
  <link rel="stylesheet" href="styles.css" media="screen">
  <link rel="stylesheet" href="print.css" media="print">
</head>
<body>
  <h1 style="font-size: 1em;">Примесь как дуализм</h1>
  <p>При переходе к следующему уровню организации почвенного покрова резонатор выводит <u>трансцендентальный нонаккорд</u>. Алеаторика решает трагический бабувизм.<br><center>Адаптация качественно испускает керн.</center></p>
</body>
Хорошо
<head>
  <title>Мелодический ташет глазами современников</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <h1>Мелодический ташет глазами современников</h1>
  <p>Герменевтика регрессийно представляет собой хамбакер. Вселенная достаточно огромна, чтобы мишень вероятна. Арпеджио поглощает данный структурализм. Экситон принимает во внимание Тукан. Бесспорно, сверхпроводник сжимает онтологический атом, что дает возможность использования данной методики как универсальной.</p>
  <p>Наряду с этим колебание случайно.</p>
</body>

Использовать обычные символы вместо символьных кодов

Все необходимые символы уже есть в кодировке UTF‑8, нет смысла заменять их кодами. Исключением могут быть некоторые символы, которые необходимо экранировать.

Плохо
<p>The currency symbol for the Euro is &ldquo;&eur;&rdquo;.</p>
Хорошо
<p>The currency symbol for the Euro is “€”.</p>

Переносить каждый блочный элемент, пункт списка или элемент таблицы на новую строку и выделять дочерние элементы отступами

<footer>
  <p>Читайте продолжение статьи <a href="/next">в нашем свежем выпуске</a></p>
</footer>
<p>Купить:</p>
<ul>
  <li>Молоко</li>
  <li>Яйца</li>
  <li>Бананы</li>
</ul>
<table>
  <thead>
    <tr>
      <th>Цена</th>
      <th>Количество</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1000 ₽</td>
      <td>4</td>
    </tr>
  </tbody>
</table>

Использовать двойные кавычки в значениях атрибутов

Плохо
<a class='login'>Войти</a>
Хорошо
<a class="login">Войти</a>

Использовать короткие формы записи правил, где это возможно

Плохо
font-family: Helvetica;
font-style: normal;
font-weight: 500;
font-size: 18px;
line-height: 22px;
border-top-style: none;
margin-top: 0;
margin-bottom: 30px;
margin-left: 20px;
margin-right: 20px;
Хорошо
margin: 0 20px 30px;
border-top: 0;
font: 500 18px/22px Helvetica, sans-serif;

Не писать единицы измерения у нулевых значений

Плохо
border-width: 0px;
margin: 0px 20px;
Хорошо
border-width: 0;
margin: 0 20px;

Избегать названий тегов в селекторах

Для селекторов с идентификаторами элемента это вообще не имеет смысла, потому что элемент с идентификатором всегда должен быть в единственном экземпляре.

Плохо
ul#example {}
div.error {}
Хорошо
 #example {}
.error {}

Отделять значения свойств пробелом и ставить точку с запятой в конце каждого правила

Плохо
.test {
  display:block;
  height:100px
}
Хорошо
.test {
  display: block;
  height: 100px;
}

Отделять селектор от блока описания правила пробелом

Левую скобку нужно оставлять на одной строке с селектором:

Плохо
#video{
  margin-top: 1em;
}
#video
{
  margin-top: 1em;
}
Хорошо
#video {
  margin-top: 1em;
}

Переносить каждый селектор и каждое свойство на новую строку

Плохо
a:focus, a:active {
  position: relative; top: 1px;
}
Хорошо
h1,
h2,
h3 {
  font-weight: normal;
  line-height: 1.2;
}

Использовать одинарные кавычки в ЦСС

Плохо
header {
  background: url("bg.png") no-repeat center;
  font-family: "open sans", arial, sans-serif;
}
Хорошо
header {
  background: url('bg.png') no-repeat center;
  font-family: 'open sans', arial, sans-serif;
}

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

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

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

Комментарии

Николай Вернер

Дополнительно к описанным, выработал своё правило для ЦСС: всегда группирую свойства по смыслу.

Сперва пишу дисплей и флексы, если есть. Потом последовательно описываю поля‑рамки‑отступы. За ними — позиционирование. После — параметры текста. За ним — фон и эффекты. И после — прочие свойства, которые встречаются далеко не у каждого элемента. Выглядеть это может так:

.content-frame {
	display: block;
	padding: 0 12px;
	border: 1px solid #333;
	margin: 16px 0 32px;
	position: relative;
	left: -4px;
	font: 300 18px/24px Helvetica, sans-serif;
	color: #333;
	background: #eee;
	box-shadow: 0 2px 2px rgba(0,0,0,0.12);
}

Мне такой подход постоянно экономит миллисекунды при сканировании кода: всегда знаю, в какой части перечня свойств что искать.

Дима Шишикин

Настроенный линтер помогает быстро привыкнуть к этим правилам.

Преттиер (https://prettier.io) помогает автоматически форматировать файлы, согласно заданным правилам. Его можно использовать как плагин для среды разработки. Или использовать вместе с гит‑хуками и форматировать файлы при каждом коммите.

Константин Мозговой

Юра, почему лучше делать отступы двумя пробелами? Табами ведь быстрее и удобнее.

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

Тарас Гордиенко

Записывать дробные значения с нулём.
Плохо:
opacity: .5;
Хорошо:
opacity: 0.5;

Тарас, Гугл рекомендует обходиться без нуля: https://google.github.io/…/htmlcssguide.html#Leading_0s

Omit leading “0”s in values. Do not put 0s in front of values or lengths between ‑1 and 1. `font‑size: .8em;`

Два или четыре пробела — дело вкуса. Стоит отметить, что правила принятые в команде приоритетнее любых других правил оформления. Поддерживать одинаковый стиль оформления кода важнее, чем насаждать «правильные» отступы или кавычки. На мой вкус, два пробела лучше, потому что код не уезжает так сильно вправо.

Насчёт табов и пробелов — опасно:
https://www.youtube.com/watch?v=tSIfHvgVeQg

Пробелы понятнее сами по себе. Ширина всегда одинаковая, а табы в разных редакторах могут скакать. Если вы редактируете код в браузере, таб тоже так себе идея.

Николай, для сравнения — Вордпресс предлагает группировать ЦСС‑свойства так:

  • Display

  • Positioning

  • Box model

  • Colors and Typography

  • Other

Но оговаривается, что главное — порядок вместо хаоса. Можно начинать со свойств, которые кажутся более важными, или просто упорядочивать их по алфавиту.
https://make.wordpress.org/…/css/#property‑ordering

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

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