-
1.1 Объединять блоки не по их визуальному расположению, а по их смыслу.
Объединяем блоки вот так:
А не вот так:
.
Как минимум, это очень легко позволит потом добавить новый элемент, когда надо будет по требованию заказчика сделать лист из 4 элементов, а не трех, как здесь. Плюс второй подход очень неудобен, если контент генерируется динамически. Так что если вы создаете верстку, которую потом будут прикручивать к бэкенду заказчики, и сделаете такую верстку, проклятия от их программистов и порча всей нашей кармы обеспечены.
-
1.2 Если есть что-то похожее на список, проверяем, как будет выглядеть при большем количестве элементов.
Если непонятно, что будет при 4-х элементах, как в этом случае, обязательно спросить, а не принимать решение самостоятельно
-
1.3 Все элементы с текстом, контент которых формируется динамически, проверяем на то, чтобы они не ломались при большем количестве текста, чем на макете.
В имена подставляем знаменитое Константин Константинопольский.
В идеале моменты, которые будет трудно масштабировать текстом, находить еще на стадии знакомства с макетом и задавать вопросы дизайнеру.
-
1.4 Не вставлять блочные элементы внутрь инлайновых.
Никаких
<span><div></div></span>.
- 1.5 Использовать h1..h6 только для заголовков, причем h1 должен встречаться в одной странице всего один раз.
-
1.6 Использовать
<table>только для реальных таблиц.Если перед таблицей есть её текстовое описание, сделать это внутри тега
<table>через<caption>.
Если у таблицы первая строка идет заголовком, то использовать<thead>и вложенные<th>для этого и использовать "scope" для этих ячеек.Пример:
<table> <caption> First two U.S. presidents </caption> <thead> <tr> <th scope="col">Name</th> <th scope="col">Took office</th> <th scope="col">Party</th> </tr> </thead> <tbody> <tr> <td>George Washington</td> <td>April 30, 1789</td> <td>n/a</td> </tr> <tr> <td>John Adams</td> <td>March 4, 1797</td> <td>Federalist</td> </tr> </tbody> </table>
-
1.7 Не использовать
<br>нигде, кроме случаев, когда соблюдены все требования:- Newlines are semantically meaningful.
- Indentation is not semantically meaningful (otherwise you should use a
<pre>). - There exists no other semantically appropriate tag, like a paragraph or header tag.
-
1.8 Использовать семантические теги.
Почему их нужно использовать, узнать можно здесь и здесь.
Блок-схема для выбора семантических тегов.
-
2.1 Все теги должны работать даже без CSS и JS.
Все тексты, видимые сначала при открытии страницы так же должны быть доступны, формы должны сабмититься, ссылки должны переходить (а ссылки, по которым вообще не должно быть перехода и для которых принято ставить
href="#", вообще не использовать, это будет далее).
-
2.2 Структура тегов в первую очередь должна идти от содержания, а не от дизайна
— например, такой элемент можно оформить как четыре идущих подряд элемента: иконка сообщений, бадж с цифрой 10, иконка аватара и имя пользователя. Но тут надо явно объединить с помощью
<div>два блока, чтобы семантически они были отдельными — блок с информацией по сообщению и блок про пользователя. Для css потом, возможно, придется писать лишние стили, но верстка будет более осмысленной и не привязанной лишний раз к дизайну.
- 2.3 Начинаем новый .html файл с
<!DOCTYPE html>, как следует по HTML5 стандарту, если этот файл не предназначен для расширения другими файлами через какой-нибудь шаблонизатор.
- 2.4 Перед
<!DOCTYPE html>не должно быть никаких символов, включая пробелы и переносы строк.
- 2.5 Внутри
<head>первым тегом должно идти<meta charset="utf-8">.
- 2.6 У каждой страницы должны быть теги
titleи мета тегиkeywords,description(на содержимое спросить контент у менеджера).
- 2.7 В
headдобавлять<meta name="viewport" content="initial-scale=1.0, width=device-width">— на мобильных браузерах можно избежать горизонтального скролла и масштабировать контент на всю ширину экрана.
-
2.8 Не использовать самозакрывающиеся теги, если они не поддерживают другого режима.
Нельзя:
<div /> <span />
Можно:
<link /> <img /> <input />
-
2.9 Все атрибуты должны быть внутри двойных кавычек
Нельзя:
<img width=200 /> <div class=block> <a href='/some/url'></a> </div>
Можно:
<img width="200" /> <div class="block"> <a href="/some/url"></a> </div>
Плюс, если в проекте нет других соглашений, атрибуты должны именоваться lower-case-hyphenated (имена только маленькими буквами и через дефис) и, если значение строковое и показывает какое-то имя, то тоже должно быть lower-case-hyphenated. Кастомные атрибуты стараться начинать с data- (это стандартная практика, рекомендованная для HTML5).
Пример:
<a href="/" data-index="33" data-page-name="main-page">Home</a>
-
2.10 Не использовать id, кроме случаев, когда они семантически востребованы.
Когда гарантируется их уникальность, например, на уровне базы данных и когда вам нужно:
- сделать рабочую навигацию в рамках одной страницы (например, как на Википедии или на этом сайте сборника best-practices.
- связать
<label>и<input />, которые находятся в совершенно разных ветках дерева DOM (вообще, лучше всегда просто<input />внутрь<label>ставить, и тогда никакие айдишники не нужны).
- 2.11 Все теги идут только с классами — никаких пустых
<div>,<section>и т. д. Но можно для инлайновых элементов, если есть четкое понимание зачем. Это очень сильно мешает новым людям входить в проект и вам через некоторое время разобраться в собственной верстке.
- 2.12 Избегать по максимуму инлайновые стили и обработчики событий в
html(то есть никаких<div onclick="func()">).
- 2.13 Все изображения должны содержать alt.
-
2.14 Не использовать ссылки с пустым или невалидным
href(никаких<a href="#">) — тогда лучше использовать ссылку-заглушку на несуществующий урл, который явно говорит, что ссылка не проставлена.Если вы верстаете проект, в котором есть страницы, которых нет в дизайне (допустим, они потом при интеграции с сервером динамически создаваться будут), то лучше ставьте адрес, который явно говорит, что это ссылка-заглушка. Причем все ссылки-заглушки должны в рамках проекта иметь один адрес, например
<a href="/mock-address/change-me"></a>.
Для SPA иногда приходится динамически js-ом генерить такие ссылки (как минимум в angular, там для этого даже отдельный атрибут ng-href), которые бы поддерживали динамическую генерацию на основе чистого клиентского раутинга.
Не надо никаких<a href="#">или<a href="javascript:someFunc(1)">. Плюс не надо сюда сохранять урлы до методов API на сервере, надеясь, что JS-ом вы сможете потом обработать клик, отправить ajax запрос на сервер по этому урлу и сами обработать ответ. Этого не произойдет, если юзер откроет ссылку в новой вкладке через контекстное меню или клик колесом мыши, например. Все урлы, указанные вhref, должны открывать читаемый для человека контент, который целиком зависит только от сервера. Оригинал последнего абзаца.
- 2.15 Ссылки на чужие сайты должны содержать атрибут
target="_blank", чтобы открываться в новом окне.
-
2.16 Все ссылки с
target="_blank"должны так же содержать атрибутrel="noopener noreferrer".Это связано с уязвимостью, в соответствии с которой сайт, который вы открыли, получит доступ к сайту, с которого перешли через
window.opener, причем это работает даже кроссдоменно.
-
2.17 Все инпуты, селекты и другие интерактивные элементы форм должны располагаться внутри тега
<form>.<form> <label> First name: <input type="text" name="first-name" value="John" /> </label> <label> Last name: <input type="text" name="last-name" value="Doe" /> </label> <button type="submit">Submit</button> </form>
- 2.18 Все интерактивные элементы, для которых дизайнером задуман нетривиальный порядок полей, должны иметь атрибут
tabindex, плюс всегда кнопка сабмита в tabindex должна быть последней (соответственно, если есть визуально поля под кнопкой, у них должен быть tabindex и он должен быть меньше, чем у кнопки).
- 2.19 Спрашивать у дизайнеров, какие элементы делать autofocus на какой странице.
- 2.20 Никогда не допускать вложенные формы
<form>.
- 2.21 Если у поля есть четкое назначение, то использовать соответствующий тип (email, number, color и т. д.).
-
2.22 Каждый тег, в котором может лежать текст, должен быть проверен на большое количество символов.
Все заголовки и все теги с текстовыми описаниями.
Все инпуты проверять, чтобы при заполнении текст не прижимался вплотную к правой границе:
-
2.23 Классические инлайн теги должны быть только inline или inline-block, и в них не должно быть ничего, кроме простого текста и других таких же инлайновых тегов.
Исключения:
<a>— иногда ссылку надо сделать блочным элементом, но лучше использовать inline-block.
-
2.24 Для телефонов, емайл-адресов и скайп никнеймов нужно использовать
<a>c соответствующим адресом.<a href="tel: +74951234567">+7 (495) 123-45-67</a> <a href="mailto: [email protected]">[email protected]</a> <a href="skype: someskype?call">someskype</a>
-
2.25 Отображать примеры кода через тег
<code>.Иногда на некоторых проектах нужно прямо на сайте показывать пользователям примеры кода (например, здесь в туториале Реакта целая куча примеров кода) — эти примеры должны быть написаны моноширинными шрифтами и отличаться от обычного текста — по умолчанию достаточно обрамить код в тeг
<code>.
- 3.1 Все картинки, шрифты и т. д. должны иметь уникальное название в рамках проекта и не содержать кириллических символов. Если в проекте нет индивидуальных соглашений, то они должны именоваться в стиле lower-case-hyphenated.
-
3.2 В проекте обязательно должен быть favicon.ico, подключаемый на всех страницах.
Как это сделать, используя webpack, очень хорошо написано в этой статье.
-
3.3 В сафари своя версия favicon, ее тоже обязательно надо настраивать.
То есть нужна svg для контура иконки, и нужен цвет для иконки при наведении. Статья.
- 3.5 Все фотографии и картинки, где нет прозрачности, делать в jpg.
- 3.6 При нарезке картинок из фотошопа поставить DPI равным 72dpi, а саму картинку сохранить через "Save for Web".
-
3.7 Максимальная ширина картинки — 1920 пикселей. Если в макетах она больше, пропорционально ужимайте.
На самом деле, это правило спорно (как минимум для ретина дисплеев я не уверен), но следуйте ему, пока дизайнер не скажет другого.