Пользователь
0,0
рейтинг
20 октября 2013 в 20:15

Разработка → Советы по использованию media query

Вступление


В статье я собрал советы по использованию media query. Расскажу, как можно более эффективно использовать media query. В конце статьи есть список использованных источников.

  • Внешнее подключение media query
  • Больше чем просто размер viewport
  • Не только смартфоны
  • Инструмент для работы с media query
  • Выделяйте специфичное
  • Breakpoints когда и сколько?
  • Второстепенные breakpoints
  • Относительные единицы измерения
  • Условная загрузка
  • Список использованных ресурсов




Внешнее подключение media query


< link href="test.css" rel="stylesheet" media="only screen and (max-width:480px)" />

Браузеры, которые не поддерживают media query не будут загружать эти стили, но браузеры с поддержкой будут загружать все независимо от того необходимы они или нет.

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

< link href="css/test1.css" rel="stylesheet" media="only screen and (max-width:480px)" />
< link href="css/test2.css" rel="stylesheet" media="only screen and (min-width:480px)" />

test1.css

body {
  background: url("../img/bg1.png");
}

test2.css

body{
  background: url("../img/bg2.png");
}

В зависимости от размера экрана будет загружена одна фоновая картинка.

Больше чем просто размер viewport


Ширина viewport это не единственное что можно определить с помощью media query. Есть много других функций которые можно определить, в том числе: пропорции устройства, ориентацию, разрешение, плотность пикселей и более.

Многие из них очень полезны:

— pixel-density пригодится если вы хотите использовать фоновые картинки и иконки адаптированные для экранов с высокой плотностью пикселей.

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

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

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

Не только смартфоны


Вы замечали насколько некрасиво смотрятся некоторые сайты на современных больших мониторах? Первая ассоциация связанная с media query — это создание интерфейса только для смартфонов. Сочетание media query и multi column поможет отобразить ваш сайт красиво на больших мониторах.

Как часто вы используете такой breakpoint?

@media all and (min-width: 1300px) {
     /* ... */
}


Инструмент для работы с media query


Существует множество плагинов для браузеров которые помогают разрабатывать адаптивный дизайн, но по моему опыту лучшим инструментом является Responsive Mode который был добавлен с 15 версией Firefox.

Выделяйте специфичное


Отсутствие media query, на самом деле и есть media query. Этот совет часть стратегии mobile-first, согласно которой. Вместо:

/* Desktop-first */
.column {
    float: left;
    width: 30%;
}

@media all and (max-width: 40em) {
    .column {
        float: none;
        width: auto;
    }
}

Лучше определить только специфичные, правила только там, где это необходимо:

/* Mobile-first  */
@media all and (min-width: 40em) {
    .column {
        float: left;
        width: 30%;
    }
}

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

Breakpoints когда и сколько?


Так исторически сложилось, что – breakpoints были привязаны к размерам популярных устройств. (iPhone = 320px портрет, 480px = iPhone пейзаж, и т.д. ). Но что мы видим сейчас — размеры устройств постоянно меняются, появляется все больше устройств с нестандартными размерами. Какой он, стандарт? Веб постоянно развивается, так что это наша работа, создавать интерфейсы, которые выглядят и работают прекрасно на любом экране.

Так где же расставить breakpoints и сколько их необходимо?

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

Второстепенные breakpoints


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

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

Относительные единицы измерения


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

Условная загрузка


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

Для этого мы можем использовать matchMedia. matchMedia позволяет нашему javascript определить все свойства доступные через media query.

Выглядит это примерно так:

if (window.matchMedia("(min-width: 60em)").matches) {
    /* load something */
}

Альтернативная методика, тоже заслуживает изучения.

Список использованных ресурсов


@rafaelkyrdan
карма
11,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (24)

  • 0
    Как часто вы используете такой breakpoint?
    Почему вы это назвали точкой остановки?
    • 0
      Подразумеваю что в этой точке заканчивают «работать» текущие стили.
      • 0
        Действительно, лучше как то поменять, у меня ассоциация с совершенно другим функционалом, который с CSS(viewport) никак не вяжется.
        • 0
          Я видел, что их называли breakpoint-ами например в курсах на codeschool
          • 0
            Ну это не повод повторять же. Это скорее перекрытие (селекторов), в терминах наследования.
    • 0
      Автор не сам придумал это название :)

      В англоязычных блогах (откуда, собственно, к нам и попадает большинство информации по RWD и веб-разработке в целом) используется именно термин breakpoint. Хотя название не самое удачное, конечно.
    • 0
      В англоязычных ресурсах, используют разные вариации слова breakpoint(break point, breakpoints).
      В спецификации к media query, тема breakpoint не затронута. Там используется выражение, в свободном переводе
      «условие выполнения».
      • 0
        Устоявшийся перевод «Media Queries» — медиа-выражения. «Breakpoints» лучше всего по смысл перевести как «ключевые точки».
  • +1
    С выходом каждого нового девайса меня все большая паника охватывает: мало что в разных ОС стараются сделать стандартным разное разрешение, так и в девайсах одного вендора порой наблюдается разброд и шатание, что считать нормально шириной для одного и того же количества дюймов диагонали. Про китайские поделия (и поделия не из мейнстрима в принципе) говорить не приходится, экраны ставят какие могут, порой даже ОС устройства, кажется, с удивлением узнает, с каким разрешением ей предстоит работать…

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

    Так что media query — штука хорошая (где же оно было лет 10 назад?!), но вот если бы еще и вендоры договорились по поводу разрешения своих девайсов…
    • 0
      10 лет назад оно было там же. Просто не так развито.
    • +1
      Верстайте от контента, а не от девайсов. И em-ами, а не пикселями. Не будет никогда ни стандартных разрешений, ни стандартных пикселей. Да и не нужны они.
      • 0
        Почему em, а не rem and %? em хорошо для лайн хайта и марджинов в тестовых блоках. Ну и для паддинга в кнопочках, баннерах. А вот для остального мне кажется перебор.
        • 0
          Да, можете использовать не только em, но и другие относительные единицы.
        • 0
          rem я рассматриваю как логичное продолжение em (он правда в сафари в медиа запросах не работает, но это так, фигня). Главное — не px. А проценты — их всегда юзать надо было.
          • 0
            Вы про эту проблему говорите? В сафари на каких девайсах? На stackoverflow говорилось что не работает на Маках, но я проверял в browserstack, все было ок.

            ___update___
            Или это все таки про использование rem вот так: media(min-width 75 rem)?
            • 0
              Да, второе. Притом замена rem на em в этом случае совершенно не меняет результат в «неглючных» браузерах — единицы в обоих случаях рассчитываются от базового размера фонта. Мне просто это причинило неудобство, так как я везде использовал rem, а тут глюкануло и пришлось дебажить.

              Старые браузеры на мобильных устройствах тоже такой же глючок имеют, кстати.
  • –1
    Может я не прав и меня заминусуют, но по большей части стараюсь ориентироваться на размеры яблочной техники.
    • +1
      Мне кажется нужно отталкиваться от своей ЦА
  • 0
    Управляйте сетками лично. Это не так сложно. Это избавит от массы проблем.

    Для понимающих SCSS оставлю ссылку на кусок своего кода.
    pastebin.com/7xg7rnFa

    P.S. Сегодня знать и уметь препроцессоры верстальщик просто обязан.
    • 0
      Для понимающих scss и английский оставлю вот это github.com/Team-Sass/Singularity. Кстати спасибо тому хабраюзеру который меня на эту мега вещь натолкнул.
  • 0
    Увидев
    Условная загрузка

    почему-то подумал, что будет рассказ о том, что на самом деле возможно сделать что-то вроде

    @media all and (max-width: 960px) {
        @import url(/css/mobile.css);
    }
    


    А мысль, собственно, хорошая. Вы не знаете, работает ли это? И если да — позволяет ли это сэкономить трафик, реально ли это будет условная загрузка?
    • 0
      Преждевременная оптимизация — корень зла.

      В большинстве случаев вы не так много сэкономите, зато усложните себе работу.
      • 0
        У меня и так все на sass всегда, который сам все сжимает в один минифицированный файл, тут банальное любопытство :)
  • +1
    Относительные единицы измерения

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


    Это полная чушь.

     

    Во-первых, зум пиксельных значений прекрасно работает во всех браузерах, начиная как мимимум с IE8. Я специально запустил виртуалку с WinXP, чтобы проверить. Более древнего IE под рукой не оказалось, но это и не важно — доля IE7 составляет в России всего 0.5%, IE6 — 0.1%, и то, по большей части, за счет госучреждений.

    Шрифты, размер которых задан в пикселах, зумятся нормально. Нормально срабатывают и media queries, ширина для которых задана в пикселах. Вы крутите колесико мыши с зажатым Ctrl, и компоновка страницы перестраивается по мере увеличения масштаба.

    Проблема, названная автором в качестве главной причины отказа от пиксельных media queries, просто не существует. Это просто легенда, которая слепо передается из уст в уста, регулярно попадает даже в публикации влиятельных изданий и блоги гуру фронтенда, и никто не удосуживается просто взять и проверить, а так ли это.
     

    Во-вторых, если вы зададите media queries в em'ах, то значения breakpoint'ов будут зависеть от базового размера шрифта.

    А теперь представьте такую ситуацию. Вот звонит вам далекий от IT шеф или клиент и говорит: «А чего у нас на сайте шрифт такой мелкий? Сделайте покрупнее». Спорить бесполезно. Вы грустно вдыхаете, бросаете виноватый взгляд на дверь кабинета UI-отдела, а потом открываете CSS и увеличиваете базовый размер шрифта с 12px до 16px (да, базовый размер шрифта все равно задается в пикселах, как ни крути).

    Что при этом происходит? Все breakpoint'ы смещаются. Теперь на планшетах сайт отображается в одну колонку: так, как раньше выглядел только на телефоне. Выглядит это примерно так (сделайте ширину окна менее 900px). Вы этому рады? Готов спорить, что окажись вы в такой ситуации, вы будете судорожно переписывать свои media queries, и да поможет вам бох, если вы не использовали препроцессор.

    Content first — это прекрасная идеология. Но не врите себе. Вы хотите строго определенную компоновку на определенных устройствах. Например, чтобы на iPad в портретном режиме колонка thumbnail'ов превращался в сетку из трех колонок, а в ландшафтном, скажем, чтобы сбоку появлялся сайдбар с навигацией. И вы не хотите, чтобы всё это поломалось при изменении размера шрифта.

    Да, для контент-ориентированных сайтов ширина колонки текста не должна выходить за комфортные пределы. Но, во-первых, эта ширина имеет достаточно широкий диапазон. Мне известна рекомендация в 45—75 знаков, то есть ширина колонки может безболезненно меняться на величину вплоть до 66 процентных пунктов. Во-вторых, почему именно такая ширина считается стандартом? Откройте любой глянцевый журнал, там сплошь и рядом попадаются колонки текста шириной по 15 знаков, и никому не приходит в голову, что это плохо. Мне, например, очень удобно свернуть журнал трубочкой, когда я пытаюсь читать его в битком набитом вагоне метро.

     

    В-третьих, использование em'ов для задания ширины media queries приводит к тому, что смежные media queries, например (max-width: 40em) и (min-width: 40em) отображаются внахлест. Величина перекрытия составляет всего один пиксел, но она есть. Если у посетителя сайта вдруг окажется именно такая ширина экрана, то и компоновка страницы, и оформление могут оказаться покорежены, вплоть до полной нечитаемости.

     

    В-четвертых, min-width и max-width media queries всегда сравниваются с виртуальной шириной экрана, которая у любого браузера задана целым числом виртуальных пикселов, к примеру, для iPhone по четвертый включительно, она составляет 320×480, а для iPhone 5 — 320x533, если правильно помню. Задавая media queries в относительных величинах, вы сначала производите в уме преобразование из пикселов в em, а потом из em обратно в пикселы, чтобы понять, а в какую ширину экрана вы этим breakpoint'ом, собственно, попадаете.

    Так зачем мучиться? Облегчите себе жизнь и ставьте breakpoint'ы в пикселах.

     

    В общем, завязывайте, пожалуйста, с этой массовой истерией.

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

    PPS Если информация в этом комменте оказалась для вас полезной, плюсаните, пожалуйста, в карму. Мне ее слили за то, что я в посте про Nexus 5 я сравнил его с конкурентом, имеющим съемную батарею и слот для карты памяти. Теперь даже сабж плюсануть не могу. :(

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