Как сделать приложение responsive
Добавил пользователь Владимир З. Обновлено: 04.10.2024
Как-то мы рассказывали, что такое мобильная версия сайта, чем она отличается от адаптивной верстки. Напомним, что если для мобильной версии по факту создается отдельный сайт, то для адаптивной -- сайт один, а верстка сайта перестраивается под различные разрешения. Поговорим о сетке, которая позволяет этого добиться.
Вокабуляр
Прежде чем перейти к мелочам, давайте разберемся с терминологией.
Контентные блоки — это текст, изображение или и то, и другое. Цвет фона не считается контентным блоком, если он не является контейнером для текста или изображения.
Колонки — это блоки, которые составляют ширину контента дизайна. Элементы поля должны располагаться на определенном количестве колонок. Традиционно в дизайн-системе ширина колонок для разных разрешений не меняется, но вот их количество — да: с 12 колонок для десктопа меняется на 8 для планшета и на 4 для телефона. В основном у сеток ширина колонки составляет 60−80 пикселей.
Ширину колонки нужно подбирать под конкретный проект, т.к. от этого будет зависеть ширина контента на сайте.
Боковые поля — это пространство за пределами ширины контента (увеличивается по мере увеличения ширины устройства). На телефонах обычно они составляют 20−30 пикселей и сильно отличаются от боковых полей сайта на планшетах и десктопе. Но на на любом устройстве боковое поле будет сохранятся (хотя бы минимально) при уменьшении размера браузера.
Ширина контента будет зависеть от сетки, высота — от высоты экрана устройства.
Правила построения
Теперь перейдем к основным правилам построения адаптивной сетки.
1. Элементы поля должны располагаться на целом количестве колонок
Вы можете распределить элементы поля по колонкам как хотите: 6 и 6, 3 на 4, 4 на 3 — как угодно. Но в сумме колонок должно получиться 12, а элемент может занимать только целое число колонок (разместить его, например, на полутора колонках нельзя).
В этом примере карточки профиля, расположенные на разном количестве колонок:
Ок, пока все просто. А если вам нужно разделить контент на определенное число колонок? Вы идеально размещаете элементы на сетке, но элементы оказываются визуально слишком широкими:
Получается, что когда вы поместили эти элементы на сетку, текст растянулся в ширину слишком сильно. Так вот шепнем по секрету: используйте поля. Лучшим расположением текста на самом деле будет не по ширине сетки, а как на примере:
Так тоже можно, но вы должны понимать, что весь элемент — что-то вроде невидимого контейнера большего размера, чем сам контент в нем. Когда вы передадите дизайн верстальщику, он тоже должен это понимать.
2. Не оставляйте элементы поля в межколоночном интервале
Элементы должны находиться внутри колонок и не просачиваться в межколоночные интервалы, иначе весь смысл сетки сходит на нет.
3. Элементы внутри блока могут быть не выровнены по сетке, если выровнен сам блок
А как вам такая ситуация: нужно, чтобы карточка профиля делилась пополам: одна половина с текстом, другая с изображением. Ок, разделили.
Карточка профиля с родительским элементом, расположенным на шести колонках (слева), без выделения (в центре) и без сетки (справа). Источник
4. Не используйте колонку сетки как боковой отступ
Контент должен соответствовать ширине сетки — не больше, ни меньше. Но, если размер браузера уменьшается, а ширина его содержимого нет — это будет выглядеть странно, разве нет?. Нет, это работает не так. Все будет зависеть от того, как заверстали страницу: либо контент внутри сетки начнет пропорционально масштабироваться, а боковые поля останутся фиксированными, либо боковые поля будут масштабироваться одновременно с содержимым.
Поэтому, если вы попросите дизайн с шириной 1200 пикселей, это не значит, что дизайн буквально будет 1200 пикселей в ширину. Это означает, что ширина контента составит где-то 960 пикселей внутри сетки размером 1200 пикселей, ведь мы оставим местечко для боковых полей.
Дизайн должен заполнять всю ширину сетки (слева), а не оставлять столбец в качестве поля (справа). Источник
5. Элемент на всю ширину экрана или фон должны выступать за пределы сетки
Еще одна ситуация: хедер и футер не считаются частью основного контента. Кто-то предпочитает делать их на ширину экрана, кто-то — оставлять по ширине сетки. У обоих вариантов есть свои плюсы: если закрепить на ширину экрана, то остается много места для меню и навигации; если оставить футер и хедер в пределах ширины сетки, то пользователю очень многодюймового монитора не придется их искать.
Как это все работает
Традиционно в сетке ширина колонок и межколоночных интервалов остается неизменной, при изменении разрешения меняется только количество колонок. Почему и как это работает? Так сделали, чтобы упростить верстку.
На самом же деле верстка должна корректно отображаться при любой ширине браузера. Допустим, дома у вас большой монитор разрешением 3440 пикселей, дизайн десктопной версии сайта — 1920 пикселей, планшетной — 768 пикселей, а мобильной — 375 пикселей. Прямо сейчас вы, скорее всего видите дизайн с шириной контента чуть меньше 1440 пикселей с большими боковыми полями (если находитесь с настольного компьютера в офисе). А что если браузер на один пиксель меньше — 1339 пикселей? Тут несколько вариантов.
Адаптивная верстка
На адаптиве сайта при переходе от десктопа к планшету вы перейдете к следующей точке излома. Пока вы не достигните следующей точки излома, сокращаться будут только боковые поля (не контент). Текст не будет переносится, а изображения не будут динамически меняться. Если никто не позаботится о том, чтобы все размеры были учтены, какая-то точка излома может быть пропущена. Тогда сайт будет выглядеть обрезанным, пока вы не достигнете следующей после десктопа точки излома в 768 пикселей. Только тогда контент встанет на свои места и все будет выглядеть правильно для планшета. Если вы еще уменьшите масштаб, то произойдет все то же и сайт будет выглядеть так же, пока вы не достигнете следующей точки излома.
Отзывчивая верстка
По мере того как вы сжимаете окно, его содержимое будет динамически меняться: текст переносится, а элементы дизайна становятся более узкими. Даже если вы еще не достигли следующей точки излома, сайт будет адаптироваться под ваше текущее разрешение экрана. Здесь точки излома — это просто ориентиры.
Гибридная адаптивная верстка
Часто делают комбинацию из адаптивной и отзывчивой верстки. Такие сайты становятся отзывчивыми, когда отображаютися только на телефонах, т. к. вариантов размеров экранов — тьма.
От автора: в последнее время часто возникает потребность в быстром создании адаптивных веб-приложений, которые правильно отображаются на устройствах с различным разрешением экрана. Эта потребность обязывает разработчиков искать способы быстрого включения стилей в логику (функционал) приложения, давая им гибкость, позволяющую легко создавать веб-приложения, реагирующие на запросы, без написания CSS медиа-запросов.
В этом руководстве мы узнаем о react-responsive библиотеке и о том, как использовать ее с TypeScript в наших проектах. Мы также применим знания из этого руководства для создания простого адаптивного приложения-портфолио. Позвольте кратко объяснить некоторые знания о реальном значении реализации адаптивных веб-приложений.
Что такое адаптивный веб-дизайн?
Согласно MDN, отзывчивый веб-дизайн (RWD) — это подход к веб-дизайну, который позволяет веб-страницам хорошо отображаться на различных устройствах и размерах окон или экранов от минимального до максимального размера отображения. Последние исследования также рассматривают близость зрителя к части контекста просмотра как расширение для RWD. Контент, дизайн и производительность необходимы на всех устройствах, чтобы обеспечить удобство использования.
Реализация RWD в веб-приложениях дает таким приложениям возможность легко настраиваться и адаптироваться к постоянному изменению размеров экрана на устройствах. Создание приложений, которые являются адгезивными RWD, означает, что это веб-приложение имеет плавные и пропорциональные сетки, гибкие изображения и медиа-запросы CSS3, являющиеся расширением правила @media. В этом руководстве мы сосредоточимся на части медиа-запросов при реализации RWD в веб-приложении.
Что такое React-response?
React-responsive — это модуль медиа-запросов, который предоставляет медиа-запросы CSS в качестве компонента или хука для адаптивного веб-дизайна. Это очень полезно для рендеринга или удаления определенных стилизованных элементов в DOM — реструктуризировать DOM с точки зрения стилей CSS / Sass, в зависимости от разрешения / размера экрана.
React JS. Основы
Изучите основы ReactJS на практическом примере по созданию учебного веб-приложения
Использование react-responseive в наших проектах означает, что мы можем легко разделить контент, который хотим отображать, без написания для него каких-либо дополнительных стилей. Эти стили обрабатываются под капотом, предоставляя нам компонент или интерфейс хука, который мы можем использовать для установки значений max-width или min-width. Эти значения определяют, на каких размерах экрана содержимое будет отображаться или скрываться.
React-response или стилизованные компоненты
Прежде чем мы проведем сравнение между этими инструментами, стоит отметить, что в то время как react-responsive был сделан для брейкпоинтов с помощью пользовательских компонентов, стилизованные компоненты были сосредоточены на создании компонентов с пользовательскими стилями CSS. Это означает, что эти два инструмента можно объединить вместе, чтобы добавить на веб-страницу больше возможностей CSS. В то время как react-responsive больше фокусируются на инкапсуляции в качестве брейкпоинтов, стилизованные компоненты сосредоточены на добавлении большего количества стилей CSS через пользовательские компоненты.
Повышение качества ваших стилизованных компонентов потребует обработки медиа-запросов с помощью react-responsive, как показано ниже:
Дисклаймер: материал был написан до того, как адаптивная верстка стала трендом.
В интернете можно найти бесчисленное множество статей, посвященных адаптивной верстке. Но фактически они дерут друг у друга общие слова, а конкретики никакой. Так случилось, что надо было сверстать для заказчика адаптивную верстку для мобильных устройств.
Итак, для верстки нам потребуются следующие элементы:
- Общее понимание разрешений мобильных устройств.
- Задание размера viewport.
- СSSи MediaQuery.
Общее понимание разрешений мобильных устройств
Да, это именно так. Яндекс выдает нам множество вариантов. Становится ясно, что разрешений очень много. Верстать под все разрешения нет возможности.
Почти все браузеры, которые есть на мобильных устройствах, могут и используют ресайз страниц. Ресайз они делают на основе технических данных, получаемых от устройства. Их три:
- devicePixelRatio
- screen.width
- screen.height
Эти три параметра могут дать нам море информации. Пишем простую функцию:
Задание размера viewport
О viewport можно найти в поиске много мусора. Почти везде идет ширпотреб без объяснения логики. На самом деле тут всё очень просто:
Размер вьюпорта можно менять, используя следующую конструкцию в head:
Для верстки используем только два параметра width и user-scalable. Первым задаем размер видимой части, второй разрешает ее увеличивать (применять zoom двумя пальцами).
Обозначив width=device-width, мы сообщаем браузеру, что нам нужна область просмотра контента, равная ширине экрана мобильного устройства.
Можно вручную задать значение для width. Например content="width=600", но этого не рекомендуем, потому-что различные носимые устройства могут иметь абсолютно различную ширину экрана.
СSS и MediaQuery в мобильной верстке
MediaQuery разжевано на множестве сайтов, уделять внимание описанию не будем. Лишь опишем ряд проблем в виде маленького ЧАВО.
Какой диапазон выбрать для MediaQuery при адаптивной верстке?
В работе мы использует три брекпоинта для носимых устройств: 1024px, 800px, 420px. Это рекомендация, вы можете спокойно добавить свои.
Мелкий текст в адаптивной/мобильной верстке сайта.
Решение: стоит увеличить размер шрифта в соответствии с devicePixelRatio или просто в 1,5 раза. Например, так:
Изменяется размер шрифта при смене ориентации/вращении мобильного устройства.
Гироскопом уже никого не удивишь, его ставят китайцы даже в самые дешевые смартфоны. Удивить можно верстальщика. Решение:
Сбрасываем форматирование для элементов форм
Каждый браузер должен, нет, просто обязан быть уникальным. Исправляем косяк с различным форматированием элементов форм, отменяя дефолтные стили браузера. А уже дальше делаем, как на душе лежит.
Safari в IOs увеличивает шрифты в верстке
Mobile Safari в Ios (а также Chrome для Android, Mobile Firefox и IE Mobile) автоматически увеличивают размер шрифта внутри широких блоков. Это можно пофиксить двумя строчками CSS:
Область просмотра (viewport) - основная часть браузера, где отображается контент.
Чтобы @media запросы корректно работали на мобильных устройствах необходимо добавить специальный мета тег
Мета тег отвечает за размер области просмотра и масштаб страницы на мобильных устройствах
Мета тег размещаем в HTML файле в секции
Для мета тега добавляем атрибут content="" и указываем в нём необходимые свойства через запятую
width=device-width - область просмотра (viewport) будет равняться ширине мобильного устройства
initial-scale=1 - устанавливает масштаб страницы при первой загрузке
Этих свойств достаточно, чтобы @media запросы корректно работали на мобильных устройствах
Существуют дополнительные свойства, которые можно добавить для мета тега в атрибуте content=""
maximum-scale=3.0 - устанавливает максимально возможное значение масштабирования
minimum-scale=0.86 - устанавливает минимально возможное значение масштабирования
user-scalable=no - запрещает масштабирование
shrink-to-fit=no - исправляет отображение области просмотра (viewport) в браузере Safari на iOS
Как узнать размеры области просмотра (viewport)?
Для разработки и тестирования адаптивной вёрстки по размерам области просмотра (viewport) необходимо определить эти размеры
Браузеры Google Chrome и Mozilla Firefox имеют инструменты для тестирования адаптивной вёрстки, которые отображают размеры внутреннего окна и могут устанавливать необходимый размер окна по введенным значения
Чтобы открыть инструмент для адаптивной вёрстки в Mozilla Firefox нажимаем клавишу F12 и в инструментах разработчика в правом верхнем углу нажимаем на иконку со смартфоном и планшетом
Окно станет выглядеть следующим образом
В Google Chrome аналогично - нажимаем клавишу F12 и в инструментах разработчика в левом верхнем углу нажимаем на иконку со смартфоном и планшетом
Окно станет выглядеть следующим образом
@media запросы основаны на полной ширине окна браузера, включая полосы прокрутки - подробнее об этом в статье Плагин для отображения размеров окна браузера
Если кратко, то на мобильных устройствах и в браузерном инструменте для адаптивной вёрстки полоса прокрутки (scrollbar) не влияет на размеры контентной части, а в десктопных браузерах когда появляется полоса прокрутки (scrollbar), то она отнимает у контентной части около 17px. На мобильных контент будет на всю ширину браузера, а к примеру, на десктопных браузерах при ширине 1200px, если есть полоса прокрутки, то контентная часть будет около 1183px - этот нюанс не самый очевидный, но нужно его учитывать
@media запросы
Существует два подхода адаптивной вёрстки по размерам области просмотра (viewport) - Mobile First и Desktop First.
При Mobile First верстаем от меньшего экрана к большему и применяем @media (min-width: 1200px)
При Desktop First верстаем от большего экрана к меньшему и применяем @media (max-width: 1199.98px)
На практике Mobile First встречается реже, чем Desktop First, поэтому обычно сначала верстаем макет для больших экранов, затем с помощью @media запросов адаптируем макет под меньшие экраны, используя контрольные точки (breakpoints).
@media запросы записываются в CSS файле следующим образом
Разница в 0.02px нужна для избежания пересечения @media запросов, чтобы разные стили не применялись для двух разных @media запросов одновременно
Контрольные точки (breakpoints)
Для примера возьмем контрольные точки, которые используются в Bootstrap
Bootstrap использует @media запросы основанные на размерах большинства устройств, поэтому не обязательно придумывать свои контрольные точки, а при необходимости можно добавить еще @media запросы или изменить существующие
Логика адаптивной вёрстки Desktop First
Предположим, есть макет шириной 1170px. Верстаем его в браузере на большом экране. Пишем основные стили. Когда десктоп версия макета готова, начинаем делать адаптивную вёрстку.
Устанавливаем ширину окна браузера в 1200px - минимальная ширина до первого @media запроса @media (max-width: 1199.98px) < >.
Проверяем вёрстку при этих размерах. Если вёрстка соответствует макету, элементы не выходят за границы окна браузера, и не появляется горизонтальной полосы прокрутки, то продолжаем.
Устанавливаем ширину браузера в 992px - минимальная ширина до следующего @media запроса @media (max-width: 991.98px)
Делаем первый @media запрос - @media (max-width: 1199.98px)
При ширине окна браузера 992px элементы сужаются, выходят за границы окна браузера, создают горизонтальную полосу прокрутки (scrollbar). Поэтому внутри @media запроса @media (max-width: 1199.98px) < >начинаем переназначать предыдущие стили элементов так, чтобы вёрстка выглядела корректно - уменьшаем отступы, размер шрифта, какие-то элементы переносим или скрываем и так далее - все зависит от требований к макету.
Обратите внимание, что мы не должны переписывать все свойства элементов, а только переназначаем необходимые свойства
Если дизайнер не предоставил макеты на определенную ширину или заказчик не указал требования к адаптивной вёрстке, делаем на своё усмотрение, но соблюдая основную идею дизайна - уменьшать элементы и отступы пропорционально и переносить/скрывать блоки так, чтобы логика сохранялась
Когда вёрстка при ширине браузера 992px выглядит корректно, то устанавливаем браузеру ширину в 768px - минимальная ширина до следующего @media запроса @media (max-width: 767.98px) < >.
Переназначаем стили в блоке @media запроса @media (max-width: 991.98px) < >, чтобы вёрстка выглядела корректно теперь при ширине 768px
Далее устанавливаем ширину 576px и переназначаем стили в блоке @media (max-width: 767.98px)
Если дизайнер/заказчик не указали минимальную ширину для адаптивной вёрстки, то устанавливаем 320px. Для этой ширины переназначаем стили элементов в блоке @media запроса @media (max-width: 575.98px)
Когда вёрстка будет выглядеть корректно при всех вышеописанных размерах браузера (1200px, 992px, 768px, 576px, 320px), проверяем вёрстку плавно изменяя размер окна от большего к меньшему, чтобы убедиться что при промежуточных размерах вёрстка не ломается. При неоходимости корректируем стили элементов в том блоке @media запроса, где элементы отображаются некорректно, для этого используем инструменты разработчика (devtools) в браузере
Инструменты разработчика (devtools)
Инструменты разработчика позволяют быстро найти элемент, посмотреть его размеры, отступы, стили, расположение стилей, использование @media запросов, менять значение свойств прямо в браузере
Открыть инструменты разработчика можно нажатием клавиши F12
Чтобы просмотреть сразу расположение элемента и отобразить его свойства нажимаем правой кнокой мыши на элемент и выбираем Исследовать элемент в Mozilla Firefox или Просмотреть код в Google Chrome
Например, хотим узнать про элемент заголовка карточки, нажимаем на нём правой кнопкой мыши и выбираем Исследовать элемент в Mozilla Firefox
Открывается окно инструментов, где с левой стороны видим расположение элемента в HTML, а справой стороны CSS свойства элемента
Чтобы визуально посмотреть размеры и отступы элемента, в левой части инструментов разработчика наводим курсор мыши на элемент, и в браузере будут отображены свойства элемента
В правой части инструментов разработчика можно выбрать значение CSS свойства и назначить другое значение, в браузере сразу же будут видны изменения.
Значение можно писать вручную или постепенно менять значение стрелками вверх или вниз на клавиатуре.
При вводе значения вручную будут выводиться подсказки
Если значение некорректно и не применяется, то будет перечеркнуто
Можно самостоятельно отключить необходимое свойство, нажав на чекбокс перед этим свойством
Можно назначить новое свойство, нажав на пустое место в пределах блока свойств элемента. Также будут выведены подсказки возможных свойств
Все эти изменения сразу отображаются в браузере, что удобно при разработке и отладке адаптивной вёрстки. После перезагрузки страницы изменения сбрасываются
Также можно посмотреть расположение стилей - указывается имя файла, строка в файле и использование @media запросов
Простой пример адаптивной вёрстки
Полный пример на Codepen
Ниже распишу только ключевые моменты адаптивности
Начальные стили десктоп вёрстки при ширине 1200px
При ширине 992px карточки немного сужаются, но все еще отображаются корректно, поэтому пока без изменений
При ширине 768px карточки становятся очень узкими, поэтому переназначаем свойство карточки width , чтобы карточки отображались по две в ряд
При ширине 576px карточки также становятся узкими, поэтому снова переназначаем свойство карточки width чтобы карточки отображались по одной
При ширине 320px карточкам не хватает места, и они также выглядят довольно узкими, поэтому уменьшим внутренние отступы padding контейнера .container
Пример специально взял упрощенный, чтобы просто показать логику адаптивной вёрстки. Возможно, через некоторое время запишу видео с адаптивной вёрсткой более сложной секции и добавлю в эту статью
Дополнительно
Немного дополнительной информации по адаптивной вёрстке
@media запросы по размерам viewport могут быть как по ширине, так и по высоте, но используется обычно реже
@media запросы можно комбинировать, например нужны только стили для планшетных экранов в диапазоне от 576px до 767.98px
Стили назначенные в таком @media запросе будут применены только если все условия выполнены
Можно определять свойства сразу для нескольких разных условий - такой @media запрос выполняется если хотя бы одно из перечисленных условий выполнено, например экраны меньше 575.98px и больше 1440px
Для упрощения адаптивной вёрстки желательно использовать Flexbox, Grid.
Желательно стараться использовать не фиксированные, а относительные величины (%, vw, vh, em, rem и так далее)
Итоги
В статье разобрали основы адаптивной вёрстки, но этих знаний достаточно, чтобы начать делать адаптивную вёрстку.
На практике можно применять дополнительные возможности @media запросов отталкиваясь от уже полученной информации.
Читайте также: