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

10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Признайтесь, если вы пишете на Sass, наверняка же у вас есть переменная, скажем, $large со значением 768px ?

А это верхняя граница меньшего интервала или нижняя граница большего? И если это, допустим, верхняя граница, тогда мы вряд ли сможем определить $small , ведь ему придётся быть нулём.

А если это нижняя граница, тогда как вы определите брейкпоинт $large-and-up ? Получается, медиа-выражением с min-width равной $medium , так?

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

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

1. Правильно определяйте границы интервалов (сами брейкпоинты)
2. Правильно называйте сами интервалы
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 должен говорить о том, что произойдёт, а не как это произойдёт. “Как” стоит вообще спрятать в какой-нибудь миксин.

Как мы уже поняли, главная путаница в брейкпоинтах возникает потому, что переменные, обозначающие границу (как одно значение), мы используем для обозначения целого интервала. Переменная $large: 600px не имеет абсолютно никакого смысла, потому что large — множество значений. Это то же самое, как определить переменную var coordinates = 4; .

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

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

Заметьте, я склюняю разработчиков к использованию суффиксов вроде -up или -only .

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

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

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

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

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

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

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

1. Это не та часть кода, которая будет меняться часто. К тому же, вряд ли она будет использована где-либо ещё в кодовой базе. Поэтому нет никаких проблем в том, что это не переменные — если только вы не хотите динамически прокидывать эти значения брейкпоинтов через js на страницу.
2. Как только вы пытаетесь превратить числа в строки в Sass — синтаксис становится отвратительным. Ниже — как раз цена, которую вы заплатите, если сочтёте повторение одного и того же числа 2 раза худшим злом:

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

Все баги прячутся в излишней сложности.

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

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

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

Бонусные советы для breakpoint development

1. Если вам нужно проверить, как выглядит сайт на экранах больше вашего — используйте responsive mode в Chrome DevTools — там можно выбрать любой размер экрана.
2. Синяя полоса в верхней части экрана означает медиа-запросы со значением “max-width”, оранжевая — “min-width”, зелёная — и max, и min.
3. Клик по @media-запросу установит ширину экрана на ту, которая использована в нём. Последовательные клики по зелёному @media-запросу будут переключать между max- и min-значениями.
4. Правый клик по @media-запросу на панели откроет определение этого правила в CSS.

Хей, спасибо, что прочли! Если у вас появятся какие-то идеи — пишите в комментарии, буду рад увидеть их (оригинал статьи по ссылке — прим. пер.). И кликните на сердечко, если считаете, что этот лайк будет заслуженным. А если вы так не считаете — просто оставьте его пустым и униженным, каковой окажется моя самооценка в таком случае.

Это всего лишь вторая переведённая мной статья, и мне хочется делать переводы лучше и лучше. Если вам есть, что сказать по поводу ошибок, неточностей или опечаток, предложить идеи статей для перевода или вас просто вдохновили сурикаты с последней картинки — пишите комментарии, я действительно читаю их, даже (особенно) если они про сурикатов:)

How to Use CSS Breakpoints for Responsive Design, Most Common Media Breakpoints + Tips

CSS breakpoints are values that determine how a website looks on different screen sizes. When visitors’ devices reach their breakpoints, the website content responds and adjusts accordingly.

These breakpoints, together with CSS media queries, are responsible for a responsive website design. In short, they make your website look proportional when viewed on a different screen size.

In this article, we’ll show you how to implement CSS breakpoints for your site. You will also get tips on how to use breakpoints for a responsive web design.

What Is a CSS Breakpoint?

A CSS breakpoint is a value that determines a website’s size and layout across different screen sizes. It creates a responsive website design when implemented with a CSS media query.

A breakpoint’s value is set based on the user’s device height or width. While it is typically shown in pixels, breakpoints can also use CSS units like em, rem, or percentages.

With breakpoints and media queries, you can define different conditions and adjust your site content based on them. For instance, you can show the navigation bar only on large devices.

To apply breakpoints and media queries, you can only use an external CSS type. To do so, you must create and link a stylesheet to your site’s HTML file.

How to Set CSS Breakpoints

There are two ways of setting CSS breakpoints – based on the device or site’s content.

