брейкпоинты в верстке что это

Контрольные точки

Основные понятия

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

Доступные контрольные точки

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

Контрольные точки	Инфикс класса	Размеры
	X-Small	Нет	sm	≥576px
	Medium	md	≥768px
	Large	lg	≥992px
	Extra large	xl	≥1200px
	Extra extra large	xxl	≥1400px

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

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

Медиа-запросы

Поскольку Bootstrap разработан для мобильных устройств, мы используем несколько медиа-запросов для создания разумных точек останова для наших макетов и интерфейсов. Эти точки останова в основном основаны на минимальной ширине области просмотра и позволяют масштабировать элементы при изменении области просмотра.

Минимальная ширина

Эти миксины Sass переводятся в наш скомпилированный CSS с использованием значений, объявленных в наших переменных Sass. Например:

Максимальная ширина

Иногда мы используем медиа-запросы, идущие в другом направлении (заданный размер экрана или меньше):

Одиночная контрольная точка

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

Между контрольными точками

Точно так же медиа-запросы могут охватывать несколько значений ширины контрольной точки:

Источник

100% правильный способ делать адаптивные брейкпоинты в CSS

Дата публикации: 2016-12-05

От автора: сейчас я попрошу вас забыть о CSS, веб-разработке и цифровых интерфейсах на некоторое время. И вот когда вы все забыли, хочу предложить отправиться вам в мысленное путешествие назад во времени. Туда, где вы были еще маленьким, ваш первый день в школе. Тогда все было проще, вы рисовали каракули и старались усидеть на месте.

Посмотрите на точки сверху. Некоторые из них слипаются, а другие расположены друг от друга на расстоянии, видите? Я хочу, чтобы вы разбили их на 5 групп так, как вы считаете нужным.

Давайте. Убедитесь, что никто не смотрит, и нарисуйте пять кружков своими детскими пальчиками.

Скорее всего, вы обвели точки примерно, как показано ниже, так ведь? И только не говорите, что прокрутили станицу вниз, не обведя точки. У меня тогда будет фейспалм.

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

Крайние справа две точки можно было бы объединить и по-другому. Если вы обвели их вместе, ничего страшного. Говорят, что тут не существует неправильного ответа.

Прежде чем я продолжу, хочу спросить, не пробовали ли вы обвести точки так?

Скорее всего, нет, правильно?

Но именно это и нужно было бы сделать, если бы вам нужно было задать брейкпоинты в местах, совпадающих с точной шириной экрана популярных устройств (320px, 768px, 1024px).

Слышали ли вы когда-нибудь или произносили цитату ниже? «Средний брейкпоинт доходит до 768px или включает 768? Так-так… это альбомный режим на iPad или large? Ой, large ведь это 768px и выше. Понятно. А small тогда 320px? Для кого тогда диапазон от 0 до 319px? Для насекомых?»

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

Почему размеры должны быть именно такими?

Я думаю, что ответ на этот вопрос, как и на многие другие проблемы, кроется в неправильном понимании терминологии. В конце концов, все мы знаем шутку про прилив в Гуантанамо. Звучит шикарно, если не знаешь, что это значит. (Жалко, что эту шутку придумал не я.) В тюрьме в Гуантанамо заключенных пытали, имитируя утопление приливом.

Мне кажется, мы смешиваем понятия границ и диапазонов, когда обсуждаем и создаем брейкпоинты.

Если же вы, говоря о large, понимаете только границы, то вы запутаетесь, потому что медиа запросы это всегда диапазон.

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

правильно определяйте брейкпоинты;

давайте диапазонам разумные названия;

Совет №1: правильно определяйте брейкпоинты

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

600px, 900px, 1200px и 1800px, если вы собираетесь сделать что-то особенное для пользователей с очень большими мониторами. Не по теме, если заказываете большой монитор онлайн, убедитесь, что он для компьютера. Вы же не хотите получить по почте гигантскую ящерицу.

Те точки, с которыми вы играли, когда были маленьким, на самом деле представляют собой 14 наиболее распространенных размеров экранов:

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

Совет №2: давайте диапазонам разумные названия

Можно называть брейкпоинты papa-bear и baby-bear, если хотите. Но если я сяду с дизайнером обсудить внешний вид сайта на разных устройствах, я хочу, чтобы наш разговор закончился как можно быстрее. Если название portrait tablet поможет мне ускорить разговор, я буду рад. Да я даже простил, если бы вы назвали размер «iPad portrait».

Но альбомные размеры меняются! Можете закричать вы. Телефоны становятся все больше, а планшеты все меньше.

Срок годности CSS на сайте составляет в среднем 3 года (если это не Gmail). iPad удвоился за это время, и его до сих пор используют. Мы же знаем, что Apple больше не делает новых продуктов, они просто убирают что-то из существующих вещей (кнопки, отверстия и т.д.).

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

