Шпаргалка по вёрстке сайта

Дневник разработчика
Содержание

Работа над вёрсткой сайта идет поэтапно. Разделяю на этапы по видам работ, а не по страничкам.

Каждый этап работы над вёрсткой отвечает за определённый тип работы и распространяется на все страницы макета. Имеется ввиду что если я делаю разметку — то делаю все страницы, а не одну. Не перехожу к следующему этапу, пока все страницы, присутствующие в макете не будут размечены.

Создание репозитория для проекта

Перед тем как что то верстать — создай репозиторий! Это стандарт не только для совместной работы над сайтами, но и залог надёжной сохранности всех ваших наработок. К тому же вы всегда сможете откатиться назад, если внесённые в спешке решения вам больше не нравятся. Главное не забывайте сохраняться вовремя и все будет хорошо.

Для этого примера вёрстки сайта я опишу работу с репозиторием через приложение GitHub Desktop, но в дальнейшем будет шпаргалка по продвинутой работе с системой контроля версий, в которой буду описывать работу с репозиториями через консоль, без приложения.

Создаю репозиторий по следующему алгоритму:

  1. Иду на свой аккаунт на github и в левом верхнем углу, нажав на знак ПЛЮС выбираем новый репозиторий
Шпаргалка по вёрстке сайта
Создаём репозиторий на github.

2. Вводим название для репозитория, если оно не используется другими — появится зелёная галочка. После чего оставляем настройки по умолчанию и нажимаем создать (зелёная кнопка внизу)

Шпаргалка по вёрстке сайта
Вводим название репозитория и нажимаем кнопку создать.

3. На следующем экране выбираем опцию «Открыть в приложении»

Шпаргалка по вёрстке сайта

4. В приложении выбираем путь по которому будет располагаться локальная копия вашего репозитория. У меня этот путь ведёт к папкам с доменами локального сервера. Всё храню в одном месте на компе.

Шпаргалка по вёрстке сайта
Выбираем куда клонировать репозиторий.

5. Всё готово к работе. Теперь вы можете создавать файлы проекта в репозитории.

Создание начальной структуры проекта

Теперь можно приступить к формированию папок и файлов. В моём случае структура проекта выглядит следующим образом:

Шпаргалка по вёрстке сайта
Пример простой структуры проекта.
  • папка CSS — для стилей;
  • папка FONTS — для шрифтов;
  • папка IMG — для изображений и иконок;
  • папка JS — для скриптов;
  • файл editorconfig — задаёт правила форматирования кода;
  • html файлы страниц проекта

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

Всё в структуре должно быть логично, просто и интуитивно понятно! Что бы открыв проект через неделю, месяц или год, ты не запутался.

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

Сохранение проекта в репозитории

После того как структура для старта работ готова — отправляем изменения в мастер репозиторий. При работе через приложение GitHub Desktop всё крайне просто. Для отправки изменений в мастер — достаточно просто в окне работы с вашим репозиторием заполнить данные коммита — заголовок и описание, которые отражают суть проделанных изменений. Затем просто нажимаете кнопку создать коммит — сохраниться.

Шпаргалка по вёрстке сайта
Создаём первый коммит.

Отправляем изменения на github

Для отправки ваших изменений на удалённый репозиторий достаточно просто нажать кнопку опубликовать

Шпаргалка по вёрстке сайта
Отправка изменений на удалённый репозиторий — публикация сохранённых изменений на github.

В дальнейшем на время работы над каждым этапом вёрстки, я создаю отдельные ветки, в которых работаю в плоть до завершения соответствующего этапа. Затем, сохранив изменения на удалённом репозитории, объединяю ветки.

Создание веток в репозитории для поэтапной работы

Для создания новой ветки в репозитории, по средствам приложения GitHub Desktop достаточно выбрать в верхнем меню соответствующий пункт

Шпаргалка по вёрстке сайта
Создание новой ветки в репозитории через GitHub Desktop.

