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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скажите, если вы делаете брейкпоинты в Sass, создавали ли вы переменную $large со значением 768px?

Это нижняя или верхняя граница, которую вы относите к large? Если нижняя, то у вас не должно быть $small, так как она должна быть равна 0, так ведь?

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

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

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

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

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

будьте декларативны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Может, мой взгляд предвзятый, но это пример хорошо декларированного CSS кода. Обратите внимание, что я вынуждаю разработчиков использовать суффиксы –up и –only.

Двусмысленность порождает путаницу.

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

Также код можно раскритиковать за 8 миксинов. Можно все переписать в один миксин и передавать необходимый размер, вот так:

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

Не говоря уже о том, что синтаксис @include for-desktop-up {…} намного красивее, чем @include for-size(desktop-up) {…}.

Минусом в двух кусках кода будет то, что я дважды использую 900px, а также 899px. Нужно просто использовать переменные и вычитать единицу по необходимости.

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

Эти цифры не так часто меняются, и они не используются где-то еще в коде. Проблем не возникнет, если эти цифры не представить в виде переменных. Если, конечно, вы не откроете свой Sass код скрипту, который вставляет JS объект с этими переменными на страницу.

Ужасный синтаксис, если нужно преобразовать цифры в строки с помощью Sass. Ниже показана плата за веру в то, что повторение чисел – это худшее из зол:

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

Баги кроются в сложностях.

Наконец, вы можете подумать: «а не должен ли я определять брейкпоинты по контенту, а не устройствам?». Удивлен, что вы так далеко зашли, и ответ будет да… для сайтов с одним макетом. Ну или если у вас много макетов, и вы не против задавать разные брейкпоинты для всех макетов. Также ответ будет да, если дизайн на вашем сайте меняется довольно редко, или вы хотите поменять все брейкпоинты при обновлении дизайна, чтобы они основывались на контенте.

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

Мы закончили! Статья вышла не такой «пушистой», как я. Могу ли я найти предлог, чтобы добавить… О, знаю!

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

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

Даже на flickr брейкпоинты на 768 и 1400

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

Голубая панель показывает max-width медиа запросы, оранжевая – min-width медиа запросы, зеленая панель показывает min и max медиа запросы.

Если кликнуть на медиа запрос, ширина экрана изменится на указанную в запросе. Два клика по зеленой панели переключают между минимальной и максимальной шириной.

Перейти к объявлению правила в CSS можно правым кликом по медиа запросу в панели медиа запросов.

Автор: David Gilbertson

Источник: //medium.freecodecamp.com/

Редакция: Команда webformyself.

Метки:

Похожие статьи:

Комментарии Вконтакте: