Pull to refresh

Comments 51

в вашем случае чтобы сделать границу вокруг контента, все равно нужно будет вкладывать какой-то контейнер внутрь, или фон для области контента, т.е. по вложенности будет тоже самое…

ну если просто для визуализации, то наверно можно "нарисовать" границу через outline.

Что мы делаем? На любом размере экрана мы вычитаем из 100% ширины блочного элемента (section в данном случае) сумму половины текущей ширины и корректирующего значения в 590px, что позволяет держать контент фиксированно в 1180px, когда экран больше или равен этому значению. В общем мне трудно это объяснить.

Наверно проще объяснить как: (100% - 1180px)/2 = 50% - 590px, где (100% - 1180px) — это сумма боковых полей.

А мне одному конструкцию calc(100% - (50% + 590px)) воспринимать труднее чем дополнительный div в вёрстке?
UFO just landed and posted this here
UFO just landed and posted this here
Что «заверстать с помощью флексбоксов»? Они не отменяются. Просто задавать flexbox правила для секции, а не для вложенного блока.
На самом деле Вы не совсем правы. Подход конечно имеет место быть, но уж точно не как замена .container. Суть в том, что вместо того, чтобы дочерний элемент с классом .container сам определял свои размеры и позицию внутри родительского блока, Вы сделали так, чтобы за него это определял сам родитель. В этом ничего нового нет, именно для этого у нас и есть и margin и padding одновременно.

Заметил calc(100% — (50% + 590px)). Проще написать calc(50% — 590px), тем более, что у меня как-то были проблемы с вложенными действиями, приходилось писать calc(100% — calc(...)). А в остальном, всё довольно очевидно для тех, кто занимается вёрсткой. Я сперва думал, что сейчас тут гриды будут, но нет.

Внёс изменения в статью. И как я сам до этого не додумался? Спасибо!

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

Виноват, торопился, исправил.
Использование контейнера удобнее, как по мне. Раз задал его размеры и контент блоков одной ширины по всему сайту. И не нужно каждой секции прописывать свойства для определенной ширины и отступов.
Можно, конечно, придумать дополнительный класс и ему прописать нужные свойста, а потом добавлять к секции (или миксинами), но как кому удобнее.

Нужно придумывать какой-то класс для блока-обёртки.

Так себе минус, добавляем к имени класса "__inner" и вопрос решен ).
Про все остальные минуса контейнера тоже можно поспорить.
То есть создавать каждый раз в секции по 1-2 блока — это удобнее, чем один раз написать padding для тега section и копировать из проекта в проект? Серьезно?
Ну вот чисто визуально, вместо этого:
<section class="Mega-Section">
      <div class="Container">
       ...
      </div>
</section>


писать:

<section class="Mega-Section Container">
...
</section>

гораздо круче.

Мне подход понравился и я не могу сходу придумать почему этот метод может не работать. Есть идеи?
Метод может работать. Секция будет в центре с указанной шириной, но если нам нужно задать какой-то фон (что в 90% случаях и требуется), то сразу всё ломается. Я этот случай описал в самом начале статьи. А если задать в стилях padding для тега section, то о дополнительных классах, контейнерах и блоках можно забыть.
Не-не, я это понял.
Я не имел ввиду тупой перенос класса контейнера на секцию. Я имел ввиду этому классу установить предложенные вами паддинги и использовать его как эдакий миксин в секциях где раньше нужна была еще одна обертка. Я просто не люблю стили вешать на теги.
И мой вопрос именно про то, когда ваша идея не будет работать? Выглядит очень хорошо на первый взгляд.
Спасибо! Мне тоже нравится это. Если не любите стили для тегов, то можно сделать как Вы сказали — задать эти стили для класса .container, а его уже вешать на секции. Всё будет работать. Очевидных минусов я пока не обнаружил, но подводные камни исключать нельзя. Если я их обнаружу или обнаружит кто-то другой и напишет мне или в комментарии, то я дополню статью.
Все решается grid / flexbox, методов justify-content: center
UFO just landed and posted this here
не один, а на каждый, где у вас есть необходимость задавать ограничения блоку на его ширину. Это header main footer как правило.
Как извращаться? Один раз прописали css правила для нужных тегов, например section, header, footer. И не создаём каждый раз лишние блоки, вроде контейнера или блока-обёртки для контента.
UFO just landed and posted this here
В Ваших словах слабо прослеживается логика. Повторюсь: нужно один раз в css задать для тега section padding'и с медиа-запросами и всё. И забыть о центрировании контента. Необходимые стили внутренней компоновки задавать уже для нужной секции по классу. Браузер сделал один расчёт calc() по текущему медиа-запросу и всё.
UFO just landed and posted this here
> Один раз прописали css правила для нужных тегов, например section, header, footer

