Статья в стадии написания, она еще редактируется и дополняется.
Техническая страница
Верстку сайта всегда нужно начинать с технической страницы. Если вы ее игнорируете, то допускаете очень грубую ошибку.
Техническая страница - это такая страница, на которой отображены все стандартные элементы, которые будут использоваться при верстке сайта, такие как: теги для текста (h1-h6, p, em, strong, a и т.д.), кнопки, инпуты, чекбоксы и т.д. Любой из этих элементов в будущем можно взять и вывести на любой странице.
Так же я достаточно часто сталкивался с ситуацией, когда например нужно реализовать еще одну страницу на сайте, по ТЗ написано что использовать стили текущего сайта. Например на этой странице есть форма. Нахожу форму на уже существующей странице, вставляю ее HTML-код на новую и вижу то что она выглядит совсем по другому. Начинаю разбираться в чем проблема, а оказывается что контентная часть страницы обернута в контейнер и для каждой страницы класс контейнера свой и все стили этой формы пляшут от класса этого контейнера. Т.е. HTML-код один и тот же, но стили для этой формы работаю только на одной странице. Даже порой обычная кнопка (которая одинаковая везде), для каждой страницы имеет свой отдельный стиль.
По этим причинам начинайте верстать всегда сайт именно с технической страницы. А на страницах сайта используйте HTML-код элементов именно с нее.
Так же хочу уделить внимание на том, что всевозможные теги для форматирования текста, которые потом клиент захочет использовать для оформления статей или просто текстовых страниц, должны стилизоваться по имени тега (без класса), например:
h1 {
font-size: 30px;
}
p {
font-size: 15px;
margin: 0 0 10px 0;
}
a {
color: #000;
text-decoration: underline;
}
a:hover {
color: #ee1c23;
text-decoration: none;
}
ul {
display: block;
margin: 0 0 20px;
}
ul > li {
display: block;
position: relative;
margin-bottom: 5px;
margin-left: 1em;
}
ul > li::before {
content: "\2022";
position: absolute;
left: -1em;
}
Это связано с тем, что публикатор при размещении текста статьи не должен заморачиваться на оформлении стандартных текстовых тегов классами. Потому что он может вести несколько проектов и названия классов для стилизации тегов на всех сайтах не удержишь в голове. Так же публикация статей на тегах без классов требует значительно меньше трат по времени. Поэтому предлагаю уважать труд людей которые будут наполнять сайт после сдачи проекта и предпринять меры, что бы их работа была более комфортной.
А вот сам пример типовой технической страницы. Она не полная, т.к. создана исключительно для примера, но ее можно взять за основу и дополнить нужными элементами.
Правила стилизации блоков
Основное правило - если возможно стилизовать блок на чистом CSS (без использования JavaScript), то именно так и нужно сделать.
Некоторые верстальщики выравнивают блоки или стилизуют элементы с помощью JavaScript, это очень плохой подход, ведь уже давно в CSS появился такой мощный инструмент как Flexbox, он подойдет для огромного количества случаев. Вы должны понимать, что каким бы оптимальным не был код написанный на JavaScript для выравнивания блоков, он все равно будет медленнее на порядок, а то и на несколько порядков чем CSS.
Так же стилизация таких элементов как input[type="checkbox"], input[type="radio"], OL возможна на чистом CSS. Примеры реализации можно посмотреть тут: Стилизация checkbox и radio, Стилизация вложенных нумерованных списков.
Если на странице есть кнопка, по клику на которую открывается всплывающая форма, то никогда не размещайте скрытый код этой формы на странице, которая показывается при клике на кнопку. Для таких целей вы должны создать отдельный HTML-файл web-формы и при клике на кнопку, подгружать эту форму на страницу средствами AJAX. При чем кнопка, вызывающая форму не должна быть ссылкой. Ссылку на эту форму можно разместить например через data-атрибут. Это нужно, чтобы поисковики не нашли в коде ссылку на эту форму, что бы не проиндексировали ее и не отдавали в поисковой выдаче, потому что она (отдельная форма без хедера и футера сайта) не представляет ценности.
Вы спросите, почему нельзя размещать скрытые формы на странице, сразу отвечаю на ваш вопрос:
- Почти на всех сайтах есть в хедере кнопка для открытия формы обратной связи, заказа звонка и прочие. В связи с этим на каждой странице будут присутствовать все эти скрытые формы, которые приводят к:
- Увеличению веса страницы (грузится дольше)
- Увеличению количества DOM-объектов на странице (рендерится дольше)
- Каждая форма генерируется средствами PHP (генерируется дольше + дополнительная нагрузка на сервер)
- Вы даете лишний повод для спам-ботов заполнить и отправить эти формы, что приводит к:
- Лишняя нагрузка на сервер
- Вероятность постоянного получения спама в результатах заполненных форм (если у формы нет защиты от спама или она слабая)
- Процентное совпадение кодов всех страниц возрастет, что будет минусом в поисковой выдаче, потому что чем уникальнее страницы, тем лучше, а одни и те же куски кода на всех страницах уменьшают эту уникальность.
Вы скажете, ну ок, я так сделал просто для наглядности, а программист переделает сам на AJAX. И вы будете не правы. Лучше в таком случае вообще не делать вывод всплывающей формы по кнопке, потому что программисту кроме доработки по AJAX, еще придется потратить время что бы найти код который отображает скрытую форму и удалить его.
Далее:
Никогда не реализуйте кнопки с помощью тега <a href=#"> при клике на которую что то всплывает, открывается или подгружается, потому что поисковые системы отрабатывают ее как ссылку на эту же страницу, а все цикличные ссылки так же плохо сказываются на поисковой выдаче.
Так же рекомендую изучение азов SEO, что бы использовать для разных блоков нужные теги согласно семантике, например если нужно вывести кнопку то используйте <button> а не <a>, если нужно вывести таблицу то <table> а не кучу <div> стилизованных под таблицу и т.д. и т.п.
Не используйте префиксы такие как -webkit -moz -o в стилях которые уже давно поддерживаются всеми современными браузерами, потому что они по факту кроме увеличения CSS ничего не дают. Верстальщик должен иметь у себя на компьютере все браузеры и перед использованием дополнительного стиля с префиксом, сделать сначала проверку работает ли этот стиль во всех браузерах и только если в каком то не работает, то продублировать стиль с префиксом только для него.
/*Так делать не надо, потому что transition уже существует много лет и поддерживается всеми браузерами*/
.btn {
-webkit-transition: all .3s ease-out;
-moz-transition: all .3s ease-out;
-o-transition: all .3s ease-out;
transition: all .3s ease-out;
}
/*Вместо предыдущего нужно использовать вот такой вариант*/
.btn {
transition: all .3s ease-out;
}
Если вы вешаете на тег какое-то JS-событие, например click, то обязательно присвойте этому тегу класс с префиксом (например "js-") указывающим на то что тут висит событие, например "js-open-callback-form" и в JS для обработчика события указывайте именно этот класс. Так же ни в коем случае не стилизуйте этот класс в CSS, что бы убрав этот класс, верстка не поехала, используйте его исключительно для обработчиков событий. Это очень хороший тон программирования, при правках это очень экономит время на понимание кода. Когда следующему разработчику прилетит этот сайт на доработки, он в уме поблагодарит вас.
Не используйте в блоках текст с макетов, потому что очень часто в одной строке расположены 3-4 блока, внутри которых одинаковые картинки и одинаковый текст. На реальном сайте они будут разные. И блоки могут поехать и не смотреться так же красиво как на макете. Поэтому экспериментируйте как будет выглядеть верстка если использовать другую длину текста с картинками другого размера. Верстка блоков должна адаптироваться под их содержимое.
Не подключайте один и тот же стандартный набор JS-библиотек на всех проектах, подключайте только те что будете использовать.
Все JS-файлы всегда подключайте в самом конце страницы, это положительно сказывается на скорости загрузки страницы.
Не используйте в теге <script> атрибуты такие как type="text/javascript", на них ругаются валидаторы HTML такие как validator.w3.org, используйте просто <script> без всяких атрибутов, любой браузер без атрибута поймет что это JavaScript.
Не используйте старые атрибуты у тегов, например border="1", color="#ff0" и т.д., на них так же ругаются валидаторы HTML-кода.
При подключении шрифта, учитывайте его начертание, т.е. учитывайте font-weight и font-style. Ниже приведу два примера реализации подключения шрифта.
<style>
/*Этот способ неправильный*/
@font-face {
font-family: 'Circe';
src: url("fonts/Circe.eot");
src: url("fonts/Circe.eot?#iefix") format("embedded-opentype"), url("fonts/Circe.woff2") format("woff2"), url("fonts/Circe.woff") format("woff"), url("fonts/Circe-Bold.ttf") format("truetype"), url("fonts/Circe.svg#Circe") format("svg");
font-weight: normal;
font-style: normal;
}
@font-face {
font-family: 'Circe-Bold';
src: url("fonts/Circe-Bold.eot");
src: url("fonts/Circe-Bold.eot?#iefix") format("embedded-opentype"), url("fonts/Circe-Bold.woff2") format("woff2"), url("fonts/Circe-Bold.woff") format("woff"), url("fonts/Circe-Bold-Bold.ttf") format("truetype"), url("fonts/Circe-Bold.svg#Circe-Bold") format("svg");
font-weight: normal;
font-style: normal;
}
@font-face {
font-family: 'Circe-Italic';
src: url("fonts/Circe-Italic.eot");
src: url("fonts/Circe-Italic.eot?#iefix") format("embedded-opentype"), url("fonts/Circe-Italic.woff2") format("woff2"), url("fonts/Circe-Italic.woff") format("woff"), url("fonts/Circe-Italic-Bold.ttf") format("truetype"), url("fonts/Circe-Italic.svg#Circe-Italic") format("svg");
font-weight: normal;
font-style: normal;
}
</style>
<style>
/*Этот способ правильный*/
@font-face {
font-family: 'Circe';
src: url("fonts/Circe.eot");
src: url("fonts/Circe.eot?#iefix") format("embedded-opentype"), url("fonts/Circe.woff2") format("woff2"), url("fonts/Circe.woff") format("woff"), url("fonts/Circe-Bold.ttf") format("truetype"), url("fonts/Circe.svg#Circe") format("svg");
font-weight: normal;
font-style: normal;
}
@font-face {
font-family: 'Circe';
src: url("fonts/Circe-Bold.eot");
src: url("fonts/Circe-Bold.eot?#iefix") format("embedded-opentype"), url("fonts/Circe-Bold.woff2") format("woff2"), url("fonts/Circe-Bold.woff") format("woff"), url("fonts/Circe-Bold-Bold.ttf") format("truetype"), url("fonts/Circe-Bold.svg#Circe-Bold") format("svg");
font-weight: bold;
font-style: normal;
}
@font-face {
font-family: 'Circe';
src: url("fonts/Circe-Italic.eot");
src: url("fonts/Circe-Italic.eot?#iefix") format("embedded-opentype"), url("fonts/Circe-Italic.woff2") format("woff2"), url("fonts/Circe-Italic.woff") format("woff"), url("fonts/Circe-Italic-Bold.ttf") format("truetype"), url("fonts/Circe-Italic.svg#Circe-Italic") format("svg");
font-weight: normal;
font-style: italic;
}
</style>
Заметили в чем разница? Если нет то опишу. В первом случае мы один и тот же шрифт назвали по разному, для обычного начертания нам в CSS нужно использовать font-family: "Circe", для жирного текста font-family: "Circe-Bold", а для наклонного font-family: "Circe-Italic". Это в корне не верно. У одного и того же шрифта должно быть одинаковое название. Во втором же примере у нас всегда один и тот же шрифт font-family: "Circe", но для того что бы вывести обычное начертание мы уже указываем font-weight: normal, для жирного font-weight: bold, а для наклонного font-style: italic. А так я бы рекомендовал вообще вместо подключения сторонних шрифтов, попросить дизайнера подыскать им замену похожими стандартными, потому что шрифты весят не мало и создают дополнительные HTTP-запросы к серверу, что приводит к уменьшению скорости загрузки страницы.
Иконки на странице
Никогда не используйте в качестве иконок файлы картинок, потому что каждая картинка на странице это дополнительный HTTP-запрос к серверу, чем больше картинок, тем больше запросов и соответственно более долгая загрузка страницы.
Очень рекомендую в качестве иконок использовать SVG, но только не в качестве тега <img src="icon.svg">, потому что это не улучшит ситуацию, а вставляйте прямо SVG-код. Потому что SVG это по сути XML и ее код сейчас понятен всем современным браузерам.
Второй, я считаю неплохой метод вывода иконок на сайте - это вставка Base64 кода картинки. Этот код можно вставить как в CSS-файл (например background-image: url(код Base64)), так и в src-атрибут картинки <img src="код Base64">.
Адаптивная верстка
Опишу основные правила или рекомендации, которые нужно учесть при разработке сайта с адаптивной версткой:
Правило выбора дефолтной версии (мобильная или десктопная):
За основную (дефолтную) версию верстки (там где нет условий размеров окна браузера, таких как @media (min-width: 768px)) возьмите версию для самого маленького разрешения (для телефона). Да, вы не ослышались, именно верстка для телефона должна быть основной, а остальные версии должны отталкиваться от нее в сторону увеличения ширины окна браузера.
Да, верстать от маленького разрешения к большому гораздо сложнее чем от большого к маленькому. Но давайте зададим вопрос, какое устройство обладает более мощным «железом», телефон, планшет, ноутбук или PC. Конечно это будет PC, а телефон будет самым медленным из этого списка. И поэтому нужно что бы при открытии сайта, меньше всего нагружался телефон. Вы не представляете какую огромную работу выполняет браузер при рендеринге страницы, чего ему стоит прочитать и понять HTML, применить к нему стили, отработать JavaScript и т.д. и т.п. Поэтому телефону придется отработать только основные стили (без условий для ширины экрана), а вот браузер на PC уже пройдется по всем стилям, начиная с основного и последовательно применяя стили для больших разрешений.
Наверняка вы пользовались утилитой для замера скорости загрузки страницы от google «PageSpeed Insights». Если для PC выдается приемлемый результат, то для телефонов частенько мы находимся в красной зоне или около нее. Среди всех рекомендаций есть пункт «Минимизируйте работу в основном потоке», вот как раз его мы и оптимизируем данным правилом верстки от меньшей ширины экрана к большей, потому что избавляем телефон от лишних шагов рендеринга страницы и возлагаем это на более мощные устройства, для которых это будет незаметно. И тем самым повышаем скорость генерации страницы для мобильных устройств, что пойдет в плюс для поисковой выдачи. В общем по минимуму напрягаем слабые устройства. Отлично, с этим разобрались.
Правило верстки элементов страницы для разных разрешений экрана:
Ни когда не дублируйте блоки/элементы страницы для разных разрешений экрана, если можно сверстать без дублирования. Очень часто сталкиваюсь с этой проблемой. Например многие верстальщики дублируют меню, на телефонах выводится одно меню, а второе скрывается, а на десктопах скрывают мобильное меню и выводят десктопное. И эта проблема не только меню, а многих и многих блоков. Я понимаю, что макеты рисует дизайнер и что у него в голове в этот момент, одному только ему известно. Но все-равно, какой бы плохой не был дизайнер, если вы хороший верстальщик (а я надеюсь что это так), то в 90% случаев можно сверстать без дублей блоков, нужно лишь немного подумать головой. И тогда вас будут ценить и уважать за вашу работу. Но если вдруг вообще никак без дублей не обойтись, то лучше сперва попробовать отдать макет на перерисовку дизайнеру и предоставить все аргументы.
А аргументы будут следующие:
- Из-за лишнего кода увеличивается вес страницы, страница грузится дольше.
- Блоки такие как меню генерируются средствами PHP, соответственно генерация страницы будет дольше.
- Возрастает количество DOM-элементов, поэтому страница дольше рендерится браузером.
- Увеличивается количество ссылок на странице (вариант с двойным меню), а поисковые системы не любят очень много ссылок на одной странице
- Так же поисковики не любят присутствие скрытых блоков на странице.
- Программист будет дольше внедрять верстку.
Все эти пункты, за исключением двух последних, вы увидите в рекомендациях по оптимизации страницы на сервисе «PageSpeed Insights», И если их игнорировать, то это аукнется на поисковой выдаче.
Никогда не используйте комбинацию из двух условий типа @media (min-width: 768px) and (max-width: 1023px) из-за этого резко вырастает количество строк CSS, потому что вам для каждого такого промежутка нужно вставить полный набор стилей элемента, а так же такой вариант очень трудно воспринимается web-разработчиком, которому прилетит такой сайт на доработки. Поэтому для каждой следующей точки перескока (breakpoint) используйте только одно условие @media (min-width: 768px), у следующего @media (min-width: 992px) и т.д. Такая реализация значительно сокращает CSS-код за счет того что у нас уже прописаны все стили и мы на следующей точке перебиваем только часть стилей и то не у всех элементов. Так же такой код очень легко воспринимается. Если мы делаем адаптив от меньшего к большему, то открыв инструменты разработчика (в простонародье Firebug) на максимальном разрешении экрана мы увидим стили сразу для всех точек перескока.
Не используйте нестандартные точки перескока, например @media (min-width: 831px), очень часто сталкиваюсь с такой проблемой, ну нет на земле устройств с таким разрешением экрана. У меня возникает только одна мысль, это сделано только потому что на этом разрешении (добиваемся такого разрешения на PC путем изменения ширины окна браузера) где-то едет верстка и таким хардкодом она исправляется. Есть же фреймворки для верстки, например тот же Bootstrap, можно взять из него все точки перескока.
Кстати, если на сайте используется например Bootstrap, то такие нестандартные точки перескока в двойне хуже, потому что например в диапазонах 768-992 в Bootstrap контейнер одной и той же ширины, а какой-нибудь @media (min-width: 831px) в CSS начинающего верстальщика сделает смену стилей у какого-нибудь элемента, что совсем нелогично. Поэтому, если используете фреймворк, то используйте в своем CSS только те точки перескока, которые в нем есть.