Suggested Reading

Before proceeding, check out our CSS cheat sheet if you are unfamiliar with the styling language.

How to Use Breakpoints Based on Device

Breakpoints can use the device’s width and length as the parameters, typically shown in the pixel values. Here’s an example of them:

However, determining device-based breakpoints might be tricky since their screen resolutions vary. It is also time-consuming since developers must add CSS breakpoints every time a new device is released.

Instead of setting a breakpoint for specific devices, you can group them based on resolutions. Here’s the code example:

While it’s possible to set breakpoints only for popular devices, we don’t recommend it since your target audience may use various devices.

How to Use Breakpoints Based on Content

You can set your breakpoints based on your site’s content. As a result, you won’t need to add a new breakpoint whenever a device comes out, saving time and keeping your site code clean.

With this method, you add breakpoints on the positions where the content starts to look misaligned or distorted when rendered on a different screen size.

You can set the parameter in two ways – using a minimum width pixel value or range. For example, the following will run the CSS code for devices with a min screen width of 720 pixels:

Meanwhile, the following applies if the device width is between 720 and 1280 pixels:

How to Use min-width or max-width CSS Breakpoints

Additionally, you can set breakpoints using a specific value with min-width, max-width, or both to define a range. Each of them is ideal for a particular use case.

Use min-width breakpoints when developing a website with the mobile-first approach. It means you set the default CSS for the smaller screen and adjust it for larger devices.

Conversely, when developing for larger devices, use max-width breakpoints and rearrange your website for smaller screens. Use both only when you are particular about your site’s appearance on a certain device.

Pro Tip

In addition to screen adjustment, you can use breakpoint with other media queries like print and speech.

Media Query Breakpoints

To set your media query breakpoints, determine what devices visitors use to render your website. They may use computers, tablets, or mobile phones.

The common breakpoints for these devices are based on their resolution. Some of the most popular ones are 1920×1080, 1366×768, and 360×640.

Alternatively, you may use different frameworks’ breakpoints. Since they are optimized for the mobile-first approach, use them as references when developing for larger-screen devices.

Here are a few examples of popular frameworks with their breakpoints:

– 576px, 768px, 992px, 1200px, and 1400px. – 640px, 1024px, and any size for smaller devices. – 768px, 769px, 1024px, 1216px, and 1408px.

Tips for Using CSS Breakpoints for Responsive Design

Consider the following tips when using CSS breakpoints to ensure your website’s responsiveness.

Minimize HTML, CSS, and JavaScript

Minifying your site code helps improve your site responsiveness by removing unnecessary characters.

Simpler code runs more efficiently, allowing your site to adjust its layout more quickly. It is especially beneficial if your site uses multiple breakpoints and CSS media queries.

Prioritize Mobile Devices

When designing a website, set your default styles for small devices and adjust them for bigger screens. It ensures your website is mobile-friendly and responsive across different devices.

Prioritizing mobile devices also helps simplify the development process since designing for smaller screens is more complicated.

Simplify the Mobile View

In addition to resizing, simplify your website for a mobile view. It helps improve your page’s loading speed and usability across different platforms.

To optimize your website for mobile viewing, remove unnecessary content and rearrange its navigation. Use breakpoints to allow the site to hide and reposition those elements automatically.

Name Your Ranges Sensibly

Your breakpoints ranges should be descriptive and easy to understand. Ideally, the range should specify the device’s type and orientation, like “portrait iPhone X.”

For device groups, use names that describe their screen sizes, such as “medium landscape tablets” or “large portrait smartphones.”

Use DevTools to Enter Large Numbers on Larger Screens

You may need to create a breakpoint for screens larger than your device. In that case, use Google DevTools’ Toggle Device Toolbar feature to simulate how the breakpoints look on different viewport sizes.

To access it, open Google Chrome’s inspect element and find the phone and tablet icon. At the top, you will see dimension fields where you can enter a custom screen resolution.

Conclusion

CSS breakpoints determine a website’s size and layout on different screen sizes. They work with CSS media queries to allow your site to adjust itself according to users’ devices.

You can set breakpoints based on the device’s screen size or the website’s content. We don’t recommend the former since you must add more lines of code whenever new devices come out.

