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

Преимущества разработки с учётом мобильных устройств

Некоторые преимущества разработки с учётом мобильных устройств — и причины, по которым она так долго была де-факто методологией разработки, — имеют смысл:

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

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

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

Предотвращает разработку, ориентированную на настольные компьютеры.

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

Недостатки подхода «сначала мобильные устройства»

Установка объявлений стилей, а затем их перезапись при более высоких точках останова может привести к нежелательным последствиям:

Больший объём работы. Чем выше вы поднимаетесь по иерархии точек останова, тем больше ненужного кода вы наследуете от более низких точек останова.

Более высокая специфичность CSS. Стили, которые были возвращены к значению по умолчанию в браузере в объявлении имени класса, теперь имеют более высокий приоритет. Это может стать головной болью при работе с большими проектами, когда вы хотите, чтобы селекторы CSS были как можно более простыми.

Требуется больше регрессионного тестирования. Изменения в CSS на более низком уровне (например, добавление нового стиля) требуют регрессионного тестирования всех более высоких точек останова.

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

Проблема переопределения значений свойств

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

Учитывая это, в наши дни я разрабатываю CSS, уделяя больше внимания значениям по умолчанию. Поскольку нет определённого порядка и цепочек конкретных значений, за которыми нужно следить, это позволяет мне одновременно разрабатывать точки останова. Я концентрируюсь на поиске общих стилей и выделении конкретных исключений в закрытых диапазонах медиазапросов (то есть в любом диапазоне с заданной максимальной шириной).

Такой подход открывает некоторые возможности, поскольку вы можете рассматривать каждую точку останова как чистый лист. Если макет компонента выглядит так, как будто он должен быть основан на Flexbox во всех точках останова, то это нормально, и его можно закодировать в таблице стилей по умолчанию. Но если кажется, что Grid будет лучше для больших экранов, а Flexbox — для мобильных устройств, то и то, и другое можно сделать независимо друг от друга, если поместить CSS в закрытые диапазоны медиазапросов. Кроме того, одновременная разработка требует, чтобы вы заранее хорошо понимали любой компонент во всех точках останова. Это может помочь выявить проблемы в дизайне на более ранних этапах разработки. Мы не хотим увязнуть в разработке сложного компонента для мобильных устройств, а затем получить дизайн для настольных компьютеров и обнаружить, что он такой же сложный и несовместим с HTML, который мы создали для мобильного представления!

Хотя такой подход подойдёт не всем, я рекомендую вам попробовать. Существует множество инструментов для параллельной разработки, таких как Responsively App, Blisk и многие другие.

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

Закрытые диапазоны медиазапросов на практике

В классическом CSS, ориентированном на мобильные устройства, мы перезаписываем стили, но этого можно избежать, используя диапазоны медиазапросов. Чтобы проиллюстрировать разницу (для краткости я использую SCSS), предположим, что есть три визуальных дизайна:

• smaller than 768
• from 768 to below 1024
• 1024 and anything larger

Возьмём простой пример, где элемент уровня блока имеет отступ по умолчанию «20 пикселей», который на планшете заменяется на «40 пикселей», а на компьютере возвращается к «20 пикселям».

Классическая минимальная ширина для мобильных устройств

.my-block {
отступ: 20 пикселей;
@media (min-width: 768 пикселей) {
отступ: 40 пикселей;
}
@media (min-width: 1024px) {
padding: 20px;
}
}

Закрытый диапазон медиазапроса

.my-block {
padding: 20px;
@media (min-width: 768px) и (max-width: 1023,98px) {
padding: 40px;
}
}

Небольшое отличие заключается в том, что в примере, ориентированном на мобильные устройства, отступ по умолчанию равен «20 пикселей», а затем он перезаписывается при каждой точке останова, в общей сложности три раза. В отличие от этого, во втором примере отступ по умолчанию равен «20 пикселей», и он перезаписывается только при соответствующей точке останова, где он не является значением по умолчанию (в данном случае исключение составляет планшет).

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

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

Возьмём приведённый выше пример. Если мы обнаружим, что отступ .my-block на рабочем столе уже учтён в поле в этой точке останова, и поскольку мы хотим полностью убрать отступ, мы можем сделать это, задав отступ для мобильных устройств в закрытом диапазоне медиазапроса.

.my-block {
@media (max-width: 767,98px) {
padding: 20px;
}
@media (min-width: 768px) и (max-width: 1023,98px) {
padding: 40px;
}
}

Отступ по умолчанию для нашего блока в браузере равен «0», поэтому вместо того, чтобы добавлять медиазапрос для настольных компьютеров и использовать значение «unset» или «0» для отступа (что нам было бы нужно при ориентации на мобильные устройства), мы можем обернуть отступы для мобильных устройств в закрытый медиазапрос (поскольку теперь он также является исключением), чтобы он не учитывался при более широких точках останова. В точке останова для настольных компьютеров нам не нужно будет задавать какой-либо стиль отступов, так как нам нужно значение по умолчанию для браузера.

Объединение или разделение CSS

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

С появлением HTTP/2 и HTTP/3 количество запросов уже не так велико, как раньше. Это позволяет нам разделять CSS на несколько файлов с помощью медиазапроса. Преимущество этого в том, что теперь браузер может запрашивать CSS, который ему нужен в данный момент, с более высоким приоритетом, чем CSS, который ему не нужен. Это повышает производительность и может сократить общее время блокировки рендеринга страницы.

Какую версию HTTP вы используете?

Чтобы определить, какую версию HTTP вы используете, перейдите на свой сайт и откройте инструменты разработчика в браузере. Затем выберите вкладку «Сеть» и убедитесь, что столбец «Протокол» отображается. Если в разделе «Протокол» указано «h2», это означает, что используется HTTP/2.

Примечание: чтобы просмотреть протокол в инструментах разработчика вашего браузера, перейдите на вкладку «Сеть», перезагрузите страницу, щелкните правой кнопкой мыши по любому заголовку столбца (например, «Имя») и проверьте столбец «Протокол».