Ребят, 1024х768 никуда не денется. Давайте не будем прятать голову в песок. Забавный факт: страусы не обитают в городах, потому что там нет песка, некуда прятаться от хищников.

Заключение: связь очень важна. Не отрывайте себя целенаправленно от полезной лексики.

Совет №3: будьте декларативны

Знаю-знаю, «декларативны», это слово, опять. Скажу по-другому: ваш CSS должен определять то, что необходимо сделать, а не как это должно произойти. Слово «как» больше относится к каким-то мелочам в миксинах.

Такие вещи можно прятать в миксины, а не оставлять в коде. Можно сделать еще лучше и вообще не использовать переменные.

Сначала я написал код ниже как упрощенный пример. Но на самом деле я думаю, что этот код охватывает все основные моменты. Можно посмотреть в действии на CodePen. Я использовал Sass, не могу представить себе разработку сайта без него. В CSS или LESS логика такая же.

Источник

100% правильный способ работы с брейкпоинтами

Feb 17, 2020 · 8 min read

Опубликована: 19 ноября 2016

Давайте на следующие несколько минут забудем о CSS, веб-разработке и интерфейсах.

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

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

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

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

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

Но, прежде чем мы продолжим — возможно, кто-то из вас всё-таки нарисовал что-то подобное?

Скорее всего нет, правда?

Но ведь это как раз таки то, что получается, когда вы выставляете брейкпоинты в своём проекте в соответствии с шириной экранов самых распространённых девайсов (320px, 768px, 1024px).

Приходилось ли вам когда-нибудь слышать или говорить что-то подобное:

Хм, а брейкпоинт “medium” подразумевает 768px, включая или не включая это значение? А пейзажная ориентация iPad — это тогда “large”? А, кажется “large” — это 768px и шире. Окей, с этим разобрались. А “small” — это 320px? Но что тогда использовать для промежутка от 0px до 319px? Назвать брейкпоинт “муравьиным”?

Я мог бы просто показать вам правильные значения для брейкпоинтов и закончить статью на этом. Но мне крайне интересно разобраться, почему метод такой странной группировки настолько широко распространён?

Почему это должно быть именно так?

Мне кажется, ответ на это вопрос, как и всегда, кроется в неправильно подобранной терминологии. К слову, “аквапарк на побережье Гуантанамо” звучит просто прекрасно ровно до тех пор, пока вы не узнаете, что значит эта фраза. (Боже, почему не я придумал эту шутку).

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

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

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

Совет 1: правильно определяйте брейкпоинты

Но что считать правильными брейкпоинтами?

Ваш внутренний ребёнок уже нарисовал несколько кружочков на шкале — я всего лишь превращу их в интервалы.

600px, 900px, 1200px, и 1800px, если интерфейс будет меняться на устройствах с огромными мониторами. Кстати, если вы покупаете огромный монитор онлайн — проверьте, что он может использоваться с ПК, чтобы не получить внезапный сюрприз при доставке.

Те самые группированные точки из вашего “школьного прошлого” как раз соответствуют 14 самым распространённым размерам экранов:

Соответственно, можно составить небольшую диаграммку, чтобы убеждать всяких “серьёзных людей” вроде менеджеров, дизайнеров, других разработчиков и тестировщиков стало немного проще.

Совет 2: правильно называйте интервалы

Конечно, вы можете назвать свои брейкпоинты как захотите, хоть papa-bear и baby-bear. Но если я приду к дизайнеру, чтобы обсудить, как выглядит сайт на том или ином разрешении экрана — я явно захочу поскорее закончить этот разговор. Если термин portrait tablet подходит для понимания обеими сторонами — отлично, я справился. Чёрт возьми, я даже готов смириться с iPad portrait в крайнем случае.

Вероятнее всего, здесь вы возразите мне, что “размеры экрана меняются! Телефоны становятся больше! Планшеты становятся меньше!”

Но срок годности CSS на вашем сайте — примерно 3 года (если только вы не Gmail, конечно). iPad, к примеру, всё это время был с нами и нам ещё придётся побороться за его отставку. Да и, насколько мы знаем, Apple больше не делает новых продуктов — они просто убирают разные элементы из старых (кнопки, разъёмы — вот это всё).

Так что, 1024 x 768 пока остаётся с нами, ребят, как бы мы ни пытались от этого спрятаться. (Кстати, забавный факт: думаю, страусы не живут в городах именно потому, что им негде прятаться — в городах нет песка, в который можно сунуть голову, завидев хищника.)

В заключение: коммуникация — это важно. Не стоит целенаправленно лишать себя возможности использовать удобные и понятные для всех термины.

Совет 3: будьте декларативны

Да-да, знаю, снова какая-то непонятная “декларативность”. Попробую зайти с другой стороны: ваш CSS должен говорить о том, что произойдёт, а не как это произойдёт. “Как” стоит вообще спрятать в какой-нибудь миксин.

Таким образом, мы можем спрятать всё лишнее в миксины и не захламлять отдельными значениями код. Или пойти ещё дальше и вовсе не использовать переменные.

Для начала, посмотрим на небольшой сниппет, который я написал в качестве простого примера.

Неопределённость порождает путаницу.

Мой пример может подвергнуться критике хотя бы за то, что не учитывает кастомные media-запросы. Однако, хорошие новости — если вы хотите кастомный media-запрос, вы можете просто написать его сами! (На практике, если мне нужно что-то более сложное, чем в примере — я минимизирую свои потери, обращаясь к столь мной любимому инструментарию Susy.)

Ещё одна причина покритиковать моё решение — 8 используемых в нём миксинов. Конечно же, это можно сделать и одним миксином, просто подставляя нужный размер, например:

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

И это не говоря уже о том, что синтаксис @include for-desktop-up <. >выглядит гораздо более читабельным, чем @include for-size(desktop-up) <. >.

Однако, оба этих сниппета плохи тем, что я дважды пишу 900px и, к тому же, использую 899px, хотя мог бы просто завести одну переменную и вычитать из неё 1, когда это необходимо.

И если вы действительно хотите сделать именно так — вы сумасшедший, потому что у меня есть минимум 2 причины этого не делать:

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

Наконец, вы, наверное, подумаете “может в выборе брейкпоинтов стоит всё же опираться на контент, а не на девайсы?”. Что ж, я восхищён вашей дальновидностью и мой ответ — да… но только для сайтов с единообразной вёрсткой. Или если макетов всё же несколько, но у вас есть набор брейкпоинтов для каждого из них. К тому же, если дизайн вашего сайта не меняется слишком часто или вы имеете возможность обновлять брейкпоинты вместе с обновлением дизайна — конечно же вы захотите сохранить брейкпоинты на основе контента, правда?

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

Итак, мы закончили! Всё-таки, этот пост получился не таким мягким и пушистым, как мне бы хотелось… Хотя, постойте, возможно я всё ещё могу это исправить…

Источник

Контрольные точки

Основные концепции

Доступные точки останова

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

Для получения дополнительной информации и примеров того, как изменить наши карты и переменные Sass, обратитесь к разделу Sass документации Grid.

Медиа-запросы

Поскольку Bootstrap разработан в первую очередь для мобильных устройств, мы используем несколько медиа-запросов для создания разумных точек останова для наших макетов и интерфейсов. Эти точки останова в основном основаны на минимальной ширине области просмотра и позволяют увеличивать размеры элементов по мере изменения области просмотра.

Min-width

Эти миксины Sass переводятся в наш скомпилированный CSS с использованием значений, объявленных в наших переменных Sass. Например:

Max-width

Иногда мы используем медиа-запросы, которые идут в другом направлении (данный размер экрана или меньше):

Одиночная точка останова

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

Между точками останова

Точно так же медиа-запросы могут охватывать несколько значений ширины точки останова:

Разработан и построен с любовью к миру, командой Bootstrap и помощью наших участников.

В настоящее время v5.0.0-alpha1. Код под лицензией MIT, документы CC BY 3.0.

Источник

Самый лучший способ создания CSS брейкпоинтов

Я хочу, чтобы на следующие минут 30 или около того, вы забыли про CSS. Забыли о веб-разработке. Забыли о цифровых пользовательских интерфейсах.

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

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

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

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

У вас скорее всего получилось что-то вроде этого, так? (И как бы то ни было, не говорите что просто прокрутили страницу не выполняя задание. Иначе будет фейспалм.)

На самом деле, эти две точки справа могут быть объединены и по-другому. Если вы поместили их в одну группу, думаю это нормально.

Прежде чем я продолжу, скажите, у вас получилось что-то вроде этого?

Полагаю, что нет. Правильно?

Но это именно то, что вы будете делать, если поставите свои брейкпоинты на позициях, точно совпадающих с ширинами популярных устройств (320px, 768px, 1024px).

Вам когда-нибудь доводилось слышать или говорите что-то такое:

Брейкпоинт medium идет до 768px или включает 768? А, вижу… А это iPad в горизонтальной ориентации, или это large? А, нет, large идет от 768px и выше. Понял. А small получается 320px? Что это за интервал от 0 до 319? Брейкпоинт для муравьев?

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

В чем может быть причина этого?

Думаю причина этой проблемы, как и многих других проблем, состоит в неправильной терминологии. Кажется мы смешиваем понятия “границы” и “интервалы” в наших обсуждениях и реализациях брейкпоинтов.