To set your breakpoint, define the target device’s screen min and max width. Alternatively, use the ones that the web development framework provides, like bootstrap breakpoints.

When it comes to ensuring your website is fully responsive, don’t forget to minify your site code, name your ranges sensibly, and use the mobile-first approach.

Besides setting CSS breakpoints right, remember to choose a suitable web hosting service to ensure your site is accessible and works fine.

CSS Breakpoints FAQ

In this section, we’ll answer some common questions about CSS breakpoints to help you understand them more.

Can Breakpoints Use Pixels, Ems, or Percentages?

Yes, you can use pixels, ems, and percentages. Min and max-width breakpoints also support different property values like cm, mm, and pt.

Which CSS Unit Is Best for Responsive Design?

Relative units like percentages are ideal for responsive design as they can adjust based on the parent element.

Which CSS Breakpoints Should You Use With SASS?

With SASS and SCSS, use the @mixin breakpoint. It allows you to create more declarative breakpoints that are easier to reuse throughout your website.

Aris is a passionate IT professional and WordPress enthusiast. He loves to share his knowledge and inspire people to start their online journey. When he’s not working or blogging, Aris enjoys watching gadget reviews and scribbling random doodles.

CSS breakpoints for responsive design

Responsive web design is an approach to make webpages render well on all screen sizes and resolutions while ensuring usability is high.

In this article, we’ll look at the evolution of responsive design, from media queries to grid systems, container queries, and finally fluid design. We’ll discuss the role of breakpoints in responsive design, reviewing different methods of choosing breakpoints and some best practices.

The evolution of responsive design

HTML is fundamentally responsive. If you create a webpage using only HTML and resize the window, the browser will automatically adjust the text to fit the viewport. However, your content will not look good on every screen!

For example, long lines of text can be difficult to read on a wide monitor. Similarly, if the line length is reduced with CSS, by creating columns or adding a margin, the content may look squashed when viewed on a mobile device. You have to intervene to adapt the style to the screen, based on the content and layout of your webpage.

The term responsive design was coined by Ethan Marcotte in 2010 and described using fluid grids, fluid images, and media queries to create responsive content. At the time, the recommendation was to use float for layout, and media queries to query the browser width or height to create layouts for different breakpoints.

A breakpoint is the point, usually a specific width, at which a webpage’s style is adapted in a particular way in order to provide the best possible user experience. Fluid images were set to not exceed the width of their container, by setting their max-width property to 100% . The prevailing attitude was to control every pixel of a layout for a given screen size.

Frameworks like Bootstrap rose in popularity as they provided developers with responsive grid systems. This contributed to a shift in the way we build and think about webpages. With the advent of design systems, there is a tendency to think in terms of components rather than pages. We combine components to make up a page and want them to live side-by-side without having to write a lot of CSS to create a harmonious layout.

With modern CSS, less intervention is required to resize or change layouts for different screen sizes. Layout methods such as Flexbox and CSS Grid have responsive capabilities, and other modern methods have been developed to make content responsive:

: Allows typography and spacing to be responsive to the viewport width : Enables a component to be responsive to its wrapper : Permits spacing to be responsive to the language of the website

In 2018, Jen Simmons introduced the term “Intrinsic Web Design” in her talk “Everything You Know About Web Design Just Changed.” Here are her three principles of intrinsic web design:

1. Contracting and expanding: The way we consider how our design will adapt to a change in available space
2. Flexibility: Using modern CSS functions to adapt to the available space
3. Viewport: The ability to use the width and height of the viewport as input to a responsive design

Today, more people generally advocate going with the grain with regard to how content adapts to the space available. As Andy Bell put it recently, maybe our preference should be to: “be the browser’s mentor, not its micromanager.”

With the recent introduction of container queries, we are entering a new era of responsive design. Container queries allow us to look at a container size and apply styles to the content based on the size of their container rather than the viewport or other device characteristics. I see this more as an evolution than a revolution because now CSS can align more easily with component-based thinking.

Some people see container queries as a departure from what came before because now a design can be largely independent of the viewport size. However, container queries still involve breakpoints. So, we still need to consider where and when (at what point) to change the style of content.

