Что такое брейкпоинт в верстке

Быстрые сетки для верстальщиков

Проблемы

Нестандартные сетки

Итак, у нашего верстальщика очень мало времени, макет горит, всё надо сделать вчера. Поэтому, он берёт для основы популярный css-фреймворк bootstrap, и начинает свою работу. И тут, в середине работы, он вдруг натыкается на блок баннеров «5 в ряд». Все, кто работал с bootstrap знает, что его сетка по умолчанию 12-кратная, поэтому 5 колонок в ряд стандартной бутстраповской сеткой ну никак не сделаешь. Да, конечно, в бутстрапе можно собрать произвольную сетку, но это время терять, качать зависимости, собирать less-ки (а мы, допустим, пишем на sass).

Поэтому, с большой вероятностью, верстальщик просто пропишет все стили вручную (там, в принципе, не так много писать).

Необходимость своего набора breakpoint-ов

Очень часто в стандартной бутстраповской сетке не хватает дополнительных брейкпоинтов, т. е. есть xs, sm, md, lg — все они до ширины 1200px. А как же большие мониторы? Какой-нибудь брейкпоинт xl на 1600px так и просится в стандартный набор. Но его опять же нет, и возникают те же варианты решения, что и в предыдущем пункте. А ведь контрольных точек может быть очень много — 320, 360, 640, 768, 992, 1200, 1600, 1900..

Избыточность и многословность

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

Не слишком ли много? Добавьте сюда возможные pull/push и visible/hidden и тогда можно смело начинать сходить с ума. А ведь все эти классы прописаны в css, представьте сколько нужно прописать классов в css для всех комбинаций 60-кратной сетки!

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

Перекрытие ненужных стилей

Чужие стандарты и code-style

Допустим, верстальщик изучил БЭМ и начал его применять. Но необходимость использовать bootstrap диктует свои исключения — в нём все классы пишутся через дефис, не следуя принципам БЭМ. И тут возникает проблема выбора — либо смириться с мешаниной в названиях классов ( btn-block disabled component__btn component__btn_disabled ), либо всё-таки выкинуть bootstrap.

Устаревшие методы

Как известно, сетки в bootstrap 3 основаны на float-ах. Что часто вызывает проблемы, одна из наиболее частых — различная высота блоков, в результате которой красивая сетка «ломается». Хватит использовать float-ы не по назначению, уже практически вымерли все браузеры, которые не умеют flexbox!

Susy! — это выход?

В поиске решения всех перечисленных выше проблем, я наткнулся на замечательный сеточный фреймворк Susy!, в целом очень хороший. Но мне не хватало скорости, т. к. susy! предлагал описывать колонки для каждого брейкпоинта отдельно:

Поиск других сеточных систем также не давал особо результата — все либо идут по пути susy!, забывая про breakpoints, либо идут по пути bootstrap, предоставляя набор сгенерированных классов для руления сетками в html.

Велосипедостроение

Итак, решено было написать что-то своё, в результате родился fast-grid. Он также, как и susy, построен на sass. Какие же главные преимущества он предоставляет по сравнению с другими решениями, в частности, с susy!? В первую очередь скоростью за счёт меньшего количества кода, возьмем стандартный bootstrap пример:

С помощью fast-grid такую сетку очень легко описать:

Давайте теперь пройдёмся по нашим недостаткам, и увидим как fast-grid решает все эти проблемы.

Источник

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 целый список переменных и цикл, проходящий по ним всем, чтобы определить нужный медиа-запрос, или пишет что-то ещё более нелепое, над расшифровкой чего потом будут биться его будущие коллеги.

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

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

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

Источник

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

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

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

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

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. Например:

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

Min-width

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

Max-width

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

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

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

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

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

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

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

Источник