Не надо вешать правило на теги. Это очень, очень, очень плохая практика за редкими единичными исключениями
Очень плохая практика. Конечно, если вы верстаете лендинг, с проблемами вы вряд ли столкнетесь, но в крупных проектах (кого я обманываю, почти в любых проектах, кроме лендинга) стили по тегам задавать крайне не рекомендуется (исключения: normalize), т.к. header, footer, section могут использоваться в разных местах по-разному, сл-но потом устанете переписывать свойства.
Надо будет попробовать! Спасибо!

Количество элементов можно уменьшить, если смешать класcы brif-wrapper и container на одном DOM-узле. А так представленная техника рассматривалась достаточно давно в книге CSS Secrets за авторством Lea Verou.


P.S.: почему используете дробные пиксели в медиа запросах, например (min-width: 1199.98px)?

Видимо из-за костыльной CSS-спецификации. И в чем была проблема в нее прикрутить операторы сравнения?
Смешать классы обёртки и контейнера — хороший вариант. Но не проще один раз в css задать стили и забыть? Не знал об этой книге. По содержанию понравилась. Почитаю. Спасибо!
Дробные пиксели взял у системы сеток bootstrap. Не вдавался в подробности почему именно дробные.

Вероятно, чтобы дробные размеры вьюпорта, иногда возникающие при неродном масштабе а-ля 90%, не попадали в "зазоры" между соседними диапазонами.

Виноват. Исправил.
Рекомендую использовать не %, а vw. Чтобы ширина считалась не от родителя, а от ширины области промотора браузера. Так просто надёжнее.

100% это ширина контента, где то 1903px
100vw это 1903 + scrollbar
Хорошее замечание. Над этим надо подумать. Дизайн-макет обычно не предусматривает скроолбар, значит используя 100vw, мы тоже не учитываем его. Но какие именно единицы измерения использовать всё равно выбирать Вам.
Если контент может меняться динамически (т.е. скроллбар может появляться и скрываться), то при 100% контент будет «прыгать» в момент появления/скрытия сколлбара, так что vw выглядит более стабильным решением в этом случае.
Если ставить себе главной задачей именно «уменьшить вложенность блоков» — да, такое решение можно использовать (причем давно). Можно назвать его «техническим» решением — то есть решением, технически возможным на данный момент.

Но «техническая» сторона — не всегда определяющая. Важнее может оказаться борьба со сложностью, читаемость кода, поддержка неких браузеров и т.д. И тогда повышенная вложенность блоков (или более простой способ верстки) уже не важна, потому как приоритеты расставлены иначе.

Словом, все зависит от задач. А задачи у всех разные. Так что будьте добры, избегайте обощений: «все верстальщики используют», «его используют абсолютно везде», «вы почувствуете некоторое облегчение» и т.д.

Насчет ".container «родился» в bootstrap" — вообще из ряда вон. Колонка (или две) контента по центру родилась тогда, когда дизайнеры начали отходить от сайтов на 100% ширины страницы и стали пробовать фикс. Бутстрапа тогда и в помине не было.

