Less.js: Consultas de medios grupales

¿Cómo se hace eso sin alterar potencialmente el significado reorganizando las declaraciones?

No creo que se puedan alterar los significados. Esto sería exactamente lo mismo que contraer etiquetas redundantes normales. Por ejemplo:

body {
    background: white;
}

body {
    padding: 0;
    margin: 0;
}

Se colapsaría para:

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

Este es aún más el caso de las consultas de medios porque son selectores especiales de nivel superior que actúan como una capa de control sobre los selectores de elementos normales. Básicamente, solo tienen un significado único y no se ven afectados por el resto del CSS dentro del archivo.

Además, Less ya mantiene el orden de las consultas de medios burbujeadas, solo crea muchos selectores redundantes para la misma consulta exacta. Si pudieran almacenarse en búfer y escribirse en una sola consulta al final del procesamiento, sería mucho más ordenado y produciría una salida css más pequeña.

¿Cuáles son las reglas sobre la complejidad del selector dentro de las consultas de medios? Hacer el
las consultas aumentan la complejidad y anulan cualquier orden? ¿Puedes señalar a alguna
¿especificaciones?

Básicamente, sí. Los selectores de medios son como declaraciones IF que se ajustan a las reglas de estilo normales y solo se aplican si se cumple la condición de la consulta. Por ejemplo, si el ancho del navegador es menor que un cierto número de píxeles, las reglas dentro de la consulta se activan y anulan las reglas existentes.

Por lo tanto, tener muchas consultas idénticas con un solo estilo, cada una sería funcionalmente idéntica a una consulta con todos los estilos dentro. Siempre que la consulta sea la misma.

Aquí hay algo de documentación de Mozilla

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

lo que quiero decir es en este ejemplo ... el div se pone rojo, lo que significa que reordenar las consultas de medios (ambas para la pantalla) cambiaría el significado del 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;
    }
}

Solo debe combinarse si los conjuntos de reglas se suceden directamente.

lo que no hacen en el ejemplo original de @Soviut , lo que hace que esta solicitud de función sea de uso limitado en IMO

Estoy de acuerdo, pero no veo cómo se aplicaría esto a las consultas de medios con burbujas. Recuerde, las consultas con burbujas son un poco de azúcar sintáctico; Normalmente no puede incrustar una consulta de medios dentro de otro selector. Por lo tanto, se podría suponer con seguridad que cada vez que encuentre una consulta burbujeante, agrúpela con consultas burbujeantes idénticas en el orden en que llegan.

Si tiene dos consultas de medios con burbujas una al lado de la otra que se pueden combinar, creo que sería muy obvio hacerlo en menos ... ¿puede dar un ejemplo real en el que sería seguro combinar las consultas de medios y tiene sentido? para mantenerlos separados en menos?

Cuando se trata de imágenes de retina, hemos envuelto la consulta de medios compleja dentro de un mixin y hemos creado mixins de sprites, por lo que tenemos esto por todas partes ... aumenta el CSS de salida pero es más fácil de mantener.

Por ejemplo, aquí está nuestra mezcla de sprites:

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

Donde @mediaRetina es:

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

Luego, a continuación, creamos más mixins para envolver cada elemento de sprite de esta manera:

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

Y utilícelo en otros archivos MENOS como este:

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

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

}

En este caso, el CSS generado se ve así:

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

Ahora imagina que este caso se repita muchas veces. Sin agrupar, la única forma de aliviar este peso adicional es mover cada estilo de retina a un archivo LESS dedicado, que puede funcionar para sitios pequeños, pero no es realista para un sitio grande.

Aquí es donde tiene sentido agruparlos y mantenerlos separados, especialmente si tiene un sitio grande con muchos módulos (como el nuestro).

Sin embargo, sé a qué te refieres con la sustitución de estilos, y no estoy seguro de que puedas implementar de forma segura esta característica exacta sin interferir potencialmente con la cascada que un diseñador podría querer.

Para mí, esto suena más como poder definir una "sección" (un marcador de posición) y luego definir los estilos que se colocarán en ella, en el orden en que estén escritos. Esto es bastante común en las plantillas del lado del servidor, donde tiene una sección de "scripts" o "encabezado" y luego sus páginas pueden inyectar contenido en ellas cuando se cargan.

Entonces, me gustaría poder hacer esto en un archivo MENOS esencialmente:

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

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

El @section se reemplazaría en la compilación con el selector actual.

Entonces, mi mezcla de sprites simplemente se convertiría en:

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

No necesita ser esta sintaxis (o implementación), la baso en la sintaxis ASP.NET Razor ya que eso es lo que conozco y me gusta la sintaxis.

Es un buen ejemplo ... y un buen caso de uso ... Podrías hacer

@media-section

(o grupo de medios) que luego le dirá menos que agrupe los medios (opcionalmente fusionarlo en la consulta de medios si ya existía, lo que le permitiría llevar las reglas a donde quiera que quisiera ponerlas). ¿lo que quieres decir?

Estoy tentado a pensar que es una buena idea (y no demasiado difícil de implementar)

+1 para @ media-group

+1 @ media-group

La otra opción sería tener una opción global para agrupar verdadero / falso.

Mmm, probablemente sea una buena idea. ¿Habría algún caso en el que sería necesaria una agrupación selectiva?

Creo que en la mayoría de los casos, las personas solo quieren que sus consultas de medios sean más compactas, por lo que una opción global por ahora podría ser el camino a seguir. Si alguien dice que necesita una agrupación selectiva, se podrían agregar nuevas palabras clave más adelante.

+1 para una opción de agrupación global.

sí ... porque vimos con @import que agregar varias palabras clave no era el camino a seguir y agregar una opción es menos controvertido.

Yo diría que agregue la opción, ya que sería útil de inmediato y podría coexistir como una anulación con una importación selectiva si alguna vez se creara.

Hola, acabo de ver este problema y quería compartir una pequeña aplicación que hice cuando necesitaba agrupar consultas de medios. Esta no es una aplicación terminada. Más como una investigación para una herramienta futura. Así que solo quiero mostrarles la idea, porque realmente creo que es algo que debe implementarse. (puede haber errores y otros problemas) pero lo probé con mi último proyecto que incluye twitter bootstrap y funciona correctamente. (no hay problema con el orden de las reglas) avísame;)

http://mqhelper.nokturnalapp.com

¡Hola!

¿Hay alguien asignado a esto? Es una gran característica que podría ser muy útil para disminuir el archivo css cuando se crea con menos. Y de esta forma, será más fácil para los desarrolladores trabajar con todos estos @mqs.

@AoDev mqhelper es definitivamente un paso en la dirección correcta, pude ver que es útil como parte de un proceso de vinculación de CSS por ahora. Creo que solo necesita la funcionalidad principal extraída de las cosas del front-end en su demostración.

Sí, pero el objetivo de mi aplicación no es formar parte de una "herramienta real". Acabo de ver a mucha gente aquí preguntándose si agrupar consultas de medios podría ser un problema y quería demostrar que se puede hacer. El código está ahí para los desarrolladores de less si quieren tener una idea y usar partes de ella. Pero puedo convertirlo en un módulo "real" si quieres :)

Ya lo logré, es un buen trabajo, gracias.

@Soviut @lukeapage Creo que la agrupación selectiva tiene más sentido. Todo o nada causa estragos en el intento de mantener la cascada. Debería ser algo similar a extender, o tal vez agregar literalmente una palabra clave de grupo. Como si esta sintaxis fuera genial:

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

Hola, la agrupación de consultas de medios sería una buena adición. Mientras tanto, se me ocurrió esta idea, me pregunto si podría usarse con la próxima función :extend para evitar propiedades 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(); }

La herramienta creada por @AoDev es excelente para mostrar cómo el enfoque de "todo o nada" realmente no debería importar. La agrupación de consultas de medios no sufre los mismos efectos secundarios que la agrupación / reordenación de estilos. ¿Alguien puede proporcionar un ejemplo del mundo real (probado con la herramienta creada por @AoDev ) que muestre cómo el método de todo o nada es defectuoso?

@kamranayub explicó perfectamente la situación exacta con la que estoy lidiando. Personalmente, me encantaría ver alguna forma de esta implementación. @DesignByOnyx , el código de prueba a continuación no se compila correctamente con la herramienta de @AoDev . Preferiría hacer este tipo de estilo como mencionó kamranayub. Es mucho más limpio cuando se trata de varios archivos menos en sitios más grandes.

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

}

No funciona porque ha utilizado menos sintaxis. Está destinado a funcionar
con CSS.
El 2 de julio de 2013 a las 21:19, "P Macom" [email protected] escribió:

@kamranayub https://github.com/kamranayub explicó perfectamente el exacto
situación con la que estoy lidiando. Personalmente, me encantaría ver alguna forma
de esta implementación. @DesignByOnyx https://github.com/DesignByOnyx ,
el código de prueba a continuación no se compila correctamente con @A oDevhttps: //github.com/AoDev 's
herramienta. Preferiría hacer este tipo de estilo como mencionó kamranayub.
Es mucho más limpio cuando se trata de varios archivos menos en sitios más grandes.

.footer ul {

margen: 10px;

@media @ layout-tablet, @ layout-full {
tamaño de fuente: 13px;
font-weight: negrita;
}
@media @ layout-mobile {
tamaño de fuente: 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 correo electrónico directamente o véalo en Gi
.

¿La propuesta para ejecutar la lógica utilizada por la herramienta de @AoDev después de que se procesa LESS? No puedo pensar en un caso en el que eso no sea lo que quiero de mi cabeza.

¿La propuesta para ejecutar la lógica utilizada por la herramienta de @AoDev después de que se procesa LESS? No puedo pensar en un caso en el que eso no sea lo que quiero de mi cabeza.

Creo que es una opción para el ínterin, consideraría envoltura @AoDev 's solución en un grunt.js módulo de manera que se puede ejecutar de forma automática después de que el menos es procesada (esto se basa en la suposición de que el pre-procesamiento está siendo hecho antes del despliegue, no sobre la marcha)

Una tarea difícil sin duda sería agradable en el ínterin y útil universalmente para CSS sin procesar. Sin embargo, considerando lo mucho que @media magic LESS ya está haciendo, una opción de agrupación parece lógica.

Por otra parte, dijo que la tarea Grunt podría separar completamente las consultas de medios en sus propios archivos, para aquellos a quienes les gusta cargar hojas de estilo móviles sobre la marcha.

Ahora que lo menciona, separar las hojas de estilo es una opción útil; actualmente, necesitaría crear sus archivos fuente específicamente para hacer eso.

¿Quizás haya espacio aquí para una herramienta de optimización de consultas de medios separada para agrupar y, opcionalmente, dividir las consultas de medios?

Absolutamente. No estoy seguro de si CSSO ya hace esto, siendo el único reescritor de CSS que conozco que también tiene una tarea Grunt asociada. Pero ni siquiera puede dividir cosas como consultas de medios en archivos separados. Del mismo modo, su reescritura es muy básica, basada en selectores y atributos idénticos, a diferencia de la estructura DOM.

Mqhelper ya le devuelve las consultas de medios individuales, consulte el github
página para más detalles. Los archivos CSS separados se pueden construir desde allí.
El 5 de julio de 2013 a las 10:08 a. M., "Soviut" [email protected] escribió:

Absolutamente. No estoy seguro de si CSSO ya hace esto, siendo el único CSS
El reescritor que conozco también tiene una tarea Grunt asociada. Pero incluso
no puede dividir cosas como consultas de medios en archivos separados. Similar,
su reescritura es muy básica, basada en selectores y atributos idénticos,
a diferencia de la estructura DOM.

-
Responda a este correo electrónico directamente o véalo en Gi
.

Suena como algo útil a menos largo plazo y no demasiado difícil.
(tanto una opción de agrupación como una opción de archivo separado) si uno de ustedes
me gusta implementar te puedo ayudar ...

No quiero desalentar el avance hacia algún tipo de idea de "sección" o "grupo" para implementar esto (creo que es bueno). Sin embargo, si alguien desea tener la capacidad de definir la información de propiedad @media en el código donde está definida para el CSS normal, pero agruparla en una sola consulta @media en otra parte del código, Hay al menos dos formas que se pueden hacer actualmente con MENOS funcionalidad, lo que brinda un buen control de ubicación, pero es cierto que con algo de codificación adicional por encima de lo que requeriría la solución propuesta (así que, por supuesto, continúe trabajando en eso). 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 produce 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;
}

He querido hacer 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;
}

pero sin agrupación, el CSS generado es un poco voluminoso

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

Hay una solución para esto https://github.com/buildingblocks/grunt-combine-media-queries, sin embargo, solo ordena por ancho mínimo en este momento, por lo que es principalmente útil para los primeros sitios móviles.

En mi opinión, tiene sentido generalizar el problema al control de agrupación de alcance que proporcionará una solución para el problema n. ° 930

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