While we have moved on from float for layouts, media queries are still relevant. They are just required less frequently than before. People have been predicting the end of media queries with the introduction of container queries, but container queries do not solve everything. Media queries still have a seat at the table. It will take some maturation before the roles are worked out with more clarity.

Let’s cover media queries first before we dive into breakpoints.

What are media queries?

Media queries are useful when you want to modify the layout or appearance of your site depending on specific characteristics such as the screen resolution of the device or the browser viewport width or height.

A media query is composed of:

1. An optional media type defining a broad category of devices to which the media query applies: all , print , or screen . This type is optional; it is assumed to be all if omitted
2. Any number of media feature expressions describing a specific characteristic of the user agent, output device, or environment. Examples are: hover , prefers-reduced-motion , and width

The common syntax for a CSS media query is as follows:

The logical operators not , and , only , and or can be used to compose a complex media query.

For responsive design, min-width and max-width are the most commonly used media features. They enable styles to be based on the width of the viewport. For example, the following CSS code will apply styles only if the browser’s viewport width is equal to or less than 80em :

You can also use height ( height , min-height , and max-height ), aspect-ratio , resolution , and orientation in media feature expressions to deal with the viewport’s dimensions and different aspects of the screen.

The Media Queries Level 4 specification includes some syntax improvements to make media features that have a less verbose “range” type, e.g., width . With this syntax improvement, our previous max-width example could be written like so:

How do you choose breakpoints?

A breakpoint is the point, usually a specific width, at which a webpage’s style is adapted in a particular way in order to provide the best possible user experience.

There are two broad approaches when choosing CSS breakpoints; one is based on devices and the other is based on content. Let’s take a look.

Breakpoints based on device

You can target and produce a different design for specific screen sizes. A design may work across multiple screen sizes, however, the content may be narrower when less space is available.

Over 200k developers use LogRocket to create better digital experiences

Learn more →

With the breadth and variety of devices available, determining breakpoints based on screen sizes is challenging. This approach is really not feasible to maintain:

To simplify this approach, people tend to loosely group devices based on a range of sizes. It’s really up to you to choose the groupings and specific breakpoints. The most common way is to group devices based on form factor (e.g., mobile devices, tablets, laptops, etc.):

Here is some data you could use to arrive at this decision:

For example, David Gilbertson wrote an article in 2016 with the ambitious title: “The 100% correct way to do CSS breakpoints.” I am always skeptical of such clickbaity claims! However, David’s approach was solid. He arrived at his set of breakpoints by taking the 14 most common screen sizes from StatCounter for 2016 and grouping them using four broad ranges. He avoided selecting screen widths that were on the upper or lower limit of the ranges. Ultimately, David settled on 600px, 900px, 1200px, and 1800px.

You will find that most methodologies arrive at a set of breakpoints in a similarly approximate fashion.

Below is an example of a set of media queries covering four broad categories of devices:

Breakpoints based on content

This next approach is based on changing the design at the point where the content starts to break in some way. If the line lengths become too long, or if a section gets too squashed, that’s where you need to consider changing the style. In other words, that’s the point where you want to use a media query or container query to change the design.

The responsive mode in browser developer tools (Responsive Design Mode in Firefox DevTools and Device Mode in Chrome DevTools) is very useful for working out where your breakpoints should go. You can easily make the viewport smaller or larger to see where the content style could be improved:

In the menu, you can choose devices from a list. In the screenshot above, I have chosen Galaxy Note 20. You can change the orientation (e.g., portrait, landscape) as well.

You can drag one side of the viewport to slowly increase the width and see how the content adapts to different viewport widths. In the video below, you can see me doing this with the MDN @media page. At 769px, you’ll notice that the layout changes with the sidebar appearing on the left:

Jeremy Keith called out that some breakpoints are for minor adjustments, he calls them tweakpoints:

“When I was working on Matter, for example, there was really only one major breakpoint, where the layout shifts from one column to two. That’s the kind of breakpoint that you can figure out pretty easily from the flow of your content; just resizing your browser window is usually enough to settle on the point that feels right. But there are lots of other media queries in the Matter stylesheet. Those are there to make smaller adjustments to margins, font sizes …the kind of changes that came about from testing on phones and tablets in the device lab.

It feels a bit odd to call them breakpoints, as though the layout would “break” without them. Those media queries are there to tweak the layout. They’re not breakpoints; they’re tweakpoints.”

Overall, this is an organic process that is guided by what you are specifically making. Adjacent to this is the understanding that if you have a mastery of modern CSS, you will find that you need to intervene less with media queries if you build things to scale according to the available space.

Which approach should you follow?

I wouldn’t say that there is one path to follow here. However, I recommend that you do not constrain yourself by thinking only in terms of particular devices. Instead, focus more on utilizing the space available to your content.

Generally, we will use media queries less as time goes on. Media queries are likely to still be used for components that are tied to the viewport width like the website’s main navigation and footer. In other cases, you can design content to be fluid, or adapt to the container size through container queries.

There can be value in having a set of breakpoints. Whether you take a set from the first approach or come up with the breakpoints organically through testing the interface is up to you. I would say that it is easier to debug layout issues when you have a set of breakpoints, rather than having many adhoc breakpoints.

More great articles from LogRocket:

• Don’t miss a moment with The Replay, a curated newsletter from LogRocket how LogRocket’s Galileo cuts through the noise to proactively resolve issues in your app
• Use React’s useEffect to optimize your application’s performance
• Switch between multiple versions of Node your React app with AnimXYZ , a new framework for building binaries
• Compare NestJS vs. Express.js

However, having a set of 6 breakpoints does not mean you should use them all to adjust a layout or style! Look to minimize intervention – look for opportunities for the content to do the work for you!

What breakpoints do popular CSS frameworks use?

According to the State of CSS survey, the most popular CSS frameworks of 2022 (ordered in terms of usage) are:

Let’s look at what these popular frameworks do.

Bootstrap uses a 12-column grid architecture, which influences its choice of breakpoints. Bootstrap describes its methodology for choosing breakpoints as follows:

“Each breakpoint was chosen to comfortably hold containers whose widths are multiples of 12. Breakpoints are also representative of a subset of common device sizes and viewport dimensions—they don’t specifically target every use case or device. Instead, the ranges provide a strong and consistent foundation to build on for nearly any device.”

Ant Design also follows the Bootstrap 4 media queries rules.

Tailwind has five default breakpoints that are inspired by common device resolutions:

PureCSS favors em for its default widths instead of px to support zooming on webpages.

Here’s a summary of breakpoints for some of the other frameworks:

: <640px, ≥640px, ≥1200px : <769px, ≥769px, ≥1024px, ≥1216px, and ≥1408px : <768px, ≥768px, ≥992px, ≥1400px, ≥1920px : <544px, ≥544px, ≥768px, ≥1012px, ≥1280px : <479px, ≥480px, ≥768px, ≥960px, ≥1200px

Common practices for breakpoints

Here are some important best practices to keep in mind regardless of which CSS framework you ultimately select:

1. Design for mobile first: With approximately 59% of overall web traffic coming from mobile devices, it makes sense to favor designing for mobile screens. Prioritizing design for mobile devices also ensures that key constraints are tackled early. However, having less space is more challenging; it compels designers to remove anything that isn’t necessary. Once you’re happy with the mobile layout, you can add and adjust for larger screens
2. Use relative units: Using relative units, such as em , allows the media queries to respond appropriately when people zoom into the webpage. Check out this article by Brad Frost for some background on using relative units within media queries
3. Avoid breakpoints that push devices into much smallerorlarger ranges: One thing you‘ll notice from the breakpoints chosen by CSS frameworks is that their cutoff for tablet-sized devices is around 768px. This is because older generations of iPad (now iPad mini) have a resolution of 768px by 1024px. If you have breakpoints with broader ranges, be mindful of these cutoff points. Usually, you’ll see 768px and above as the medium breakpoint category. If you’re basing breakpoints on content, this is less of a concern

Do you really need breakpoints?

Some techniques have emerged that allow elements to scale proportionally and fluidly without using breakpoints. Sometimes this is referred to as fluid design.

