Less.js: Consultas de mídia do grupo

Como você faz isso sem potencialmente alterar o significado por ter as declarações reorganizadas?

Não acho que os significados possam ser alterados. Isso seria exatamente o mesmo que recolher tags redundantes normais. Por exemplo:

body {
    background: white;
}

body {
    padding: 0;
    margin: 0;
}

Seria reduzido para:

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

Este é ainda mais o caso com consultas de mídia porque eles são seletores de nível superior especiais que atuam como uma camada de controle sobre os seletores de elemento normais. Basicamente, eles têm apenas um único significado e não são afetados pelo resto do css dentro do arquivo.

Além disso, o less já mantém a ordem das consultas de mídia em bolhas, ele apenas cria muitos seletores redundantes para a mesma consulta exata. Se eles pudessem ser armazenados em buffer e gravados em uma única consulta no final do processamento, a saída de css seria muito mais organizada e menor.

Quais são as regras em torno da complexidade do seletor nas consultas de mídia? Faça o
as consultas aumentam a complexidade e substituem qualquer pedido? Você pode apontar para qualquer
especificações?

Essencialmente, sim. Os seletores de mídia são como instruções IF que envolvem as regras de estilo normal e só se aplicam se a condição da consulta for atendida. Por exemplo, se a largura do navegador for menor que um certo número de pixels, as regras dentro da consulta são ativadas e substituem as regras existentes.

Portanto, ter muitas consultas idênticas com um único estilo, cada uma seria funcionalmente idêntica a uma consulta com todos os estilos dentro dela. Contanto que a consulta seja a mesma.

Aqui estão algumas documentações da Mozilla

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

o que quero dizer é neste exemplo ... o div fica vermelho - o que significa que reordenar as consultas de mídia (ambas para a tela) mudaria o significado do 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;
    }
}

Ele só deve combinar se os conjuntos de regras seguirem um ao outro diretamente.

o que eles não fazem no exemplo original do @Soviut , tornando esta solicitação de recurso de uso limitado na IMO

Eu concordo, mas não vejo como isso se aplicaria a consultas de mídia borbulhante. Lembre-se de que as consultas em bolhas são um pouco de açúcar sintático; Normalmente, você não pode incorporar uma consulta de mídia dentro de outro seletor. Portanto, pode-se presumir com segurança que sempre que você encontrar uma consulta bubbling para agrupá-la com consultas bubbling idênticas na ordem em que chegam.

Se você tiver duas consultas de mídia em bolha próximas uma da outra que podem ser combinadas, acho que seria muito óbvio fazer isso com menos ... você pode dar um exemplo real em que seria seguro combinar as consultas de mídia e isso faz sentido mantê-los separados no menor?

Ao lidar com imagens de retina, envolvemos a consulta de mídia complexa dentro de um mixin e criamos mixins de sprite, então temos isso em todo lugar ... aumenta o CSS de saída, mas é mais fácil de manter.

Por exemplo, aqui está nosso mixin de sprite:

.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);
    }
}

Onde @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)";

Em seguida, abaixo, criamos mais mixins para envolver cada elemento sprite assim:

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

E use-o em outro (s) arquivo (s) MENOS como este:

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

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

}

Nesse caso, o CSS gerado se parece com:

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]");
  }
}

Agora imagine este caso sendo repetido muitas vezes. Sem agrupamento, a única maneira de aliviar esse peso extra é mover cada estilo de retina para um arquivo LESS dedicado, que pode funcionar para sites pequenos, mas não é realista para sites grandes.

É aqui que faz sentido agrupá-los e mantê-los separados, especialmente se você tiver um grande site com muitos módulos (como o nosso).

Eu sei o que você quer dizer sobre a substituição de estilos, porém, e não tenho certeza se você poderia implementar com segurança esse recurso exato sem potencialmente mexer com a cascata que um designer pode desejar.

Para mim, isso soa mais como ser capaz de definir uma "seção" (um espaço reservado) e, em seguida, definir estilos a serem colocados nela, em qualquer ordem em que foram escritos. Isso é muito comum em modelos do lado do servidor, onde você tem uma seção de "scripts" ou "cabeça" e, em seguida, suas páginas podem injetar conteúdo nelas quando são carregadas.

Então, eu gostaria de poder fazer isso em um arquivo LESS essencialmente:

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

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

O @section seria substituído na compilação pelo seletor atual.

Então, meu mixin de sprite se tornaria:

.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);
    }
}

Não precisa ser esta sintaxe (ou implementação), estou baseando-a na sintaxe ASP.NET Razor, uma vez que estou familiarizado com isso e gosto da sintaxe.

É um bom exemplo ... e um bom caso de uso ... Você poderia fazer

@media-section

(ou grupo de mídia) que diria menos para agrupar a mídia (opcionalmente, mesclando-a na consulta de mídia se ela já existisse, o que permitiria que você puxasse as regras para onde você quisesse colocá-las) .. talvez isso seja o que você quer dizer?

Estou tentado a pensar que é uma boa ideia (e não muito difícil de implementar)

+1 para @ media-group

+1 @ media-group

A outra opção seria ter uma opção global para agrupar verdadeiro / falso.

Hmm, provavelmente é uma boa ideia. Haveria algum caso em que o agrupamento seletivo seria necessário?

Acho que, na maioria dos casos, as pessoas querem apenas que suas consultas de mídia sejam mais compactas, portanto, uma opção global por enquanto pode ser o caminho a percorrer. Se alguém alegar que precisa de um agrupamento seletivo, novas palavras-chave podem ser adicionadas posteriormente.

1 para uma opção de agrupamento global.

sim .. porque vimos com @import que adicionar várias palavras-chave não era o caminho a percorrer e adicionar uma opção é menos controverso.

Eu diria que adicionar a opção, pois seria útil imediatamente e poderia coexistir como uma substituição com uma importação seletiva, caso ela fosse criada.

Olá, acabei de ver esse problema e queria compartilhar um pequeno aplicativo que fiz quando precisei agrupar consultas de mídia. Este não é um aplicativo concluído. Mais como uma pesquisa para uma ferramenta futura. Então, eu só quero mostrar a vocês a ideia, porque eu realmente acho que é algo que deve ser implementado. (pode haver bugs e outros problemas), mas eu testei com meu último projeto que inclui bootstrap do Twitter e funciona corretamente. (nenhum problema com a ordem das regras) me avise;)

http://mqhelper.nokturnalapp.com

Olá!

Alguém foi designado para isso? É um ótimo recurso que pode ser muito útil para diminuir o arquivo css quando criado com menos. E desta forma, será mais fácil para os desenvolvedores trabalharem com todos esses @mqs.

@AoDev mqhelper é definitivamente um passo na direção certa, posso considerá-lo útil como parte de um processo de linting de CSS por enquanto. Acho que ele só precisa da extração da funcionalidade central do front-end da sua demonstração.

Sim, mas o objetivo do meu aplicativo não é fazer parte de uma "ferramenta real". Acabei de ver muitas pessoas aqui se perguntando se agrupar consultas de mídia poderia ser um problema e queria mostrar que isso pode ser feito. O código está lá para os desenvolvedores do less se eles quiserem ter uma ideia e usar partes dela. Mas posso torná-lo um módulo "real" se você quiser :)

Já consegui, é um trabalho bacana, obrigado.

@Soviut @lukeapage Acho que o agrupamento seletivo faz mais sentido. Tudo ou nada destrói a tentativa de manter a cascata. Deve ser algo semelhante a estender, ou talvez adicionar literalmente uma palavra-chave de grupo. Como se essa sintaxe fosse ótima:

<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; }
}

Olá, o agrupamento de consultas de mídia seria uma adição muito boa. Nesse ínterim, tive esta ideia, gostaria de saber se ela poderia ser usada com o próximo recurso :extend para evitar propriedades duplicadas:

// 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(); }

A ferramenta criada por @AoDev é ótima para mostrar como a abordagem "tudo ou nada" não deveria importar. O agrupamento de consultas de mídia não sofre os mesmos efeitos colaterais dos estilos de agrupamento / reordenação. Alguém pode fornecer um exemplo do mundo real (testado com a ferramenta criada por @AoDev ) que mostra como o método tudo ou nada é falho?

@kamranayub explicou perfeitamente a situação exata com a qual estou lidando. Pessoalmente, adoraria ver alguma forma dessa implementação. @DesignByOnyx , o código de teste abaixo não compila corretamente com a ferramenta de @AoDev . Eu preferiria fazer esse tipo de estilo como o kamranayub mencionado. É muito mais limpo ao lidar com vários arquivos menos em sites maiores.

.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) }   
  }

}

Não funciona porque você usou menos sintaxe. Destina-se a funcionar
com CSS.
Em 2 de julho de 2013, 21:19, "P Macom" [email protected] escreveu:

@kamranayub https://github.com/kamranayub explicou perfeitamente o
situação com a qual estou lidando. Pessoalmente, adoraria ver algum formulário
desta implementação. @DesignByOnyx https://github.com/DesignByOnyx ,
o código de teste abaixo não compila corretamente com @A oDevhttps: //github.com/AoDev 's
ferramenta. Eu preferiria fazer esse tipo de estilo como o kamranayub mencionado.
É muito mais limpo ao lidar com vários arquivos menos em sites maiores.

.footer ul {

margem: 10px;

@media @ layout-tablet, @ layout-full {
tamanho da fonte: 13px;
intensidade da fonte: Negrito;
}
@media @ layout-mobile {
tamanho da fonte: 10px;
padding-left: 10px;
}

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) }

}
}

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/less/less.js/issues/950#issuecomment -20369038
.

A proposta é rodar a lógica usada pela ferramenta de @AoDev após o LESS ser processado? Não consigo pensar em um caso em que isso não seja o que eu quero de cara.

A proposta é rodar a lógica usada pela ferramenta de @AoDev após o LESS ser processado? Não consigo pensar em um caso em que isso não seja o que eu quero de cara.

Eu acho que é uma opção para o interino, eu consideraria embrulho @AoDev 's solução em um grunt.js módulo para que ele pode ser executado automaticamente após o menor é processada (isto é baseado na suposição de que o pré-processamento está sendo feito antes da implantação, não em tempo real)

Uma tarefa árdua certamente seria boa nesse ínterim e útil universalmente para CSS bruto. No entanto, considerando o quanto @media magic LESS já está fazendo, uma opção de agrupamento parece lógica.

Então, novamente, a tarefa do Grunt pode ser capaz de separar totalmente as consultas de mídia em seus próprios arquivos, para aqueles que gostam de carregar folhas de estilo móveis em tempo real.

Agora que você mencionou, separar as folhas de estilo é uma opção útil - atualmente, você precisaria criar seus arquivos de origem especificamente para fazer isso.

Talvez haja espaço aqui para uma ferramenta separada otimizador de consulta de mídia para agrupar e, opcionalmente, dividir as consultas de mídia?

Absolutamente. Não tenho certeza se CSSO já faz isso, sendo o único reescritor CSS que conheço que também tem uma tarefa Grunt associada a ele. Mas nem mesmo ele pode dividir coisas como consultas de mídia em arquivos separados. Da mesma forma, sua reescrita é muito básica, com base em seletores e atributos idênticos, em oposição à estrutura DOM.

Mqhelper já retorna consultas de mídia individuais, verifique o github
página para mais detalhes. arquivos css separados podem ser construídos a partir daí.
Em 5 de julho de 2013 10:08, "Soviut" [email protected] escreveu:

Absolutamente. Não tenho certeza se o CSSO já faz isso, sendo o único CSS
Eu sei que o reescritor também tem uma tarefa Grunt associada a ele. Mas mesmo
ele não pode dividir coisas como consultas de mídia em arquivos separados. De forma similar,
sua reescrita é muito básica, baseada em seletores e atributos idênticos,
em oposição à estrutura DOM.

-
Responda diretamente a este e-mail ou visualize-o em Gi tHubhttps: //github.com/less/less.js/issues/950#issuecomment -20505834
.

Parece algo útil para menos longo prazo e não muito difícil
(uma opção de agrupamento e uma opção de arquivo separado) se um de vocês
gostaria de implementar eu posso te ajudar ...

Não quero desencorajar a mudança para algum tipo de ideia de "seção" ou "grupo" para implementar isso (acho que é bom). No entanto, se alguém deseja a capacidade de definir as informações da propriedade @media no código onde está definido para o css regular, mas agrupar em uma única consulta @media em outra parte do código, Há pelo menos duas maneiras que podem ser feitas atualmente com a funcionalidade LESS, dando um bom controle de posicionamento, mas reconhecidamente com alguma codificação extra acima do que a solução proposta exigiria (portanto, por todos os meios, continue trabalhando nisso). Considerar:

<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();

Que produz este 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;
}

Tenho vontade de fazer algo como:

/*
 * 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;
}

mas sem agrupamento, o css gerado é um pouco volumoso

/* ----- 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%;
  }
}

Existe uma solução para esta https://github.com/buildingblocks/grunt-combine-media-queries, no entanto, ela só ordena por largura mínima no momento, então é útil principalmente para primeiros sites móveis.

IMO, faz sentido generalizar o problema para o controle de agrupamento de escopo que fornecerá solução para o problema # 930

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

Ótima ferramenta @krava ! obrigado

Excelente !!! IMO faz todo o sentido implementar o recurso KRAVA no LESS

+1

Eu quero fazer isso como um plugin. não deve ser muito difícil. muito a fazer!

Acho que os plug-ins devem ter prioridade mais baixa do que ter um sistema para carregar plug-ins automaticamente (options.json). Mas sim, um plugin faz sentido como um recurso aditivo.

Esta opção já foi implementada?
Isso provavelmente reduziria meu css de saída pela metade, pois eu uso consultas de mídia dentro de componentes e ficaria feliz em tê-los agrupados no estágio de saída.

Com relação ao reordenamento do slector, se você usar uma palavra-chave "grupo" para agrupar algo, você está ciente de que será removido do fluxo lógico atual e colocado em uma área agrupada.

http://helloanselm.com/2014/web-performance-one-or-thousand-media-queries/
De acordo com este artigo, não é necessário agrupar as consultas de mídia.
Mas um plugin é bom.

Não é tanto uma questão de desempenho, mas sim o tamanho do arquivo CSS resultante. Dezenas de strings <strong i="5">@media</strong> screen and (max-width: 480px) começam a somar em termos de tamanho de arquivo CSS.

Eu fiz esta pergunta no SO e alguém deu uma resposta parcial a esta questão.

@ seven-phase-max deu a você a resposta e se referiu a esse problema em sua resposta. Muito meta;)

Eu definitivamente prefiro o método mixin para mesclar as consultas de mídia, em vez de pós-processá-las. Isso permite uma digitação mais fácil e mais controle sobre o que é mesclado e como.

Aqui nos comentários você pode ver a solução que utilizo em todos os meus projetos:
https://github.com/less/less.js/issues/950#issuecomment -17723748

Acabei de fazer uma pesquisa e encontrei dois plug-ins grunt que fazem agrupamento de consulta de mídia:

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

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

Combine media queries também está disponível para gulp .
http://github.com/konitter/gulp-combine-media-queries

Desde a v2, você pode usar plug-ins, então consulte https://github.com/bassjobsen/less-plugin-group-css-media-queries (e https://github.com/bassjobsen/less-plugin-pleeease)

Fechando uma vez que é suportado por um plugin e não é uma prioridade para mover para o núcleo (AFAIK - @ less / admin correto se estiver errado).

@gyopiazza Eu tenho uma pergunta sobre https://github.com/less/less.js/issues/950#issuecomment -17723748 acima: por que você precisa inicializar o mixin? Quer dizer, o CSS compila sem o init. Acho que estou tentando entender as melhores práticas e uso.

@nfq Esta não é bem uma inicialização, mas apenas uma definição vazia "padrão". É necessário no caso de você não fornecer seus mixins .step*() (ou seja, assume-se que você pode ter essas coisas em arquivos diferentes, por exemplo, definições "padrão" de .step*() e sua renderização em algum tipo genérico código de utilitário / biblioteca, enquanto as definições personalizadas de .step*() estão em seu código específico de tema / projeto).

@nfq Na verdade, não é necessário.
Como @ seven-phase-max mencionado, é útil para evitar erros caso você não use os mixins em seu código, já que as media-queries irão chamar o mixin inexistente.

Aliás, a vantagem dessa técnica é que a combinação de consultas de mídia retarda o tempo de compilação (um pouco).

@gyopiazza Obrigado pela resposta rápida. Não me importo com o tempo de compilação e, para projetos grandes, definitivamente prefiro agrupar todas as consultas de mídia na parte inferior da folha de estilo principal. Tentei alguns dos plug-ins, mas descobri que o seu caminho é o mais fácil e conveniente para o nosso caso de uso. Obrigado!!

@ seven-phase-max Obrigado, sua resposta faz sentido. Uso menos muito, mas ainda não entendi a melhor forma de conseguir certas coisas!

Observe que também o clean-css suporta mesclagem @media desde a v3, e o mesmo acontece com o less-plugin-clean-css

com 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 saídas:
footer,header{color:green}<strong i="15">@media</strong> only screen (max-width:500px){footer,header{color:red}}

less-plugin-clean-css define o --skip-advanced como verdadeiro por padrão, você deve definir explicitamente a opção advanced para @media mesclagem

@nfq Com a "abordagem mixin", as consultas de mídia ainda são compiladas na parte inferior (ou em qualquer lugar que você as declare).

@gyopiazza , obrigado, sim. Feliz com esta abordagem !!

@bassjobsen Com certeza vou usar isso em um projeto maior. Na verdade, ainda não comecei a usar os plug-ins do Less. Obrigado pelas dicas!