¡Gran herramienta @krava ! Gracias

Excelente !!! En mi opinión, tiene todo el sentido implementar la función de KRAVA en MENOS

+1

Quiero hacerlo como complemento. no debería ser demasiado difícil. ¡Aunque hay mucho que hacer!

Creo que los complementos deberían tener menos prioridad que tener un sistema para autocargar complementos (options.json). Pero sí, un complemento tiene sentido como característica adicional.

¿Ya se ha implementado esta opción?
Esto probablemente reduciría mi CSS generado a la mitad ya que uso consultas de medios dentro de los componentes y estaría feliz de tenerlos agrupados en la etapa de salida.

Con respecto a la reordenación de selectores, si usa una palabra clave "grupo" para agrupar algo, es consciente de que se eliminará del flujo lógico actual y se colocará en un área agrupada.

http://helloanselm.com/2014/web-performance-one-or-thousand-media-queries/
Según este artículo, no es necesario agrupar las consultas de medios.
Pero un complemento es bueno.

No se trata tanto de una cuestión de rendimiento como del tamaño del archivo CSS resultante. Docenas de cadenas <strong i="5">@media</strong> screen and (max-width: 480px) comienzan a sumarse en términos de tamaño de archivo CSS.

Hice esta pregunta sobre SO y alguien dio una respuesta parcial a este problema.

@ seven-phase-max le dio la respuesta y se refirió a este problema en su respuesta. Muy meta;)

Definitivamente prefiero el método mixin para fusionar las consultas de medios, en lugar de procesarlas posteriormente. Esto permite escribir más fácilmente y tener más control sobre qué se fusiona y cómo.

Aquí en los comentarios puedes ver la solución que utilizo en todos mis proyectos:
https://github.com/less/less.js/issues/950#issuecomment -17723748

Acabo de hacer una búsqueda y encontré dos complementos gruñidos que hacen agrupaciones de consultas de medios:

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

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

Las consultas de medios combinados también están disponibles para gulp .
http://github.com/konitter/gulp-combine-media-queries

Desde v2 puede usar complementos, así que consulte https://github.com/bassjobsen/less-plugin-group-css-media-queries (y https://github.com/bassjobsen/less-plugin-pleeease)

Cerrar ya que es compatible con un complemento y no es una prioridad para pasar al núcleo (AFAIK - @ less / admin correct si esto es incorrecto).

@gyopiazza Tengo una pregunta sobre https://github.com/less/less.js/issues/950#issuecomment -17723748 arriba: ¿por qué necesitas inicializar el mixin? Quiero decir, el CSS se compila sin init. Supongo que estoy tratando de comprender las mejores prácticas y su uso.

@nfq Esto no es una inicialización, sino una definición vacía "predeterminada". Es necesario en caso de que no proporcione sus .step*() mixins personalizados (es decir, se asume que puede tener estas cosas en diferentes archivos, por ejemplo, las definiciones de .step*() "predeterminadas" y su representación están en algunos código de utilidad / biblioteca, mientras que las definiciones .step*() están en el código específico de su tema / proyecto).

@nfq En realidad, no es necesario.
Como mencionó @ seven-phase-max, es útil evitar errores en caso de que no use los mixins en su código, ya que las consultas de medios llamarán al mixin inexistente.

Por cierto, la ventaja de esta técnica es que la combinación de consultas de medios ralentiza el tiempo de compilación (un poco).

@gyopiazza Gracias por la rápida respuesta. No me importa el tiempo de compilación, y para proyectos grandes, definitivamente prefiero agrupar todas las consultas de medios en la parte inferior de la hoja de estilo principal. Probé algunos de los complementos, pero encontré tu camino más fácil para nuestro caso de uso y el más conveniente. ¡¡Gracias!!

@ seven-phase-max Gracias, su respuesta tiene sentido. Uso menos mucho, ¡pero aún no he entendido cuál es la mejor manera de lograr ciertas cosas!

Tenga en cuenta que también clean-css admite la fusión de @media desde v3, y también lo hace less-plugin-clean-css

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

less-plugin-clean-css establece --skip-advanced true de forma predeterminada, debe establecer explícitamente la opción advanced para la fusión de @media

@nfq Con el "enfoque mixin", las consultas de medios todavía se compilan en la parte inferior (o en cualquier lugar donde las declare).

@gyopiazza gracias, sí. Feliz con este enfoque !!

@bassjobsen Definitivamente