Less.js: Групповые медиа-запросы

Как это сделать, не изменяя смысла путем реорганизации утверждений?

Я не думаю, что смысл можно изменить. Это будет то же самое, что свернуть обычные избыточные теги. Например:

body {
    background: white;
}

body {
    padding: 0;
    margin: 0;
}

Будет свернуто в:

body {
    background: white;
    padding: 0;
    margin: 0;
}

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

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

Каковы правила сложности селектора внутри медиа-запросов? Сделайте
запросы увеличивают сложность и отменяют любой порядок? Вы можете указать на любой
спецификации?

По сути, да. Селекторы мультимедиа похожи на операторы IF, которые охватывают обычные правила стиля и применяются только в том случае, если выполняется условие запроса. Например, если ширина браузера меньше определенного количества пикселей, тогда правила в запросе включаются и переопределяют существующие правила.

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

Вот некоторая документация от Mozilla

https://developer.mozilla.org/en-US/docs/CSS/Media_queries

то, что я имею в виду, находится в этом примере ... div становится красным - это означает, что переупорядочение медиа-запросов (как для экрана) изменит значение css

<strong i="6">@media</strong> screen {
    div {
        background-color: green;
    }
}

div {
     background-color: red;
}

<strong i="7">@media</strong> screen {
    div.pink {
        background-color: pink;
    }
}

Его следует комбинировать только в том случае, если наборы правил следуют друг за другом напрямую.

чего они нет в исходном примере @Soviut , что делает этот запрос функции ограниченным использованием в IMO

Я согласен, но не понимаю, как это применимо к всплывающим медиа-запросам? Помните, что пузырьковые запросы - это немного синтаксический сахар; Обычно вы не можете встроить медиа-запрос в другой селектор. Таким образом, можно смело предположить, что каждый раз, когда вы сталкиваетесь с восходящим запросом, нужно сгруппировать его с идентичными восходящими запросами в порядке их поступления.

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

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

Например, вот наш миксин спрайтов:

.sprite(<strong i="7">@spritePath</strong>, <strong i="8">@hdpiPath</strong>, <strong i="9">@x</strong>, <strong i="10">@y</strong>, <strong i="11">@size</strong>: auto) {
    background-image: url(@spritePath);  
    background-repeat: no-repeat;
    background-position: -1 * <strong i="12">@x</strong> -1 * @y; // Negativize the value
    .background-size(@size);
    <strong i="13">@media</strong> <strong i="14">@mediaRetina</strong> {
        background-image: url(@hdpiPath);
    }
}

Где @mediaRetina - это:

<strong i="19">@mediaRetina</strong>: ~"only screen and (-webkit-min-device-pixel-ratio: 1.3), only screen and (min--moz-device-pixel-ratio: 1.3), only screen and (-o-min-device-pixel-ratio: 4/3), only screen and (min-device-pixel-ratio: 1.3), only screen and (min-resolution: 124dpi), only screen and (min-resolution: 1.3dppx)";

Затем, ниже, мы создаем дополнительные миксины, чтобы обернуть каждый элемент спрайта следующим образом:

#sprite
{
    .header-logo()
    {
        .sprite(<strong i="23">@globalSpritePath</strong>, <strong i="24">@global2XSpritePath</strong>, 22px, 0, 384px 288px);
        width: 94px;
        height: 59px;
    }
}

И используйте его в других файлах LESS, например:

h1 {
    width: 94px;
    height: 59px;

    a {
        #sprite > .header-logo();
    }

}

В этом случае сгенерированный CSS выглядит так:

h1 a {
  background-image: url("/images/sprite-global.png");
  background-repeat: no-repeat;
  background-position: -22px 0;
  -webkit-background-size: 384px 288px;
  -moz-background-size: 384px 288px;
  -o-background-size: 384px 288px;
  background-size: 384px 288px;
  width: 94px;
  height: 59px;
}
<strong i="31">@media</strong> only screen and (-webkit-min-device-pixel-ratio: 1.3), 
       only screen and (min--moz-device-pixel-ratio: 1.3), 
       only screen and (-o-min-device-pixel-ratio: 4/3), 
       only screen and (min-device-pixel-ratio: 1.3), 
       only screen and (min-resolution: 124dpi), 
       only screen and (min-resolution: 1.3dppx) {
  h1 a {
    background-image: url("/images/[email protected]");
  }
}

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

Здесь имеет смысл сгруппировать их и держать отдельно, особенно если у вас большой сайт с множеством модулей (например, наш).

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

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

Итак, я хотел бы иметь возможность сделать это в файле LESS по существу:

<strong i="39">@media</strong> { // retina query
    @renderSection("retina")
}

// in another file
h1 {
    <strong i="40">@section</strong> retina {
        // retina styles
    }
}

@section будет заменен при компиляции текущим селектором.

Итак, мой миксин спрайтов стал бы просто:

.sprite(<strong i="46">@spritePath</strong>, <strong i="47">@hdpiPath</strong>, <strong i="48">@x</strong>, <strong i="49">@y</strong>, <strong i="50">@size</strong>: auto) {
    background-image: url(@spritePath);  
    background-repeat: no-repeat;
    background-position: -1 * <strong i="51">@x</strong> -1 * @y; // Negativize the value
    .background-size(@size);
    <strong i="52">@section</strong> retina {
        background-image: url(@hdpiPath);
    }
}

Это не обязательно должен быть этот синтаксис (или реализация), я основываю его на синтаксисе ASP.NET Razor, поскольку это то, с чем я знаком, и мне нравится синтаксис.

Это хороший пример ... и хороший вариант использования ... Вы могли бы сделать

@media-section

(или медиа-группа), которая затем будет меньше рассказывать о группировке медиа вместе (необязательно, объединяя его в медиа-запрос, если он уже существует, что позволит вам вытащить правила туда, где вы хотите их разместить) .. может быть, это так что ты имеешь в виду?

Я склонен думать, что это хорошая идея (и ее не так уж сложно реализовать)

+1 для @ media-group

+1 @ media-group

Другой вариант - иметь глобальную опцию для группировки true / false.

Хм, наверное, неплохая идея. Будет ли необходимость в выборочной группировке?

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

+1 для опции глобальной группировки.

да ... потому что мы видели с @import что добавление нескольких ключевых слов было не лучшим вариантом, а добавление опции менее спорно.

Я бы сказал, добавьте этот параметр, поскольку он будет полезен немедленно и сможет сосуществовать в качестве переопределения с выборочным импортом, если он когда-либо будет создан.

Здравствуйте, я только что увидел эту проблему и хотел поделиться небольшим приложением, которое я сделал, когда мне нужно было сгруппировать медиа-запросы. Это не законченное приложение. Больше похоже на исследование для будущего инструмента. Итак, я просто хочу показать вам идею, потому что я действительно считаю, что это то, что нужно реализовать. (могут быть ошибки и другие проблемы), но я тестировал свой последний проект, который включает загрузку twitter, и он работает правильно. (нет проблем с порядком правил) дайте мне знать;)

http://mqhelper.nokturnalapp.com

Привет!

Кто-то назначен на это? Это отличная функция, которая может быть очень полезна для уменьшения размера файла css при создании с меньшими затратами. И так разработчикам будет проще работать со всеми этими @mqs.

@AoDev mqhelper - определенно шаг в правильном направлении, на данный момент я вижу, что он полезен как часть процесса линтинга CSS. Я думаю, что ему просто нужна основная функциональность, извлекаемая из внешнего интерфейса в вашей демонстрации.

Да, но цель моего приложения - не быть частью какого-то «настоящего инструмента». Я только что увидел здесь множество людей, которые задавались вопросом, может ли группировка медиа-запросов быть проблемой, и хотел показать, что это можно сделать. Код предназначен для разработчиков less, если они хотят иметь идею и использовать ее части. Но я могу сделать его "настоящим" модулем, если хотите :)

У меня это уже получилось, это отличная работа, спасибо.

@Soviut @lukeapage Я думаю, что выборочная группировка имеет наибольший смысл. Все или ничего разрушает попытки поддерживать каскад. Должно быть что-то похожее на расширение или, может быть, буквально добавление ключевого слова группы. Как будто этот синтаксис был бы отличным:

<strong i="8">@tablet</strong>: (max-width: 979px);

.a {
  color: yellow;
  <strong i="9">@media</strong> <strong i="10">@tablet</strong> group {
    color: red;
  }
}
.b {
  background: black;
  <strong i="11">@media</strong> <strong i="12">@tablet</strong> group {
    background: white;
  }
}