Many fluid design techniques use mathematical functions available in CSS such as: clamp() , min() , and max() , along with dynamic units based on the viewport such as vh and vw to create expressions that will scale elements. If you would like to learn more about this, here’s an article on flexible layouts without media queries.

One systematic approach to fluid design is Utopia. Utopia advocates for designers and developers to share a systematic approach to fluidity in responsive design. Instead of designing for any particular number of arbitrary breakpoints, you design a system within which elements scale proportionally and fluidly. This can help you to:

• Design and code minimally and elegantly
• Streamline collaboration between design and development roles
• Ensure visual harmony and consistency

Utopia is like a fancy calculator that will spit out some CSS; just input some dimensions and a preferred scale to determine the range of values.

For example, this is how the fluid space calculator looks:

If you use clamp() in Utopia’s calculator, it will generate the following CSS snippet:

No media query is required here. You can use these CSS variables in your padding and margins to create proportional spacing between elements throughout your website.

You can achieve fluidity with typography, spacing, and grid-based layouts. However, this may not be enough to make a completely responsive website.

Final thoughts

Responsive design is challenging, but it’s getting easier. Nowadays, choosing breakpoints is less fraught. There’s wider acceptance that we are not trying to create a pixel perfect rendering of a website across many screen sizes.

CSS has evolved a lot and now it is possible to create fluid designs that adapt to the available space and require less intervention. However, it is still important to understand breakpoints, you will need them sometime!

Now you can choose breakpoints according to the content and the design task in front of you, rather than follow a prescribed path. There is the option to implement breakpoints according to the viewport (media queries) or according to blocks of elements (container queries). This will simplify the process of creating responsive designs in the long run.

As of this writing, container queries are still new. So, we will need to be good students, and shift our habits to embrace this multi-paradigm landscape.

Is your frontend hogging your users’ CPU?

As web frontends get increasingly complex, resource-greedy features demand more and more from the browser. If you’re interested in monitoring and tracking client-side CPU usage, memory usage, and more for all of your users in production, try LogRocket.https://logrocket.com/signup/

LogRocket is like a DVR for web and mobile apps, recording everything that happens in your web app or site. Instead of guessing why problems happen, you can aggregate and report on key frontend performance metrics, replay user sessions along with application state, log network requests, and automatically surface all errors.

Медиа-запросы и брейкпоинты для адаптивной верстки

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

Но есть более менее устоявшиеся значения.

• 0
• 576px
• 768px
• 992px
• 1200px
• 1400px

Когда-то я использовал такие:

• 320px
• 640px
• 960px
• 1280px
• 1920px

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

Подробнее можно изучить в официальном источнике.

Короче используем min-width или max-width , или их сочетание.

На пальцах (разрешения взяты для примера):

1. @media (min-width: 1200px) — контейнер стилей для устройств с минимальной шириной экрана в 1200px.
2. @media (min-width: 992px) and (max-width: 1199px) — для устройств с минимальной 992px и максимальной 1199px,
3. @media (max-width: 767px) — для устройств с максимальной шириной экрана в 767px.

Первый я называю адаптивка на минах, второй диапазонный, последний на максах.

Для правильного использования медиа-запросов важно знать две вещи:

1. Чаще всего сайт верстается от бОльшего разрешения к меньшему. То есть сначала для десктопа, а потом подгоняется под устройства всё меньше и меньше, в сторону уменьшения.
2. В css-файле чем ниже написаны стили (ближе к концу), тем они приоритетнее, то есть они перезаписывают предыдущие.

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

адаптивная верстка на максах

Самым безопасным (чтобы ничего не перепутать) и понятным можно взять для себя такой способ:

Получается наиболее четкая и ясная картина.

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

Внимание! Разрешение, которое прописано в медиа-запросе НЕ ВХОДИТ само в этот диапазон! Т.е. запись @media (max-width: 990px) будет работать для 989px включительно, но без 990px.

UPD. Постепенно начало набирать такое понятие, как mobile-first. То есть мобильная версия сайта верстается первой, а потом подгоняется под разрешения побольше. Но это вкусовщина, я считаю. Внимательный верстальщик сделает так, что итог будет одинаковый, и неважно с какого конца начинать.

На сегодня лично мои рабочие брейкпоинты для мобильной верстки такие (на максах):