Обычно названия веток носят соответствующие этапам названия:

  • export graphics — экспорт графики
  • hypertext markup — разметка гипертекста
  • element classification — классификация элементов
  • basic style — базовая стилизация
  • grid setup — настройка сетки
  • decorative styles — декоративная стилизация
  • live interface — живой интерфейс
  • project optimization — оптимизация проекта

После того как я закончил работу над текущим этапом, я объединяю ветки. Это тоже очень просто делается:

В приложении переключитесь в ветку Master (основная ветка проекта)

Шпаргалка по вёрстке сайта

В меню Branch выберите пункт Merge into Current Branch (Слияние с текущей веткой)

Шпаргалка по вёрстке сайта

Затем выбираете вашу отдельную ветку, которую вы хотите объединить с главной веткой Master.

Шпаргалка по вёрстке сайта

Готово! Только не забудьте отправить сохранённые изменения на удалённый репозиторий.

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

Экспорт графики из макета

На этом этапе я занимаюсь переносом всех графических элементов из макета в проект. В папке img я создаю логическую структуру.

Шпаргалка по вёрстке сайта

Структура папки с изображениями

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

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

Корректные форматы при экспорте графики из макета (расширение для изображений)

  • Изображения без полупрозрачных частей — сохраняем в формат .jpeg
  • Картинки с полупрозрачностью и прозрачным фоном — в .png
  • Стараемся не использовать .gif
  • Все иконки в векторе — .svg

Разметка гипертекста

В папке проекта создаются все необходимые html-страницы проекта. Размечается структура макета на языке html, применяемом для разметки гипертекста. При разметке страниц руководствуюсь принципом «Страница как документ» —

Принципы и критерии выполнения разметки страниц

Страница как документ

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

Правильные заголовки

  • Последовательные заголовки — страница имеет основной смысловой заголовок, который качественно её описывает — размечаем его <h1>.
  • Условно страницу можно разделить на смысловые секции, каждая из которых так же имеет заголовок — размечаем из тегом <h2>.
  • Внутри секции могут находиться разделы, подразделы и блоки, которые часто содержат заголовки, которые мы размечаем тегами <h3>, <h4>, <h5>, <h6>.
  • В совокупности, структура страницы должна иметь последовательную вложенность заголовков от <h1> до <h6>.
  • Все заголовки должны озаглавливать разделы, секции или блоки. Сам по себе заголовок не является полноценным контентом. Он лишь описывает контент, который идет после него.
  • Заголовки необходимы для логического структурирования контента страниц.
  • Если в дизайн-макете присутствует цитата или рекламный текст, оформленный как заголовок, это не значит, что его нужно размечать тегом <h1> или <h2>.

Смысл повествования важнее дизайна

  • Руководствоваться смысловой нагрузкой контента, а не дизайном.
  • Нет смысла в заголовке без последующего контента. Такие элементы лучше размечать более походящими по смыслу тегами.
  • Все страницы мы условно делим на смысловые секции, у каждой должен быть заголовок и описание.
  • Если в дизайн-макете не хватает заголовка в секции — мы можем его добавить и визуально скрыть. Например при помощи стилей в css. Благодаря этому мы сохраним соответствие дизайн-макету и улучшим семантическую структуру страницы.

пример стилей css что бы доступно спрятать заголовок:

.visually-hidden {
	position: absolute !important;
	clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
	clip: rect(1px, 1px, 1px, 1px);
	padding:0 !important;
	border:0 !important;
	height: 1px !important; 
	width: 1px !important; 
	overflow: hidden;
}

/* или вот такой вариант  */

.visually-hidden:not(:focus):not(:active),
input[type="checkbox"].visually-hidden,
input[type="radio"].visually-hidden {
  position: absolute;
  overflow: hidden;
  clip: rect(0 0 0 0);
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  white-space: nowrap;
  border: 0;
  -webkit-clip-path: inset(100%);
  clip-path: inset(100%);
}