//output
.a { color: yellow; }
.b { background: black; }
<strong i="13">@media</strong> (max-width: 979px) {
  .a { color: red; }
  .b { background: white; }
}

Здравствуйте, группировка медиа-запросов была бы действительно приятным дополнением. А пока я придумал эту идею, мне интересно, можно ли ее использовать с предстоящей функцией :extend чтобы избежать дублирования свойств:

// Define the media queries
<strong i="7">@step1</strong>: ~"only screen and (max-width: 960px)";
<strong i="8">@step2</strong>: ~"only screen and (min-width: 961px)";

// Default empty mixins
.step1() {}
.step2() {}

// Custom styles
.test { color: blue; }

// Change the style in the media queries
.step1() {
  .test { color: red; }
}

.step2() {
  .test { color: green; }
}

// Finally render the media queries
<strong i="9">@media</strong> <strong i="10">@step1</strong> { .step1(); }
<strong i="11">@media</strong> <strong i="12">@step2</strong> { .step2(); }

Инструмент, созданный @AoDev, отлично подходит для демонстрации того, что подход «все или ничего» на самом деле не имеет значения. Группировка медиа-запросов не страдает теми же побочными эффектами, что и стили группировки / переупорядочения. Может ли кто-нибудь предоставить реальный пример (протестированный с помощью инструмента, созданного @AoDev ), который показывает, как ошибочен метод «все или ничего»?

@kamranayub прекрасно объяснил точную ситуацию, с которой я имею дело. Лично мне хотелось бы увидеть какую-нибудь такую ​​реализацию. @DesignByOnyx , приведенный ниже тестовый код некорректно компилируется с помощью инструмента

.footer ul {

  margin: 10px;

  <strong i="9">@media</strong> @layout-tablet, @layout-full {
    font-size: 13px;
    font-weight: bold;
  }
  <strong i="10">@media</strong> @layout-mobile {
    font-size: 10px;
    padding-left: 10px;
  }

  li {

    background: black;
    color: white;
    padding: 10px;

    <strong i="11">@media</strong> @layout-tablet, @layout-full { .border-radius(@radius) }
    <strong i="12">@media</strong> @layout-mobile { .border-radius(@radius-mobile) }   
  }

}

Это не работает, потому что вы использовали меньше синтаксиса. Он предназначен для работы
с помощью CSS.
2 июля 2013 г. в 21:19 "P Macom" [email protected] написал:

@kamranayub https://github.com/kamranayub прекрасно объяснил точный
ситуация, с которой я имею дело. Лично мне хотелось бы увидеть какую-нибудь форму
этой реализации. @DesignByOnyx https://github.com/DesignByOnyx ,
приведенный ниже тестовый код не компилируется должным образом с @A oDevhttps: //github.com/AoDev
орудие труда. Я бы предпочел сделать такую ​​стилизацию, как упомянул камранаюб.
Это намного проще при работе с несколькими меньшими файлами на больших сайтах.

.footer ul {

маржа: 10 пикселей;

@media @ layout-tablet, @ layout-full {
размер шрифта: 13 пикселей;
font-weight: жирный;
}
@media @ layout-mobile {
размер шрифта: 10 пикселей;
отступ слева: 10 пикселей;
}

li {

background: black;
color: white;
padding: 10px;

<strong i="34">@media</strong> @layout-tablet, @layout-full { .border-radius(@radius) }
<strong i="35">@media</strong> @layout-mobile { .border-radius(@radius-mobile) }

}
}

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/less/less.js/issues/950#issuecomment -20369038
.

Предлагается ли запустить логику, используемую инструментом

Предлагается ли запустить логику, используемую инструментом

Я думаю , что это вариант для промежуточного, я хотел бы рассмотреть оберточной @AoDev «s решение в grunt.js модуль , так что он может быть автоматически запускается после того , как МЕНЬШЕ обрабатываются (это основано на предположении , что предварительная обработка в настоящее время выполняется до развертывания, а не на лету)

Неприятная задача, безусловно, была бы хороша тем временем и универсально полезна для необработанного CSS. Однако, учитывая, как много @media magic LESS уже делает, вариант группировки кажется логичным.

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

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

Может быть, здесь есть возможность для отдельного инструмента оптимизатора медиа-запросов для группировки и, при необходимости, разделения медиа-запросов?