А если это верхняя граница, как вы собираетесь называть брейкпоинты, которые выше, large-and-up? Это должен быть media-запрос с минимальной шириной medium, правильно?

И если вы подразумеваете только границу, когда говорите large, то это приведет к неразберихе в дальнейшем, потому что media-запрос — это всегда интервал.

Эта ситуация запутана и мы тратим время, думая об этом. Поэтому у меня есть три предложения:

Совет #1: Расставляйте брейкпоинты правильно

Что знаичит правильный брейкпоинт?

Школьник в вашем обличии уже нарисовал окружности. Я просто перевел их в прямоугольники для вас.

600px, 900px, 1200px и 1800px если вы планируете показать что-то особенное людям с гигантскими мониторами.

Эти точки, с которыми игрался школьник в вашем обличии, на самом деле были визуализацией 14 самых популярных размеров экранов:

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

Совет #2: Именуйте интервалы разумно

Честно говоря, вы можете назвать ваши брейкпоинты папа-медведь и малыш-медведь, если вам хочется. Но если я собираюсь сесть с дизайнером и обсудить, как сайт должен выглядеть на разных устройствах, я хочу, чтобы это прошло как можно быстрее. Если то, что вы назовете размер “планшет в портретной ориентации”, ускорит дело, то я за. Да блин, я даже готов простить вам если вы назовете его “iPad в портретной оринтации”.

“Но размеры меняются!” — можете возразить вы. “Телефоны становятся больше, планшеты становятся меньше!”

Однако срок годности CSS вашего сайта равен примерно 3 годам (конечно, если это не Gmail). В течение двух таких временных промежутков iPad был с нами и до сих пор не свергнут.

Так что 1024×768 остается надолго, друзья. Давайте не прятать головы в песок.

Вывод: общение очень важно. Не ограничивайте себя от полезной терминологии.

Совет #3: Будьте повествовательны

Знаю, знаю, снова это слово “повествовательность”. Другими словами, ваш CSS должен определять что должно произойти, а не как это должно произойти. “Как” можно спрятать в каком-нибудь миксине.

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

Сначал я написал приведенный ниже код как упрощенный пример. Но я думаю он покрывает все основные задачи. Чтобы заценить его в действии, посмотрите этот pen. Я использую Sass, потому что не могу представить разработку сайта без него. Эта логика применима и по отношению к CSS и Less.

Неоднозначность порождает путаницу.

Очевидным недостатком может быть то, что приведенный пример не поддерживает кастомные media-запросы. Однако, есть хорошие новости. Если вам нужен кастомный media-запрос, напишите кастомный media-запрос. (На практике, если мне нужна большая опциональность, чем приведено выше, то я бегу в объятия к своему любимому инструментарию Sussy)

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

Да, это работает. Но вы не получите ошибок компиляции, если передадите неподдерживаемый размер. Не говоря уже о том, что синтаксис @include for-desktop-up <. >выглядит приятнее, чем @include for-size(desktop-up) <. >.

Недостатоком обоих приведенных примеров может быть то, что я печатаю 600px дважды, и так же 599px. Конечно, мне следовало просто использовать переменные и вычитать еденицу там, где это нужно.

Если вы хотите сделать это, вперед, но я, конечно, делать этого не буду. На это есть пара причин:

О, и раз я уже перешел на повышенный тон в предыдущих параграфах… Мне жаль того дурака, который делает что-то прекрасное, как хранение брейкпоинтов в списке Sass, и делает цикл, который их обходит, чтобы вывести media-запросы, или что-то такое же нелепое, что заставляет последующих разработчиков ломать голову пытаясь это расшифровать.

Сложность — это место, где прячутся баги.

Подходя к концу, отметим, что вы можете думать “разве я не должен основывать брейкпоинты на контенте, а не на устройствах?”. Что ж, я поражен, что вы зашли так далеко, и ответ — “да”… для сайтов с одним макетом. Или если у вас есть много макетов и вам нравится создавать отдельный набор брейкпоинтов для каждого макета. О, и еще, если дизайн сайта не меняется часто или вам нравится менять брейкпоинты каждый раз, когда он меняется. Вы же хотите держать брейкпоинты основанными на контенте, так же?

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

На этом все! Но эта статья получилась не настолько няшной, как я хотел, так что дайте-ка подумать как мне исправиться…

Бонусные советы по созданию брейкпоинтов

Благодарю вас за чтение. Комментируйте, делитесь своими идеями. Я буду рад их услышать. И кликните на кнопку “поделиться”, если считаете, что я заслужил это, либо просто забейте на нее, если не боитесь, что я буду рыдать по ночам 🙂

Источник