Насчет подводных камней calc-метода — при желании можно придумать какие-то варианты. В основном, связанные с границами. Например, бывает что в одном блоке натасованы элементы как шириной колонки, так и шириной экрана. Или нужны absolute блоки по краю колонки. «Технически» оно явно решаемо. Но есть ли практический смысл решать — зависит от задач.

Спасибо за конструктивный отзыв. Я не утверждал, что контейнер родился в бутстрап. Буду дополнять статью решением возможных подводных камней, в том числе и блоков с абсолютным позиционированием по краям секции.
padding — это всё-таки не margin, и не всегда подойдёт.
С background'ами не оберешься проблем — позиционирование и т.д.
Или прибежит заказчик и попросит сделать подложку красного цвета у контентной части, или насядут рекламщики и заставят навтыкать баннеров абсолютом.
Ну и опять же пресловутый перформанс, который на тяжелых страницах может здорово аукнуться.
А так, конечно, пользоваться можно, но исключительно с умом и в простых случаях.
Но я зарекся делать такие не гибкие штуки, ибо процент возможных последующих страданий резко возрастает.
Попробуйте применить этот метод и отписывайтесь об обнаруженных проблемах. Если нужно сделать картинку внутри контента, то нужно будет задать background-size и background-position тоже относительными единицами, скорее всего с применением calc. В скором времени я дополню статью различными примерами с background. Хорошее замечание, спасибо за Ваш отзыв!
Не надо так делать. Ради экономии одного-единственного блока вы создаете потенциальные возможности для кучи побочных эффектов. Профита же не будет никакого. На скорость один блок (да даже и несколько) не влияет ваще никак. Читаемость тоже не улучшится, скорее наоборот. Короче, это типичный троллейбус из хлеба.
Попробовал на практике.

На самом деле описаный вами способ ведет себя иначе, чем ".container". При использовании вашего способа мы получаем фиксированный по ширине контейнер в каждом диапазоне от медиа-минимума до медиа-максимума. А ".container" с авто-марджинами плавно меняет размер от минимума до указанного «max-width». Что позволяет более эффективно использовать пространство на планшетах-мобилах нестандартных разрешений.

Это не совсем так. Если размер экрана будет меньше, чем заданная ширина контейнера, то padding'ы станут равными нулю, так как выражение внутри calc(50% - width / 2) будет отрицательным.


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


Набросал пример — https://jsfiddle.net/6kqa4t7n/.

Это совсем так. Вы, видимо, не совсем поняли, о чем я написал.
Я говорил про то, что в диапазоне от одного медиа-брейкпоинта до следующего контент-блок будет фиксированной ширины, увеличиваться будут только паддинги.

Если взять пример автора, то на устройстве с экраном 580px и устройстве с экраном 760px ширина контейнера всегда будет 540px.

А в случае с .container (padding: 0 15px; max-width: 1100px; margin: 0 auto;) на всех экранах до 1101px шириной контейнер будет занимать все доступное пространство. Что порой бывает критично.

В примерах автора это не так очевидно, но данная техника позволяет добиться желаемого. Выставите значение переменной --container-width, например в 1200px, и посмотрите, как это работает — https://jsfiddle.net/z86wt2uh/

Почему в минусах метода нет пункта «Повышение нагрузки на браузер»?
А то на Тостере сегодня один персонаж так и не понял, почему его страничка тормозит, где анимации вагон, в том числе и вот этот вот вычислитель calc.
Критикуя-предлагаю:
аналогично вашему методу я использую один блок, а если необходимо закрасить пустые места слева и справа, то на помощь нам спешат волшебники :before и :after, задавая им заведомо большую ширину.
Все таки padding: 0 calc(50vw — 270px); лучше задавать без обнуления padding сверху и снизу, а как padding-left(right)
При использовании плагинов для группировки медиа запросов, которые включены по телу css, они перебрасываются в конец css файла и, получая больший приоритет, перекрывают свойства паддинга.
Sign up to leave a comment.

Articles