Абсолютно. Я не уверен, что CSSO уже делает это, поскольку я единственный известный мне переписчик CSS, у которого также есть связанная с ним задача Grunt. Но даже он не может разбивать такие вещи, как медиа-запросы, на отдельные файлы. Точно так же его переписывание очень простое, основанное на идентичных селекторах и атрибутах, в отличие от структуры DOM.

Mqhelper уже возвращает вам отдельные медиа-запросы проверьте github
страницу для более подробной информации. отдельные файлы css могут быть построены оттуда.
5 июля 2013 г. в 10:08 "Soviut" [email protected] написал:

Абсолютно. Я не уверен, что CSSO уже делает это, будучи единственным CSS
rewriter, о котором я знаю, также имеет связанную с ним задачу Grunt. Но даже
он не может разбивать такие вещи, как медиа-запросы, на отдельные файлы. Сходным образом,
его переписывание очень простое, основано на идентичных селекторах и атрибутах,
в отличие от структуры DOM.

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/less/less.js/issues/950#issuecomment -20505834
.

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

Я не хочу препятствовать переходу к какой-то «секционной» или «групповой» идее для реализации этого (я думаю, что это хорошо). Однако, если кто-то желает иметь возможность определять информацию о свойстве @media в коде, где она определена для обычного CSS, но сгруппировать ее в один запрос @media другом месте кода, там являются по крайней мере двумя способами, которые в настоящее время могут быть выполнены с функциональностью МЕНЬШЕ, что дает хороший контроль над размещением, но, по общему признанию, с некоторым дополнительным кодированием сверх того, что потребует предлагаемое решение (так что, во что бы то ни стало, продолжайте работать над этим). Рассмотреть возможность:

<strong i="8">@media</strong> screen {
  .my-class > .mediaScreen();
  #screenSpace1(screen);
  #screenSpace2(screen);
}

//technique #1 only works for a top level class or id that can act as a namespace
//and would not handle a deep nesting very well
.my-class {
  regular-property: value;

  .mediaScreen(<strong i="9">@selectorString</strong>: ~'.my-class') { //full path needs repeat here if deeply nested
    @{selectorString} {
      media-screen-property: value;
    }
  }
}

//technique #2 allows for tag selectors and easier deeper nesting 
#screenSpace1(<strong i="10">@place</strong>: noMedia) {
  div > ul {
    .setProps() when (<strong i="11">@place</strong> = noMedia) {
       regular-property: value;
    }
    .setProps() when (<strong i="12">@place</strong> = screen) {
       screen-property: value;
    }
    .setProps();

    li {
       .setProps() when (<strong i="13">@place</strong> = noMedia) {
          regular-property: value;
          &:hover { regular-property: value; }
       }
       .setProps() when (<strong i="14">@place</strong> = screen) {
          screen-property: value;
          &:hover { screen-property: value; }
        }
       .setProps();
    }
  }
}
#screenSpace1();

.more-classes-not-needing-media {property: value;}

#screenSpace2(<strong i="15">@place</strong>: noMedia) {
  .someClass {
    .setProps() when (<strong i="16">@place</strong> = noMedia) {
       regular-property: value;
    }
    .setProps() when (<strong i="17">@place</strong> = screen) {
       screen-property: value;
    }
    .setProps();

    > a {
       .setProps() when (<strong i="18">@place</strong> = noMedia) {
          regular-property: value;
          &:hover { regular-property: value; }
       }
       .setProps() when (<strong i="19">@place</strong> = screen) {
          screen-property: value;
          &:hover { screen-property: value; }
        }
       .setProps();
    }
  }
}
#screenSpace2();

Что производит этот css:

<strong i="23">@media</strong> screen {
  .my-class {
    media-screen-property: value;
  }
  div > ul {
    screen-property: value;
  }
  div > ul li {
    screen-property: value;
  }
  div > ul li:hover {
    screen-property: value;
  }
  .someClass {
    screen-property: value;
  }
  .someClass > a {
    screen-property: value;
  }
  .someClass > a:hover {
    screen-property: value;
  }
}
.my-class {
  regular-property: value;
}
div > ul {
  regular-property: value;
}
div > ul li {
  regular-property: value;
}
div > ul li:hover {
  regular-property: value;
}
.more-classes-not-needing-media {
  property: value;
}
.someClass {
  regular-property: value;
}
.someClass > a {
  regular-property: value;
}
.someClass > a:hover {
  regular-property: value;
}