Здоровая культура разработки

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

DRY – Don’t repeat yourself (не повторяй себя)

В любом дизайн-макете, на любом сайте есть повторяющие блоки кода, похожие части контента, повторяющиеся элементы дизайна. Это позволяет нам не только использовать их повторно.

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

Единообразие стиля кодирования и структуры разметки

В работе над сайтами используется единообразный стиль написания кода. Все повторяющиеся элементы должны иметь одинаковый код, даже если стили оформления будут модифицироваться в зависимости от места вставки в макете.

Использование тега <article>

Использование тега article не только для разметки независимых баннеров на странице, но и для карточек, анонсов и списков статей. Этот тег отлично подходит для них, особенно, если в них присутствуют заголовки.

Осмысленное разделение картинок

Все изображения в дизайн макете можно условно разделить на контентные и декоративные:

  • Контентные изображения — несут смысловую нагрузку, их присутствие в контенте обязательно, так как без них посетитель не сможет до конца понять смысл или принять решение.
  • Декоративные изображения — по сути можно обойтись и без них. Смысловая нагрузка контента на странице не пострадает. Такие изображения крайне не желательно вставлять в разметку тегом <img>. Лучше вынести их в стили как фоновое изображение или через псевдо-элементы

Понимание принципа разметки жирного и важного

  • тег <b> — просто для визуального выделения, без явного смыслового акцента.
  • тег <strong> -для важного по смыслу контента
  • <mark> — он существует, что бы выделить текст в абзацах, но не несёт в себе семантичности. только декоративные свойства.

Брать в расчёт CMS на этапе вёрстки

Заранее учитывай особенности натяжки вёрстки на движок. Это можно узнать или у заказчика, или из Технического задания. Очень часто использование классов по БЭМу для абсолютно всех тегов в разметке — излишне. Очень часто это даже мешает при переносе на CMS.

Если известно на какую CMS будут переносить вёрстку — достаточно обратить внимание на разметку типовых элементов этой CMS.

Аналогично и с декоративными изображениями — иногда есть необходимость инлайновой стилизации для фоновых изображений на странице.

Минимум глобальных стилей

Стилизация по тегам крайне вредна для контентных страниц.

Старайся не использовать стилизайию тегов глобально.

Применяй стилизацию по классу, используй смежные селекторы.

Лучше перестраховаться

Для тега <button> всегда явно указываем атрибут и значение type="button", так как значение по умолчанию — type="submit", Так что всегда указываем. Исключением является кнопка отправки данных из формы или кнопка поиска по сайту. Там type="submit" в самый раз.

Обязательно явно указывать размеры для контентных изображений в тегах <img>. Это позволяет избегать скачков страницы по мере загрузки стилевых файлов и скриптов. А еще такой подход ускоряет отрисовку страниц браузером.

Классификация элементов

Для классификации элементов = тегов в разметке я использую английские именования, которые описывают тег или родителя, в который вложен этот тег.

При именовании классов не использую транслит.

Типовые элементы

В любом проекте есть повторяющиеся элементы, которые визуально выглядят одинаково. Обычно я именую их универсальными именами.

Если провести аналогию с БЭМ — это такие БЭБ-блоки.

Базовая стилизация

Стилизация по тегу минимальна.

Вложенность селекторов — максимум три. Но желательно не более двух.

Стараюсь избегать сокращённых слов. Исключение — популярные разделы и элементы сайта:

  • logotype — log,
  • picture — pic,
  • image — img,
  • copyright — cop,
  • header — head,
  • button — btn,
  • navigation — nav,
  • wrapper — wrap,

При работе над базовой стилизацией я по возможности стараюсь описать элементы за счет именования классов. Что бы с первого взгляда на CSS было понятно что это за элемент.

Настройка сетки по макету

Декоративная стилизация

Программирование интерфейсов

Оптимизация проекта

Тестирование проекта

Юрий Ронин