Медиа-запросы, какой из них лучше и почему?

Я писал Media Queries после всех моих обычных стилей CSS (настольные и портативные устройства). Но недавно, глядя на некоторые примеры и загрузочные CSS-файлы, я заметил, что медиа-запросы следуют непосредственно после написания css. Этот пример лучше проиллюстрирует мой вопрос,

.content {
    padding-top: 20px;
    padding-bottom: 40px; 
    font-size: 1rem;  
    }
.something{
   background: red;
   padding:20px;
   width:800px;
}
   // The Media Queries after I write all normal CSS
@media only screen and (max-width: 768px) {
    .content{
      padding:10p;
      //some style for mobile
    }
    .something{
       width:100%;
   //some style for mobile
    }
}

Or

.content {
        padding-top: 20px;
        padding-bottom: 40px; 
        font-size: 1rem;  
        }
// Media Query Directly After the CSS
@media only screen and (max-width: 768px) {
        .content{
          padding:10p;
          //some style for mobile
        }
}
.something{
       background: red;
       padding:20px;
       width:800px;
    }
       // Media Query Directly After the CSS
@media only screen and (max-width: 768px) {        
    .something{
           width:100%;
       //some style for mobile
        }
    }

Итак, мне любопытно, как правильно или лучше?

Я делаю первый способ, так как мне не нужно каждый раз повторять медиа-запросы «@media only screen and (max-width: ..px)».

Спасибо


html css responsive media-queries
person Kanchan Rai    schedule 09.05.2016    source источник

Ответы (4)


arrow_upward
2
arrow_downward

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

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

@custom-media --small-viewport (max-width: 30em);

@media (--small-viewport) {
  /* styles for small viewport */
}
person Community    schedule 09.05.2016
comment
Большое спасибо за ссылку на плагин! Я обязательно попробую! - person Kanchan Rai; 11.05.2016

arrow_upward
4
arrow_downward

Это действительно зависит от вас. Не существует «правильного» способа сделать это. Это зависит от того, как вы хотите организовать свои таблицы стилей. Если у вас есть много правил медиа-запросов для разных видовых экранов, возможно, имеет смысл сделать это так, как вы делали, потому что вы правы — более эффективно иметь разделы для разных медиа-запросов. Примеры, которые вы рассмотрели, могут делать это по-другому, чтобы сделать их более понятными для других людей, читающих их. Я думаю, единственное, что важно, это попытаться выбрать путь и придерживаться его настолько, насколько это возможно. (В то же время правила предназначены для того, чтобы время от времени их нарушать.) В долгосрочной перспективе это поможет вашему коду быть более предсказуемым, и вам будет легче его понимать и поддерживать.

person Ringo    schedule 09.05.2016
comment
эффективнее иметь разделы для разных медиазапросов. Эффективнее в каком смысле? - person ; 09.05.2016
comment
@torazaburo Я просто имею в виду более короткую длину файла по причине, которую вы упомянули в своем ответе (повторение блоков медиа-запросов снова и снова). Я согласен, если бы вы могли использовать препроцессор, это сделало бы сохранение метода с несколькими окнами просмотра на правило более привлекательным. - person Ringo; 09.05.2016

arrow_upward
0
arrow_downward

Для приведенных примеров это в основном сводится к личным предпочтениям, у обоих примеров есть свои плюсы и минусы.

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

Второй пример, когда правила @media следуют за первоначальным объявлением, кажется, облегчают следование объявлениям, поскольку сразу видно, что для разных @media все будет по-разному. Хоть и не СУХОЙ.

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

Мои причины для этого просты:

  • это СУХОЕ по дизайну
  • если вы когда-нибудь почувствуете необходимость иметь медиа-запросы к <link>-элементам, вы можете легко извлечь их в отдельные файлы.
  • он никогда не останавливается только на одном правиле @media, их будет больше, и когда это произойдет, все аргументы читабельности/ясности в пользу второго подхода (немедленные переопределения) потеряют свою ценность, поскольку вы получите беспорядок.
person Rogier Spieker    schedule 09.05.2016
comment
Вы неверно истолковываете принцип DRY, превращая его во что-то вроде избегания дублирования ввода. Окончательное определение, AFAIK, на самом деле состоит в том, что часть знаний должна иметь единственное, недвусмысленное, авторитетное представление в системе. Ваше предложение на самом деле менее сухое, поскольку оно разбивает определение правила для .content на несколько файлов. Когда вы читаете о DRY, часто речь идет о препроцессорах или генераторах кода; например, процессор схемы, который выдает как SQL-запросы, так и программный код, чтобы вам не приходилось менять их самостоятельно. - person ; 11.05.2016
comment
(продолжение) В этом случае обработчику схемы соответствует некий механизм для предварительного определения или псевдонимов точек останова (определений медиа-запросов) в одном месте, а затем использования этих определений везде, где они необходимы. Это то, что делает медиа-плагин postCSS с его определением --small-viewport. Это, в свою очередь, позволяет вам писать действительно СУХОЙ код, где есть единственное представление правила для .content. - person ; 11.05.2016
comment
(продолжение) Если вас беспокоит загрузка правил, которые не имеют отношения к текущему размеру устройства пользователя, существуют другие механизмы на стороне сервера для фильтрации правил и загрузки только тех, которые относятся к текущему форм-фактору; это не нужно делать на уровне файлов. - person ; 11.05.2016

arrow_upward
0
arrow_downward

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

В этом случае вам просто нужно найти его только один раз.

person Codec    schedule 09.05.2016
comment
Все сводится к предпочтениям и используемым методологиям/архитектурам CSS. Это не так просто, как один способ лучше, чем другой. - person Michel Joanisse; 24.04.2019