Я давно хотел сделать что-то вроде:

/*
 * Span mixins
 * adapted from Gridpak Beta LESS
 * http://gridpak.com/
 * Created by <strong i="6">@erskinedesign</strong>
 */

.mixin-span(<strong i="7">@num</strong>, <strong i="8">@gutter_pc</strong>, <strong i="9">@padding</strong>, @max_columns) when (<strong i="10">@num</strong> > @max_columns) {
    .mixin-span(<strong i="11">@max_columns</strong>, <strong i="12">@gutter_pc</strong>, <strong i="13">@padding</strong>, @max_columns);
}
.mixin-span(<strong i="14">@num</strong>, <strong i="15">@gutter_pc</strong>, <strong i="16">@padding</strong>, @max_columns) when (<strong i="17">@num</strong> =< @max_columns) {
    <strong i="18">@one_col</strong>: (100% - (<strong i="19">@gutter_pc</strong> * (<strong i="20">@max_columns</strong> - 1))) / @max_columns;
    width:(<strong i="21">@one_col</strong> * @num) + (<strong i="22">@gutter_pc</strong> * (<strong i="23">@num</strong> - 1));
    padding:@padding;
    margin-left:@gutter_pc;
}
.mixin-span_first() {
    margin-left:0;
}

// end of adapted Gridpak LESS

// Namespaced mixin sets

#mob{
    <strong i="24">@max_columns</strong>: 1;
    <strong i="25">@padding</strong>: 0 1.5%;
    <strong i="26">@gutter_pc</strong>: 5%;

    .span(@col){
        <strong i="27">@media</strong> screen and (max-width:300px){
            .mixin-span(<strong i="28">@col</strong>, <strong i="29">@gutter_pc</strong>, <strong i="30">@padding</strong>, @max_columns);
            .mixin-span_first;
        }
    }
}

#desk{
    <strong i="31">@max_columns</strong>: 10;
    <strong i="32">@padding</strong>: 0 3%;
    <strong i="33">@gutter_pc</strong>: 5%;

    .span(@col){
        <strong i="34">@media</strong> screen and (min-width:301px){
            .mixin-span(<strong i="35">@col</strong>, <strong i="36">@gutter_pc</strong>, <strong i="37">@padding</strong>, @max_columns);
        }
    }
}

//assign different layouts per namespaced breakpoint
/* ----- Header ----- */
#header{
    #mob > .span(2);
    #desk > .span(4);
    .mixin-span_first;
    background-color:#888;
    color:#fff;
}

/* ----- Main ----- */
#main{
    #mob > .span(1);
    #desk > .span(6);
    background-color:#eee;
    color:#111;
}

но без группировки сгенерированный css немного громоздкий

/* ----- Header ----- */
#header {
  margin-left: 0;
  background-color: #888;
  color: #fff;
}
<strong i="41">@media</strong> screen and (max-width: 300px) {
  #header {
    width: 100%;
    padding: 0 1.5%;
    margin-left: 5%;
    margin-left: 0;
  }
}
<strong i="42">@media</strong> screen and (min-width: 301px) {
  #header {
    width: 37%;
    padding: 0 3%;
    margin-left: 5%;
  }
}
/* ----- Main ----- */
#main {
  background-color: #eee;
  color: #111;
}
<strong i="43">@media</strong> screen and (max-width: 300px) {
  #main {
    width: 100%;
    padding: 0 1.5%;
    margin-left: 5%;
    margin-left: 0;
  }
}
<strong i="44">@media</strong> screen and (min-width: 301px) {
  #main {
    width: 58%;
    padding: 0 3%;
    margin-left: 5%;
  }
}

Для этого https://github.com/buildingblocks/grunt-combine-media-queries есть решение, однако на данный момент оно заказывается только по минимальной ширине, поэтому в основном полезно для мобильных сайтов.

IMO имеет смысл обобщить проблему для управления группировкой области, которая предоставит решение для проблемы # 930

https://github.com/Se7enSky/group-css-media-queries

Отличный инструмент @krava ! Благодарность

Отлично !!! IMO имеет смысл реализовать функцию KRAVA на LESS

+1

