P.S. Надеюсь качество GIF'ок позволяет что-то разглядеть.
Навигация:
- Немного о стандартном .container
- Минусы .container
- Работа с .container и медиа-запросами
- Замена .container одним css-свойством
- Комбинация с медиа-запросами
- Пример из реальной практики, сравнение методов
- Рекомендации
- Заключение
CSS:
.container {
max-width: 1170px;
margin: auto;
height: 1000px;
}
Немного о стандартном .container
Изображение выше и код наглядно показывают как работает стандартный контейнер в типовой вёрстке сайта. Наверное все знают, что обычно создается тег section, в него помещается div.container и уже в него помещают различный контент. Он занимает всю ширину экрана, например, до 1170px и когда экран становится больше, то играет роль обёртки и фиксирует контент в центре страницы, не давая ему «разбежаться» в стороны.
Так почему бы сразу не задать эти стили для контента? Если задать эти стили для секции без контейнера, то вроде бы всё смотрится нормально.
HTML:
<section class="main-section">
<h1 class="main-title">Заголовок страницы</h1>
<p class="main-subtitle">Lorem ipsum dolor.</p>
<div class="cards">
...
</div>
</section>
Но как только требуется задать фон для секции, ситуация сразу выходит из под контроля:
Если задать для секции фон, внутрь секции положить контейнер с его стилями, а в него уже контент, то всё заработает так, как надо:
HTML:
<section class="main-section">
<div class="container">
<h1 class="main-title">Заголовок страницы</h1>
<p class="main-subtitle">Lorem ipsum dolor.</p>
<div class="cards">
...
</div>
</div>
</section>
Минусы .container
Самый очевидный минус контейнера — создание лишних блоков в разметке, которое ведет к увеличению цепочки вложенностей элементов и понижению читаемости кода.
Также создание контейнера может вызвать сложности в названиях классов (иногда нужно придумать дополнительный класс для обёртки внутри контейнера). Это всё просто увеличивает код.
Выше мы рассмотрели самый простой пример. Но если на сайте 15 секций или больше? Это 15 лишних блоков. А если нам внутри контейнера нужно разделить секцию еще на две части и сделать их flex-элементами? Нужно создать div-обёртку, это еще по одному блоку в контейнер. И уже +2 лишних блока на секцию! Как я уже сказал выше — эти div'ные вложенности «мусорят» в разметке. Но возможности css позволяют нам обойтись и без них.
Работа с .container и медиа-запросами
Я не так давно в веб-разработке, но уже нашел способ адекватно работать с контейнером и в итоге вообще избавился от него. Я так понимаю .container «родился» в bootstrap и теперь его используют абсолютно везде.
Взяв за основу сетку bootstrap можно значительно упростить себе работу с css медиа-запросами, используя следующий код:
CSS:
.container {
padding: 0 15px;
}
@media (min-width: 575.98px){
.container {
max-width: 540px;
margin: auto;
padding: 0;
}
}
@media (min-width: 767.98px){
.container {
max-width: 720px;
}
}
@media (min-width: 991.98px) {
.container {
max-width: 960px;
}
}
@media (min-width: 1199.98px){
.container {
max-width: 1140px;
}
}
Что он делает? Если кратко, то держит контент всегда в центре и меняет его размеры на разных экранах:
- На экранах до 576px контент растягивается, но боковые отступы в 15px сохраняются.
- На экранах от 576px до 768px контент находится в центре и его ширина 540px.
- На экранах от 768px до 992px контент в центре и его ширина 720px.
- На экранах от 992px до 1200px контент в центре и его ширина 960px.
- На экранах от 1200px контент в центре с шириной 1140px.
Такая система сетки даёт явные преимущества:
- У нас есть 4 четких медиа-запроса: для больших экранов, для средних экранов, для маленьких экранов, для планшетов.
- имеем всего один небольшой промежуток от 320px до 576px, который нужно адаптировать как бы «вручную» — уменьшая по 1px ширины контента.
Использовать такую настройку медиа-запросов с контейнером очень удобно. Если еще не используете, то попробуйте и вы обязательно согласитесь. В конце концов в Twitter же не дураки сидят, не просто так придумали именно такую сетку размеров экрана.
На рисунке ниже изображена работа .container в связке с медиа-запросами, которые я подсмотрел у bootstrap.
Замена .container одним css-свойством
Наконец-то мы подошли к самому интересному. Так как же заменить .container? Для начала разберемся что нам нужно сделать. Нам нужно две вещи:
- Чтобы контент был фиксированной ширины, например 1180px и не разбегался в стороны.
- Чтобы при этом можно было задать цвет или фон для всей секции.
Что может отодвинуть контент в центр секции и при этом фон останется везде внутри? Ответ оказался прост: задаём для секции внутренние отступы — padding. Но padding не простой. Но для примера давайте сначала попробуем задать простой padding.
Допустим нам нужна ширина контента 1180px, значит 1920 — 1180 = 740 / 2 = 370px — будут боковые отступы в нашей секции. Смотрим:
HTML:
<section>
<div class="content">
content
</div>
</section>
CSS:
section {
background-color: pink;
height: 1000px;
padding: 0 370px;
}
Да уж. При уменьшении экрана, наши отступы сжимают контент. Не годится. Может возможно сделать отступы динамическими? Возможно! И ресурсами одного лишь css!
Для этого воспользуемся функцией calc(). На данный момент css-функция calc() поддерживается на 96.5%, что всего на 1% меньше, чем flexbox, а это значит, что её можно смело использовать. Для динамических внутренних отступов нужно выполнить одну математическую операцию.
Давайте уже скорее посмотрим на пример:
Мне нравится! Без всяких дополнительных блоков наша секция ведёт себя ровно так же, как с .container. С уменьшением экрана уменьшаются padding, а контент остается фиксированным по ширине. И это всего лишь одно css-свойство:
CSS:
section {
padding: 0 calc(50% - 590px);
}
UPD: Упросил формулу. Спасибо Metotron0.
Таким образом мы задаём боковые внутренние отступы с помощью функции calc(), которая при любом разрешении экрана высчитывает эти отступы так, чтобы контент был 1180px! Вы только попробуйте.
Можно поиграться с корректирующим значением 590px и сделать контент 1140px или 1170px, как угодно!
Посмотрите сравнение этого метода с контейнером прямо сейчас!
Комбинация с медиа-запросами
Было бы очень хорошо встроить это в сетку от bootstrap, чтобы легче было адаптировать сайт.
Давайте попробуем:
CSS:
section{
padding: 0 15px;
}
@media (min-width: 575.98px){
section {
padding: 0 calc(50% - 270px);
}
}
@media (min-width: 767.98px){
section {
padding: 0 calc(50% - 360px);
}
}
@media (min-width: 991.98px) {
section {
padding: 0 calc(50% - 480px);
}
}
@media (min-width: 1199.98px){
section {
padding: 0 calc(50% - 590px);
}
}
Результат:
Итого на разных размерах экранов мы имеем:
- от 320px до 576px авто ширину контента и фиксированные отступы 15px.
- от 576px до 768px ширину 540px и динамические отступы.
- от 768px до 992px ширину 720px и динамические отступы.
- от 992px до 1200px ширину 960px и динамические отступы.
- от 1200px ширину 1180px и динамические отступы.
Это же абсолютно тоже самое, что и с div.container! Только без лишних блоков.
Пример из реальной практики, сравнение методов
Всё еще не видите пользы от метода с динамическими отступами? Тогда давайте взглянем на пример из реальной практики. Надевайте очки разработчика — есть следующая секция (кликабельно):
Какие мысли? Есть секция, в ней два отдельных блока, чтобы разбросать их по сторонам, хорошо бы задать для секции display: flex и jcsb. Но если использовать .container, то придётся оборачивать два этих блока в ещё один и ему уже задавать df. Разве это удобно? Пробуем:
HTML:
<section class="brif-section">
<div class="container">
<div class="brif-wrapper">
<div class="brif-text-block">
....
</div>
<form action="#" class="brif-form">
....
</form>
</div>
</div>
</section>
CSS:
.brif-section {
background: background;
}
.container {
max-width: 1180px;
margin: auto;
}
.brif-wrapper {
display: flex;
justify-content: space-between;
}
А теперь посмотрите как это выглядит если использовать динамические отступы:
HTML:
<section class="brif-section">
<div class="brif-text-block">
....
</div>
<form action="#" class="brif-form">
....
</form>
</section>
CSS:
.brif-section {
display: flex;
justify-content: space-between;
padding: 0 calc(50% - 590px);
background: background;
}
Только посмотрите как уменьшился код, он стал чище, читать его стало легче. Получилась секция, которая содержит блок с текстом и форму — ничего лишнего! И это всего лишь одна секция. Повторюсь: а если на сайте 15 секций?
Итак, начинаем подводить итоги:
Плюсы .container:,
- Контент зафиксирован в центре и имеет нужную ширину.
- Можно задать нужный фон для всей секции.
Минусы .container:
- Он является дополнительным div.
- Иногда нужно создавать еще один дополнительный div.
- Код «раздувается» и труднее читается.
- Иногда нужно задавать фон для секции, а другие стили для блока-обёртки.
- Нужно придумывать какой-то класс для блока-обёртки.
Плюсы padding (относительно .container):
- Контент зафиксирован в центре и имеет нужную ширину.
- Можно задать нужный фон для всей секции.
- Нет дополнительных блоков, обёрток.
- Код чище и легче читается.
- Все нужные стили задаются только для секции.
Минусы padding:
- Нужно для секций задавать padding-top и padding-bottom отдельными свойствами.
То есть не:
section {
padding: 50px 0;
}
А вот так:
section {
padding-top: 50px;
padding-bottom: 50px;
}
Иначе они перезапишут динамические отступы.
Рекомендации
Мне нравится метод с динамическими внутренними отступами. Попробуйте его вместо привычной «контейнерной» вёрстки и вы быстро заметите как повысилась чистота вашего кода. Если есть какие-то сомнения в этом методе, то пишите их в комментарии — обсудим!
Рекомендую использовать не %, а vw. Чтобы ширина считалась не от родителя, а от ширины области промотора браузера. Так просто надёжнее. Поддержка vw — 96% тут.
CSS:
section {
padding: 0 calc(50vw - 590px);
}
Создайте свой шаблон этих стилей с медиа-запросами, например:
section, header, footer {
padding: 0 15px;
}
@media (min-width: 575.98px){
section, header, footer {
padding: 0 calc(50vw - 270px);
}
}
@media (min-width: 767.98px){
section, header, footer {
padding: 0 calc(50vw - 360px);
}
}
@media (min-width: 991.98px) {
section, header, footer {
padding: 0 calc(50vw - 480px);
}
}
@media (min-width: 1199.98px){
section, header, footer {
padding: 0 calc(50vw - 590px);
}
}
Заключение
Метод с динамическими отступами выполняет ту же функцию, что и div.container, но полностью лишён всех его недостатков. Возможно этот метод имеет какие-то подводные камни, но я пока их не встретил. Пока всё работает абсолютно так же, как с контейнером.
Не бойтесь чего-то нового. Просто начните применять этот метод и в скором времени вы почувствуете некоторое облегчение. Используйте css на полную катушку!
P.S. Если во время использования этого метода всплывут какие-то подводные камни — опишите их в комментариях! Будем разбираться.
Комментарии (46)
Xalium
16.08.2019 15:37Что мы делаем? На любом размере экрана мы вычитаем из 100% ширины блочного элемента (section в данном случае) сумму половины текущей ширины и корректирующего значения в 590px, что позволяет держать контент фиксированно в 1180px, когда экран больше или равен этому значению. В общем мне трудно это объяснить.
Наверно проще объяснить как:
(100% - 1180px)/2=50% - 590px, где(100% - 1180px)— это сумма боковых полей.
iskhomutov
16.08.2019 15:41А мне одному конструкцию
calc(100% - (50% + 590px))воспринимать труднее чем дополнительный div в вёрстке?staticlab
16.08.2019 16:09Ну если уж так заморачиваться, то такую конструкцию можно вынести в миксин SASS.
staticlab
16.08.2019 16:07+1На данный момент css-функция calc() поддерживается на 96.5%, что всего на 1% меньше, чем flexbox, а это значит, что её можно смело использовать.
Тогда почему бы не заверстать с помощью флексбоксов? :)
jcsb Автор
16.08.2019 17:55Что «заверстать с помощью флексбоксов»? Они не отменяются. Просто задавать flexbox правила для секции, а не для вложенного блока.
iskhomutov
16.08.2019 16:44На самом деле Вы не совсем правы. Подход конечно имеет место быть, но уж точно не как замена .container. Суть в том, что вместо того, чтобы дочерний элемент с классом .container сам определял свои размеры и позицию внутри родительского блока, Вы сделали так, чтобы за него это определял сам родитель. В этом ничего нового нет, именно для этого у нас и есть и margin и padding одновременно.
Metotron0
16.08.2019 16:58Заметил calc(100% — (50% + 590px)). Проще написать calc(50% — 590px), тем более, что у меня как-то были проблемы с вложенными действиями, приходилось писать calc(100% — calc(...)). А в остальном, всё довольно очевидно для тех, кто занимается вёрсткой. Я сперва думал, что сейчас тут гриды будут, но нет.
4mobile
16.08.2019 16:59Использование контейнера удобнее, как по мне. Раз задал его размеры и контент блоков одной ширины по всему сайту. И не нужно каждой секции прописывать свойства для определенной ширины и отступов.
Можно, конечно, придумать дополнительный класс и ему прописать нужные свойста, а потом добавлять к секции (или миксинами), но как кому удобнее.
Нужно придумывать какой-то класс для блока-обёртки.
Так себе минус, добавляем к имени класса "__inner" и вопрос решен ).
Про все остальные минуса контейнера тоже можно поспорить.jcsb Автор
16.08.2019 23:29То есть создавать каждый раз в секции по 1-2 блока — это удобнее, чем один раз написать padding для тега section и копировать из проекта в проект? Серьезно?
tema_sun
17.08.2019 13:21Ну вот чисто визуально, вместо этого:
<section class="Mega-Section"> <div class="Container"> ... </div> </section>
писать:
<section class="Mega-Section Container"> ... </section>
гораздо круче.
Мне подход понравился и я не могу сходу придумать почему этот метод может не работать. Есть идеи?jcsb Автор
17.08.2019 13:53Метод может работать. Секция будет в центре с указанной шириной, но если нам нужно задать какой-то фон (что в 90% случаях и требуется), то сразу всё ломается. Я этот случай описал в самом начале статьи. А если задать в стилях padding для тега section, то о дополнительных классах, контейнерах и блоках можно забыть.
tema_sun
17.08.2019 14:25Не-не, я это понял.
Я не имел ввиду тупой перенос класса контейнера на секцию. Я имел ввиду этому классу установить предложенные вами паддинги и использовать его как эдакий миксин в секциях где раньше нужна была еще одна обертка. Я просто не люблю стили вешать на теги.
И мой вопрос именно про то, когда ваша идея не будет работать? Выглядит очень хорошо на первый взгляд.jcsb Автор
17.08.2019 14:36Спасибо! Мне тоже нравится это. Если не любите стили для тегов, то можно сделать как Вы сказали — задать эти стили для класса .container, а его уже вешать на секции. Всё будет работать. Очевидных минусов я пока не обнаружил, но подводные камни исключать нельзя. Если я их обнаружу или обнаружит кто-то другой и напишет мне или в комментарии, то я дополню статью.
psFitz
16.08.2019 17:56Так извращаться чтобы не создавать один блок? + Нагрузка на браузер при множестве контейнеров
Alexufo
17.08.2019 03:03не один, а на каждый, где у вас есть необходимость задавать ограничения блоку на его ширину. Это header main footer как правило.
jcsb Автор
17.08.2019 12:14Как извращаться? Один раз прописали css правила для нужных тегов, например section, header, footer. И не создаём каждый раз лишние блоки, вроде контейнера или блока-обёртки для контента.
psFitz
17.08.2019 12:42так каждый раз и не надо, надо только если фон должен быть на весь экран, если этого не надо делать — просто вешаешь .container на section, зато браузеру не надо делать кучу пересчетов после смены контента/анимации/размера окна
jcsb Автор
17.08.2019 13:59В Ваших словах слабо прослеживается логика. Повторюсь: нужно один раз в css задать для тега section padding'и с медиа-запросами и всё. И забыть о центрировании контента. Необходимые стили внутренней компоновки задавать уже для нужной секции по классу. Браузер сделал один расчёт calc() по текущему медиа-запросу и всё.
psFitz
17.08.2019 18:44Что мешает один раз задать просто ширину? Браузер не считает один аз это, если внутренний блок будет анимироваться — браузер снова будет считать
Fayon
19.08.2019 16:46+1> Один раз прописали css правила для нужных тегов, например section, header, footer
Не надо вешать правило на теги. Это очень, очень, очень плохая практика за редкими единичными исключениями
edk55
19.08.2019 21:35Очень плохая практика. Конечно, если вы верстаете лендинг, с проблемами вы вряд ли столкнетесь, но в крупных проектах (кого я обманываю, почти в любых проектах, кроме лендинга) стили по тегам задавать крайне не рекомендуется (исключения: normalize), т.к. header, footer, section могут использоваться в разных местах по-разному, сл-но потом устанете переписывать свойства.
monochromer
16.08.2019 23:56Количество элементов можно уменьшить, если смешать класcы
brif-wrapperиcontainerна одном DOM-узле. А так представленная техника рассматривалась достаточно давно в книге CSS Secrets за авторством Lea Verou.
P.S.: почему используете дробные пиксели в медиа запросах, например
(min-width: 1199.98px)?xadd
17.08.2019 00:33Видимо из-за костыльной CSS-спецификации. И в чем была проблема в нее прикрутить операторы сравнения?
ImKremen
17.08.2019 07:11Они уже есть в спецификации и даже кое-где поддерживаются. https://www.w3.org/TR/mediaqueries-4/#range-context
jcsb Автор
17.08.2019 14:02Смешать классы обёртки и контейнера — хороший вариант. Но не проще один раз в css задать стили и забыть? Не знал об этой книге. По содержанию понравилась. Почитаю. Спасибо!
Дробные пиксели взял у системы сеток bootstrap. Не вдавался в подробности почему именно дробные.
SelenIT3
18.08.2019 23:45Вероятно, чтобы дробные размеры вьюпорта, иногда возникающие при неродном масштабе а-ля 90%, не попадали в "зазоры" между соседними диапазонами.
tyzberd
18.08.2019 12:29Рекомендую использовать не %, а vw. Чтобы ширина считалась не от родителя, а от ширины области промотора браузера. Так просто надёжнее.
100% это ширина контента, где то 1903px
100vw это 1903 + scrollbarjcsb Автор
18.08.2019 12:38Хорошее замечание. Над этим надо подумать. Дизайн-макет обычно не предусматривает скроолбар, значит используя 100vw, мы тоже не учитываем его. Но какие именно единицы измерения использовать всё равно выбирать Вам.
mobi
18.08.2019 12:46Если контент может меняться динамически (т.е. скроллбар может появляться и скрываться), то при 100% контент будет «прыгать» в момент появления/скрытия сколлбара, так что vw выглядит более стабильным решением в этом случае.
cssfish
19.08.2019 21:35Если ставить себе главной задачей именно «уменьшить вложенность блоков» — да, такое решение можно использовать (причем давно). Можно назвать его «техническим» решением — то есть решением, технически возможным на данный момент.
Но «техническая» сторона — не всегда определяющая. Важнее может оказаться борьба со сложностью, читаемость кода, поддержка неких браузеров и т.д. И тогда повышенная вложенность блоков (или более простой способ верстки) уже не важна, потому как приоритеты расставлены иначе.
Словом, все зависит от задач. А задачи у всех разные. Так что будьте добры, избегайте обощений: «все верстальщики используют», «его используют абсолютно везде», «вы почувствуете некоторое облегчение» и т.д.
Насчет ".container «родился» в bootstrap" — вообще из ряда вон. Колонка (или две) контента по центру родилась тогда, когда дизайнеры начали отходить от сайтов на 100% ширины страницы и стали пробовать фикс. Бутстрапа тогда и в помине не было.
Насчет подводных камней calc-метода — при желании можно придумать какие-то варианты. В основном, связанные с границами. Например, бывает что в одном блоке натасованы элементы как шириной колонки, так и шириной экрана. Или нужны absolute блоки по краю колонки. «Технически» оно явно решаемо. Но есть ли практический смысл решать — зависит от задач.
jcsb Автор
19.08.2019 21:48Спасибо за конструктивный отзыв. Я не утверждал, что контейнер родился в бутстрап. Буду дополнять статью решением возможных подводных камней, в том числе и блоков с абсолютным позиционированием по краям секции.
Turba
19.08.2019 21:36padding — это всё-таки не margin, и не всегда подойдёт.
С background'ами не оберешься проблем — позиционирование и т.д.
Или прибежит заказчик и попросит сделать подложку красного цвета у контентной части, или насядут рекламщики и заставят навтыкать баннеров абсолютом.
Ну и опять же пресловутый перформанс, который на тяжелых страницах может здорово аукнуться.
А так, конечно, пользоваться можно, но исключительно с умом и в простых случаях.
Но я зарекся делать такие не гибкие штуки, ибо процент возможных последующих страданий резко возрастает.jcsb Автор
19.08.2019 21:43Попробуйте применить этот метод и отписывайтесь об обнаруженных проблемах. Если нужно сделать картинку внутри контента, то нужно будет задать background-size и background-position тоже относительными единицами, скорее всего с применением calc. В скором времени я дополню статью различными примерами с background. Хорошее замечание, спасибо за Ваш отзыв!
dom1n1k
19.08.2019 23:25Не надо так делать. Ради экономии одного-единственного блока вы создаете потенциальные возможности для кучи побочных эффектов. Профита же не будет никакого. На скорость один блок (да даже и несколько) не влияет ваще никак. Читаемость тоже не улучшится, скорее наоборот. Короче, это типичный троллейбус из хлеба.
Fayon
20.08.2019 11:49Попробовал на практике.
На самом деле описаный вами способ ведет себя иначе, чем ".container". При использовании вашего способа мы получаем фиксированный по ширине контейнер в каждом диапазоне от медиа-минимума до медиа-максимума. А ".container" с авто-марджинами плавно меняет размер от минимума до указанного «max-width». Что позволяет более эффективно использовать пространство на планшетах-мобилах нестандартных разрешений.
KinsleR
в вашем случае чтобы сделать границу вокруг контента, все равно нужно будет вкладывать какой-то контейнер внутрь, или фон для области контента, т.е. по вложенности будет тоже самое…
Xalium
ну если просто для визуализации, то наверно можно "нарисовать" границу через outline.