[ad_1]
Независимо от того, как вы работаете, реализовать принципы адаптивного веб-дизайна (RWD) в большом и сложном проекте может быть непросто. Нравится вам это или нет, но достижение священной земли кросс-платформенных макетов для нескольких устройств сопряжено с ощутимыми накладными расходами.
Чем больше точек останова и сетки меняет ваш контент и фреймворк, тем сложнее и трудоемче становится поддержка проекта. В худшем случае элегантное начало может превратиться в кошмар конкретики и запутанных деклараций. Потенциально влияет на производительность вашего сайта из-за раздутого CSS и повышенной загрузки страницы.
Расширяя уже хорошо задокументированные адаптивные методы, мы постараемся сформировать предсказуемый шаблон адаптивного масштабирования, который может привести к более чистому и легкому CSS и повышению удобства сопровождения.
Сочетая макет на основе em и типографику с гибкой шириной, мы можем обслуживать согласованные дизайны для больших экранов, в которых все элементы в полной мере используют доступную площадь экрана и разрешение. Измените макет один раз, и вы можете быть спокойно уверены, что изменение отразилось на всех ваших точках останова, и все они контролируются одним объявлением CSS. Звучит хорошо для вас? Давайте начнем.
Работа с экраном
Суть любого адаптивного сайта заключается в определении того, как основные и второстепенные точки останова позволяют гибкой сетке сворачиваться или, в равной степени, расширяться. Независимо от вашего предпочтительного рабочего процесса, создания визуальных элементов с помощью модульного руководства по стилю или проектирования в браузере, именно ширина области просмотра и ее влияние на наш контент должны определять наши дизайнерские решения.
Но ширина области просмотра — это еще не все. Нам также приходится иметь дело с множеством физических размеров экрана с разными разрешениями. Ваш контент может быть как увеличен, так и уменьшен в зависимости от дисплея. Это может оказать заметное влияние на удобочитаемость вашего контента и эффективность макета. Например, типографика, настроенная так, чтобы она выглядела удобно на большом экране, будет совершенно неуместна для устройства меньшего размера.
Это не новая проблема. Фактически, разрешение экрана всегда было ограничивающим фактором при разработке веб-сайтов. Помните сетку 960 или дизайн для 760 до этого? Гибкий подход RWD к компоновке помог нам преодолеть это ограничение. Тем не менее, он все еще может таить в себе некоторые проблемы и, что удивительно, возможность.
Пропорциональное мышление
Во многих отношениях адаптивная типографика уже в какой-то мере помогла нам решить проблему. Часто можно встретить сайт, на котором заголовки и текст уменьшаются в размере по мере того, как экран сжимается.
Хотя текст инициируется сужающимся окном просмотра, текст также можно рассматривать как применяющий соответствующее масштабирование для разрешения экрана. Уменьшение размера шрифта становится приемлемым, потому что уменьшению частично противодействует увеличение при меньшем разрешении. Самый распространенный и, возможно, самый неэффективный подход к адаптивной типографике — это простая стилизация, а затем изменение стиля элементов в отдельных контрольных точках. Скрипты на стороне клиента также часто используются для динамического изменения размера заголовков, чтобы максимально увеличить их размер, чтобы он соответствовал доступному пространству, FitText (откроется в новой вкладке) и slabText (откроется в новой вкладке) является одним из наиболее популярных проектов с открытым исходным кодом. Но есть и другой подход, простая, но мощная техника, которая должна нас заинтересовать.
Управление масштабом с относительными единицами
Без сомнения, вы использовали пиксели для определения типографики и макета, а почему бы и нет? Преобразование дизайна в HTML требует общего блока, и нет ничего плохого в использовании пикселей. Но есть недостаток. Пиксели — это абсолютные значения, игнорирующие контекст их окружения. (Часто считается, что один пиксель CSS соответствует физическому пикселю экрана. В мире высокой четкости это не всегда так.)
Эмы бывают разные. Определяемые как относительная длина шрифта, они прямо пропорциональны размеру шрифта родительского элемента. Определение этого значения в процентах приведет к масштабированию любых дочерних атрибутов, определенных в ems, по этому коэффициенту. Установив размер шрифта в корне документа, вы глобально повлияете на типографские пропорции.
Давайте создадим базовый документ с размером шрифта HTML 100%, с заголовками в формате ems. Теперь уменьшите размер шрифта HTML до 80%. Все, что определено в ems, будет масштабироваться на 80%. Мы можем лучше воспользоваться этим с введением медиа-запросов.
Например:
@media screen and (max-width: 55em) {
html { font-size: 80%; }
}
Имитируя различную ширину области просмотра, вы можете почувствовать, как теперь масштабируется наша типографика. Это может работать в обоих направлениях, определяя размер шрифта выше 100% мы также можем увеличить наш текст.
@media screen and (min-width: 75em) {
html { font-size: 135%; }
}
Простая предпосылка, но мощная. Используя этот метод, вы можете эффективно управлять типографским размером всего сайта с помощью одного объявления CSS, полностью избегая необходимости многократного нацеливания на отдельные элементы. Если вертикальный ритм вашего документа состоит из относительных единиц, он также будет прекрасно масштабироваться. Найдите живой пример этого на CodePen (откроется в новой вкладке).
Добавляем немного структуры
Как мы видели, определение нашей типографики с помощью ems может позволить нам в полной мере использовать его относительные свойства. Но em допустимы не только для типографских элементов, мы можем использовать их для определения любого измерения CSS, и при этом мы свяжем их реляционными отношениями с корневым размером шрифта.
Звучит отлично. Но если вы не будете осторожны, ems может вызвать проблемы. Когда они вложены, они могут привести к нежелательному масштабированию за счет наследования. Но у ems есть более дружественный к наследованию аналог в виде rems.
Rem работает так же, как и em, с той лишь разницей, что он обращается непосредственно к корневому размеру шрифта для своего реляционного значения. Это решает нашу проблему наследования и идеально подходит для нашего приложения.
Хотя rems широко поддерживались ведущими браузерами примерно в то же время, что и медиа-запросы, однако для поддержки до CSS мы можем использовать значения px в качестве запасных единиц.
Расширяя наш предыдущий пример, давайте добавим немного больше структуры, убедившись, что весь наш макет и типографика определены в rems за одним исключением. Из-за проблемы с Safari нам нужно определить наши медиа-запросы в стандартных ems. Вы можете просмотреть расширенный пример на CodePen (откроется в новой вкладке).
После этого весь макет теперь масштабируется, уменьшаясь по мере сужения экрана и увеличиваясь по мере его расширения. Но важно то, что он остается пропорциональным как нашей типографике, так и окружающей ее структуре. Но, давайте будем честными, без гибкой сетки в основе мы далеки от действительно адаптивного макета. Нам нужен план.
Мы по-прежнему можем достичь нашей гибкой компоновки точно так же, как мы обычно подходим к адаптивной сборке. Нам просто нужно проявить немного дисциплины, когда мы вводим проценты в микс. Полезно визуализировать две отдельные плоскости эффекта в нашем документе.
План атаки
По горизонтали: все, что составляет общую ширину документа, определяется в процентах. Это включает в себя: ширины, поле, набивкаа также пограничный левый а также Правильно.
Вертикаль и все остальное: указывается в бэрах и привязывается к корневому размеру шрифта документов, это должна быть наша единица измерения по умолчанию, в том числе: мин- а также Максимальная ширина, Топ а также нижний родственник, и абсолютный позиционирование.
Применим это к действию:
html { font-size: 100%; }
h1 { font-size: 2.75rem; }
h2 { font-size: 2.125rem; }
.wrapper {
width: 100%;
min-width: 50rem;
margin: 0 auto;
}
.header {
position: relative;
width: 100%;
height: 3rem;
}
.header-logo {
position: absolute;
top: 1rem;
left: 6%;
width: 5rem;
padding: 1.3rem 1.5rem;
}
.article {
overflow: hidden;
}
.article-content {
float: left;
width: 56%;
padding: 2rem 6% 4rem;
}
.article-aside {
float: right;
width: 26%;
padding: 1.5rem 5% 3rem 0;
}
.article-figure {
padding: 0 2%;
}
.article-figure > img {
margin: 1.5rem 0 0;
}
.auxiliary-list
{
margin: 0;
padding: 0 0 0 6%;
}
.auxiliary-list > li
{
display: inline-block;
}
.aux-item
{
width: 19%;
margin: 2rem 5.6% 2rem 0;
padding: 3.1rem 0;
}
.footer {
width: 97%;
padding: 3rem 0 0 3%;
}
@media screen and (max-width: 55em) {
html { font-size:80%;}
}
@media screen and (min-width: 65em) {
html { font-size:115% }
}
@media screen and (min-width: 75em) {
html { font-size:135%; }
}
Для краткости в нашем примере мы имеем дело только с компоновкой. Вы можете просмотреть полные стили на CodePen (откроется в новой вкладке).
Все это кажется довольно простым, но с процентами, управляющими двумя аспектами нашего макета, это может немного сбивать с толку. Итак, чтобы было ясно, проценты, которые составляют общую ширину документа, не зависят напрямую от нашего корневого масштабирования. Сохраняя это разделение, мы можем создать сайт, который будет одновременно гибким и пропорционально масштабируемым.
В дикой природе
Хотя эти короткие примеры показывают основную предпосылку того, чего мы хотим достичь, его практическое применение часто будет зависеть от преобразования макета дизайна в стилизованный HTML. Для этого нам понадобится метод выражения размеров пикселей в бэрах.
К счастью для нас, это уже существует. Это формула, с которой вы уже должны быть знакомы. Это то же самое, что мы используем для поиска пропорциональных процентов в адаптивном рабочем процессе, а именно:
target ÷ context = result
Поскольку длина rems зависит от шрифта, наш контекст привязывается к корневому размеру шрифта. Предполагая размер шрифта HTML 100% приравнивается к 16 пикселейто пример измерения 58 пикселей будет 58 разделить на 16 равно 3,625 бэр. Это также верно для преобразования размеров шрифта на основе px в единицы rem. Вполне реально вычислить наши значения rem от руки. Но это само по себе создает накладные расходы, барьер для эффективной работы. Использование препроцессора CSS, такого как Sass, может избавить нас от тяжелой работы. Имея простой миксин, мы можем определить все наши измерения в пикселях, что упростит усвоение нашего CSS.
$em-root: 16px !default;
@function rem($target, $context: $em-root)
{
@return ($target / $context) * 1rem;
}
Скрытые преимущества
Часто упускаемая из виду функция масштабирования в браузере позволяет пользователям управлять масштабированием сайта. Он является важной частью набора специальных инструментов для людей с нарушениями зрения. Непроверенный, он может привести к неожиданному поведению макетов, что может повлиять на навигацию по сайту. С нашими шаблонами масштабирования мы обнаруживаем, что воспроизводим это естественное поведение, и тестирование на него становится неотъемлемой частью нашего рабочего процесса.
Масштабирование также помогает нам представить более единообразный опыт на большем количестве экранов. Эта согласованность может помочь повысить эффективность рабочего процесса при работе с более крупной командой. Многие разговоры о том, как контент должен перекомпоновываться, и связанные с этим сложности могут быть сокращены. Тестирование и контроль качества становятся проще, так как ожидания одинаковы на большом экране. Это может позволить нам инвестировать больше времени в создание взаимодействия и нашего опыта в целом.
Зайти слишком далеко
Масштабирование вашего контента имеет свои ограничения. Не используйте его в ущерб вашему маленькому экрану. Пропорциональный RWD может прекрасно работать с мобильным подходом. Мы можем улучшить работу с маленькими экранами, введя основную точку останова, определяющую макеты для малого и большого экрана, каждый из которых управляется независимым шаблоном масштабирования.
Вывод
Простое исполнение, сочетающее гибкую ширину с пропорциональным масштабированием, может дать ряд преимуществ. Он достигает наших целей в области отзывчивости, представляя нашей аудитории согласованные, предсказуемые макеты и уменьшая потребность в повторном размещении нашего контента. Повторяя нативную функцию масштабирования браузера, мы по своей сути тестируем наши проекты на недооцененную функцию доступности.
В более крупных проектах масштабирование макетов снижает потребность в избыточном CSS и обеспечивает более эффективный командный рабочий процесс, сокращая время проектирования и сборки.
Слова: Дэн Нисбет
Эта статья первоначально появилась в сетевом журнале (откроется в новой вкладке) выпуск 253.
[ad_2]