Я хочу сделать это как плагин. не должно быть слишком сложно. слишком много нужно сделать!

Я думаю, что плагины должны иметь более низкий приоритет, чем система автоматической загрузки плагинов (options.json). Но да, плагин имеет смысл как дополнительная функция.

Реализована ли эта опция?
Это, вероятно, сократит мои выводимые css вдвое, поскольку я использую медиа-запросы внутри компонентов и буду счастлив, если бы они были сгруппированы на этапе вывода.

Что касается переупорядочения слежения, если вы используете ключевое слово «group» для группировки чего-либо, вы знаете, что оно будет удалено из текущего логического потока и помещено в сгруппированную область.

http://helloanselm.com/2014/web-performance-one-or-thousand-media-queries/
Согласно этой статье, нет необходимости группировать медиа-запросы.
Но плагин - это хорошо.

Это не столько проблема производительности, сколько размер результирующего файла CSS. Десятки строк <strong i="5">@media</strong> screen and (max-width: 480px) начинают складываться с точки зрения размера файла CSS.

Я задал этот вопрос о SO, и кто-то дал частичный ответ на этот вопрос.

@ seven-phase-max дал вам ответ и вернулся к этой проблеме в своем ответе. Очень мета;)

Я определенно предпочитаю метод mixin для объединения медиа-запросов, а не для их постобработки. Это позволяет упростить набор текста и лучше контролировать, что и как объединяется.

Здесь в комментариях вы можете увидеть решение, которое я использую во всех своих проектах:
https://github.com/less/less.js/issues/950#issuecomment -17723748

Я только что провел поиск и нашел два плагина grunt, которые группируют медиа-запросы:

https://github.com/buildingblocks/grunt-combine-media-queries

https://github.com/Se7enSky/grunt-group-css-media-queries

Комбинирование медиа-запросов также доступно для gulp .
http://github.com/konitter/gulp-combine-media-queries

Начиная с версии 2, вы можете использовать плагины, поэтому см. Https://github.com/bassjobsen/less-plugin-group-css-media-queries (и https://github.com/bassjobsen/less-plugin-pleeease)

Закрытие, поскольку это поддерживается плагином и не является приоритетом для перехода в ядро ​​(AFAIK - @ less / admin правильно, если это неправильно).

@gyopiazza У меня вопрос о https://github.com/less/less.js/issues/950#issuecomment -17723748 выше: зачем вам инициализировать миксин? Я имею в виду, что CSS компилируется без файла init. Думаю, я пытаюсь понять передовой опыт и способы его использования.

@nfq Это не совсем инициализация, а просто пустое определение "по умолчанию". Это необходимо в том случае, если вы не предоставляете свои собственные миксины .step*() (т.е. предполагается, что эти вещи могут быть у вас в разных файлах, например, определения .step*() умолчанию и их рендеринг в некоторых общих код утилиты / библиотеки, а пользовательские определения .step*() находятся в коде вашей темы / проекта).

@nfq На самом деле это не обязательно.
Как упоминалось в @ seven-phase-max, полезно избегать ошибок, если вы не используете миксины в своем коде, поскольку медиа-запросы будут вызывать несуществующий миксин.

Кстати, преимущество этого метода в том, что объединение медиа-запросов замедляет время компиляции (немного).

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

@ seven-phase-max Спасибо, ваш ответ имеет смысл. Я использую меньше и много, но еще не понял, как лучше всего достичь определенных целей!

Обратите внимание, что clean-css также поддерживает слияние @media начиная с версии v3, как и less-plugin-clean-css

с main.less:

header {
    color: green;

    <strong i="9">@media</strong> only screen (max-width: 500px) { color: red; }
}

footer {
    color: green;

    <strong i="10">@media</strong> only screen (max-width: 500px) { color: red; }
}

lessc --clean-css="advanced" main.less выходы:
footer,header{color:green}<strong i="15">@media</strong> only screen (max-width:500px){footer,header{color:red}}

less-plugin-clean-css устанавливает --skip-advanced true по умолчанию, вы должны явно установить параметр advanced для слияния @media

@nfq При «смешанном подходе» медиа-запросы по-прежнему компилируются внизу (или в любом месте, где вы их объявляете).

@gyopiazza, спасибо, да. Доволен таким подходом !!

@bassjobsen Я обязательно использую это в более