Less.js: Requêtes médias de groupe

Comment y parvenir sans potentiellement altérer le sens en réorganisant les énoncés ?

Je ne pense pas que les significations pourraient être modifiées. Ce serait exactement la même chose que de réduire les balises redondantes normales. Par exemple:

body {
    background: white;
}

body {
    padding: 0;
    margin: 0;
}

Serait réduit à :

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

C'est encore plus le cas avec les media queries car ce sont des sélecteurs spéciaux de niveau supérieur qui agissent comme une couche de contrôle au-dessus des sélecteurs d'éléments normaux. Fondamentalement, ils n'ont qu'une seule signification et ne sont pas affectés par le reste du css dans le fichier.

De plus, moins maintient déjà l'ordre des requêtes multimédias en bulles, cela crée simplement de nombreux sélecteurs redondants pour exactement la même requête. S'ils pouvaient être mis en mémoire tampon et écrits dans une seule requête à la fin du traitement, cela serait beaucoup plus net et produirait une sortie CSS plus petite.

Quelles sont les règles concernant la complexité des sélecteurs dans les requêtes multimédias ? Faire le
les requêtes augmentent la complexité et remplacent tout ordre ? Pouvez-vous indiquer n'importe quel
spécifications ?

Essentiellement, oui. Les sélecteurs de médias sont comme des instructions IF qui entourent les règles de style normales et ne s'appliquent que si la condition de la requête est remplie. Par exemple, si la largeur du navigateur est inférieure à un certain nombre de pixels, les règles de la requête sont activées et remplacent les règles existantes.

Donc, avoir beaucoup de requêtes identiques avec un seul style, chacune serait fonctionnellement identique à une requête avec tous les styles à l'intérieur. Tant que la requête est la même.

Voici de la documentation de Mozilla

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

ce que je veux dire, c'est dans cet exemple .. le div devient rouge - ce qui signifie que la réorganisation des requêtes multimédias (à la fois pour l'écran) changerait la signification du 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;
    }
}

Il ne devrait se combiner que si les ensembles de règles se suivent directement.

ce qu'ils ne font pas dans l'exemple original de @Soviut , ce qui rend cette demande de fonctionnalité d'une utilisation limitée dans l'OMI

Je suis d'accord, mais je ne vois pas comment cela s'appliquerait aux requêtes média bullées ? N'oubliez pas que les requêtes à bulles sont un peu de sucre syntaxique ; Vous ne pouvez normalement pas intégrer une requête multimédia dans un autre sélecteur. On peut donc supposer en toute sécurité que chaque fois que vous rencontrez une requête bouillonnante, vous devez la regrouper avec des requêtes bouillonnantes identiques dans l'ordre dans lequel elles arrivent.

Si vous avez deux requêtes média à bulles côte à côte qui peuvent être combinées, je pense qu'il serait très évident de le faire dans le moins .. pouvez-vous donner un exemple réel où il serait sûr de combiner les requêtes média et cela a du sens pour les garder séparés dans le moins ?

Lorsque nous traitons des images de rétine, nous avons enveloppé la requête multimédia complexe dans un mixin et créé des mixins de sprite, nous avons donc cela partout... cela augmente le CSS de sortie mais c'est plus maintenable.

Par exemple, voici notre mixin 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);
    }
}

Où @mediaRetina est :

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

Ensuite, ci-dessous, nous créons plus de mixins pour envelopper chaque élément de sprite comme ceci :

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

Et utilisez-le dans d'autres fichiers LESS comme celui-ci :

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

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

}

Dans ce cas, le CSS généré ressemble à :

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

Imaginez maintenant que ce cas se répète plusieurs fois. Sans regroupement, le seul moyen d'alléger ce poids supplémentaire est de déplacer chaque style de rétine dans un fichier LESS dédié, ce qui peut fonctionner pour les petits sites, mais n'est pas réaliste pour un grand site.

C'est là qu'il est logique de les regrouper et de les garder séparés, surtout si vous avez un gros site avec beaucoup de modules (comme le nôtre).

Je sais ce que vous entendez par substitution de styles, cependant, et je ne suis pas sûr que vous puissiez implémenter en toute sécurité cette fonctionnalité exacte sans potentiellement jouer avec la cascade qu'un concepteur pourrait souhaiter.

Pour moi, cela ressemble plus à la possibilité de définir une "section" (un espace réservé), puis de définir les styles à y placer, quel que soit l'ordre dans lequel ils sont écrits. C'est assez courant dans les modèles côté serveur, où vous avez une section "scripts" ou "head", puis vos pages peuvent y injecter du contenu lorsqu'elles sont chargées.

Donc, j'aimerais pouvoir le faire dans un fichier LESS essentiellement :

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

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

Le @section serait remplacé à la compilation avec le sélecteur actuel.

Ainsi, mon mixin de sprite deviendrait simplement :

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

Il n'est pas nécessaire que ce soit cette syntaxe (ou cette implémentation), je la base sur la syntaxe ASP.NET Razor car c'est ce que je connais et j'aime la syntaxe.

C'est un bon exemple.. et un bon cas d'utilisation.. Vous pourriez faire

@media-section

(ou groupe de médias) qui en dirait alors moins pour regrouper les médias (éventuellement en les fusionnant dans la requête média s'il existait déjà, ce qui vous permettrait de tirer les règles là où vous vouliez les mettre) .. peut-être que c'est ce que tu veux dire?

Je suis tenté de penser que c'est une bonne idée (et pas trop difficile à mettre en œuvre)

+1 pour @media-group

+1 @groupe-media

L'autre option serait d'avoir une option globale pour grouper vrai/faux.

Hum, c'est probablement une bonne idée. Y aurait-il un cas où un regroupement sélectif serait nécessaire ?

Je pense que dans la plupart des cas, les gens veulent juste que leurs requêtes multimédias soient plus compactes, donc une option globale pour le moment pourrait être la voie à suivre. Si quelqu'un prétend avoir besoin d'un regroupement sélectif, de nouveaux mots-clés pourraient être ajoutés ultérieurement.

+1 pour une option de regroupement global.

oui.. parce que nous avons vu avec @import que l'ajout de plusieurs mots-clés n'était pas la solution et que l'ajout d'une option est moins controversé.

Je dirais d'ajouter l'option car elle serait utile immédiatement et pourrait coexister en tant que remplacement avec une importation sélective si jamais elle devait être créée.

Bonjour, je viens de voir ce problème et je voulais partager une petite application que j'ai créée lorsque j'avais besoin de regrouper des requêtes multimédias. Ce n'est pas une application finie. Plutôt une recherche pour un futur outil. Alors je veux juste vous montrer l'idée, parce que je pense vraiment que c'est quelque chose qui doit être mis en œuvre. (il peut y avoir des bugs et d'autres problèmes) mais j'ai testé avec mon dernier projet qui inclut twitter bootstrap et cela fonctionne correctement. (pas de problème avec l'ordre des règles) faites le moi savoir ;)

http://mqhelper.nokturnalapp.com

Salut!

Quelqu'un est-il affecté à cela? C'est une fonctionnalité intéressante qui pourrait être très utile pour réduire le fichier css lorsqu'il est créé avec moins. Et de cette façon, il sera plus facile pour les développeurs de travailler avec tous ces @mqs.

@AoDev mqhelper est définitivement un pas dans la bonne direction, je pourrais le voir utile dans le cadre d'un processus de linting CSS pour le moment. Je pense qu'il suffit d'extraire les fonctionnalités de base des éléments frontaux de votre démo.

Oui mais le but de mon application n'est pas de faire partie d'un "vrai outil". Je viens de voir beaucoup de gens ici se demander si le regroupement des requêtes médiatiques pourrait être un problème et je voulais montrer que cela pouvait être fait. Le code est là pour les développeurs de moins s'ils veulent avoir une idée et en utiliser des parties. Mais je peux en faire un "vrai" module si tu veux :)

Je l'ai déjà réussi, c'est un travail soigné, merci.

@Soviut @lukeapage Je pense que le regroupement sélectif est le plus logique. Tout ou rien fait des ravages en essayant de maintenir la cascade. Devrait être quelque chose de similaire à étendre, ou peut-être ajouter littéralement un mot-clé de groupe. Comme cette syntaxe serait géniale :

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

Bonjour, le regroupement media-queries serait un très bon ajout. En attendant, j'ai eu cette idée, je me demande si elle pourrait être utilisée avec la prochaine fonctionnalité :extend pour éviter les propriétés dupliquées :

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

L'outil créé par @AoDev est idéal pour montrer à quel point l'approche "tout ou rien" ne devrait pas vraiment avoir d'importance. Le regroupement des requêtes média ne subit pas les mêmes effets secondaires des styles de regroupement/réorganisation. Quelqu'un peut-il fournir un exemple concret (testé par rapport à

@kamranayub a parfaitement expliqué la situation exacte à laquelle je suis confronté. Personnellement, j'aimerais voir une forme de cette mise en œuvre. @DesignByOnyx , le code de test ci-dessous ne se compile pas correctement avec l'outil de @AoDev . Je préférerais faire ce genre de style comme kamranayub mentionné. C'est beaucoup plus propre lorsqu'il s'agit de gérer plusieurs fichiers de moins sur des sites plus volumineux.

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

}

Cela ne fonctionne pas car vous avez utilisé moins de syntaxe. C'est censé fonctionner
avec CSS.
Le 2 juillet 2013 à 21h19, "P Macom" [email protected] a écrit :

@kamranayub https://github.com/kamranayub a parfaitement expliqué l'exact
situation à laquelle je suis confronté. Personnellement, j'aimerais voir une forme
de cette mise en œuvre. @DesignByOnyx https://github.com/DesignByOnyx ,
le code de test ci-dessous ne se compile pas correctement avec @A oDevhttps://github.com/AoDev 's
outil. Je préférerais faire ce genre de style comme kamranayub mentionné.
C'est beaucoup plus propre lorsqu'il s'agit de gérer plusieurs fichiers de moins sur des sites plus volumineux.

.footer ul {

marge : 10px ;

@media @layout-tablet, @layout-full {
taille de la police : 13px ;
font-weight : gras ;
}
@media @layout-mobile {
taille de la police : 10px ;
remplissage-gauche : 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) }

}
}

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/less/less.js/issues/950#issuecomment -20369038
.

La proposition d'exécuter la logique utilisée par l' outil de

La proposition d'exécuter la logique utilisée par l' outil de

Je pense que c'est une option pour l'intérim, j'envisagerais d'

Une tâche fastidieuse serait certainement agréable dans l'intervalle et utile universellement pour le CSS brut. Cependant, compte tenu de tout ce que @media magic LESS fait déjà, une option de regroupement semble logique.

Là encore, ladite tâche Grunt pourrait être en mesure de séparer complètement les requêtes multimédias dans leurs propres fichiers, pour ceux qui aiment charger des feuilles de style mobiles à la volée.

Maintenant que vous le mentionnez, séparer les feuilles de style est une option utile - actuellement, vous devez créer vos fichiers source spécifiquement pour le faire.

Peut-être existe-t-il ici une possibilité pour un outil d'optimisation de requêtes multimédia distinct de regrouper et éventuellement de diviser les requêtes multimédias ?

Absolument. Je ne sais pas si CSSO le fait déjà, étant le seul réécrivain CSS que je connaisse qui a également une tâche Grunt associée. Mais même cela ne peut pas diviser des éléments tels que des requêtes multimédias en fichiers séparés. De même, sa réécriture est très basique, basée sur des sélecteurs et des attributs identiques, par opposition à la structure DOM.

Mqhelper vous renvoie déjà des requêtes média individuelles, vérifiez le github
page pour plus de détails. des fichiers css séparés peuvent être construits à partir de là.
Le 5 juillet 2013 à 10h08, "Soviut" [email protected] a écrit :

Absolument. Je ne sais pas si CSSO le fait déjà, étant le seul CSS
le rewriter que je connais a également une tâche Grunt qui lui est associée. Mais même
il ne peut pas diviser des éléments tels que des requêtes multimédias en fichiers séparés. De la même manière,
sa réécriture est très basique, basée sur des sélecteurs et attributs identiques,
contrairement à la structure DOM.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/less/less.js/issues/950#issuecomment -20505834
.

Cela ressemble à quelque chose d'utile à moins long terme et pas trop difficile
(à la fois une option de regroupement et une option de fichier séparé) si l'un de vous voulait
aimer mettre en œuvre je peux vous donner de l'aide...

Je ne veux pas décourager d'aller vers un certain type d'idée de "section" ou de "groupe" pour mettre en œuvre cela (je pense que c'est bien). Cependant, si quelqu'un souhaite pouvoir définir les informations de propriété @media dans le code où elles sont définies pour le CSS normal, mais les regrouper dans une seule requête @media ailleurs dans le code, il Il y a au moins deux façons qui peuvent actuellement être faites avec la fonctionnalité LESS, donnant un bon contrôle du placement, mais certes avec un codage supplémentaire au-dessus de ce que la solution proposée nécessiterait (donc, continuez à travailler là-dessus). Envisager:

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

Ce qui produit ce 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;
}

J'ai eu envie de faire quelque chose comme :

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

mais sans regroupement, le css généré est un peu volumineux

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

Il existe une solution pour cela https://github.com/buildingblocks/grunt-combine-media-queries, mais il ne commande pour le moment que par largeur minimale, il est donc principalement utile pour les premiers sites mobiles.

OMI, il est logique de généraliser le problème au contrôle de regroupement de portée qui fournira une solution au problème n ° 930

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

Super outil @krava ! Merci

Excellent !!! OMI, il est tout à fait logique de mettre en œuvre la fonctionnalité KRAVA sur LESS

+1

Je veux le faire en tant que plugin. ne devrait pas être trop dur. trop à faire quand même !

Je pense que les plugins devraient avoir une priorité inférieure à celle d'avoir un système pour charger automatiquement les plugins (options.json). Mais oui, un plugin a du sens en tant que fonctionnalité additive.

Cette option a-t-elle déjà été implémentée ?
Cela réduirait probablement de moitié mes css générés, car j'utilise des requêtes multimédias dans des composants et je serais heureux de les regrouper à l'étape de sortie.

En ce qui concerne la réorganisation des sélecteurs, si vous utilisez un mot-clé "group" pour regrouper quelque chose, vous savez qu'il sera supprimé du flux logique actuel et placé dans une zone groupée.

http://helloanselm.com/2014/web-performance-one-or-thousand-media-queries/
Selon cet article, il n'est pas nécessaire de regrouper les requêtes média.
Mais un plugin c'est bien.

Ce n'est pas tant une question de performances que de taille du fichier CSS résultant. Des dizaines de chaînes <strong i="5">@media</strong> screen and (max-width: 480px) commencent à s'additionner en termes de taille de fichier CSS.

J'ai posé cette question sur SO et quelqu'un a donné une réponse partielle à ce problème.

@seven-phases-max vous a donné la réponse et a évoqué ce problème dans sa réponse. Très méta ;)

Je préfère définitivement la méthode mixin pour fusionner les requêtes multimédias, par opposition à leur post-traitement. Cela permet une saisie plus facile et plus de contrôle sur ce qui est fusionné et comment.

Ici, dans les commentaires, vous pouvez voir la solution que j'utilise dans tous mes projets :
https://github.com/less/less.js/issues/950#issuecomment -17723748

Je viens de faire une recherche et j'ai trouvé deux plugins grunt qui font le regroupement de requêtes multimédias :

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

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

Combiner les requêtes multimédias est également disponible pour gulp .
http://github.com/konitter/gulp-combine-media-queries

Depuis la v2, vous pouvez utiliser des plugins, alors voir https://github.com/bassjobsen/less-plugin-group-css-media-queries (et https://github.com/bassjobsen/less-plugin-pleeease)

Fermeture car cela est pris en charge par un plugin et n'est pas une priorité pour passer au noyau (AFAIK - @less/admin correct si c'est faux).

@gyopiazza J'ai une question sur https://github.com/less/less.js/issues/950#issuecomment -17723748 ci-dessus : pourquoi avez-vous besoin d'initialiser le mixin ? Je veux dire, le CSS compile sans init. Je suppose que j'essaie de comprendre les meilleures pratiques et leur utilisation.

@nfq Ce n'est pas tout à fait une initialisation mais juste une définition vide "par défaut". C'est nécessaire au cas où vous ne fourniriez pas vos .step*() mixins personnalisés (c'est-à-dire qu'il est supposé que vous pouvez avoir ces éléments dans différents fichiers, par exemple les définitions "par défaut" .step*() et leur rendu sont dans certains génériques code utilitaire/bibliothèque, tandis que les définitions personnalisées .step*() trouvent dans votre code spécifique à votre thème/projet).

@nfq Ce n'est en fait pas nécessaire.
Comme @seven-phases-max l'a mentionné, il est utile d'éviter les erreurs au cas où vous n'utiliseriez pas les mixins dans votre code, car les media-queries appelleront le mixin inexistant.

D'ailleurs, l'avantage de cette technique est que la combinaison de media queries ralentit (un peu) le temps de compilation.

@gyopiazza Merci pour la réponse rapide. Le temps de compilation ne me dérange pas, et pour les gros projets, je préfère définitivement regrouper toutes les requêtes média au bas de la feuille de style principale. J'ai essayé quelques-uns des plugins, mais j'ai trouvé votre chemin le plus simple pour notre cas d'utilisation et le plus pratique. Merci!!

@seven-phases-max Merci, votre réponse est logique. J'en utilise moins beaucoup, mais je n'ai pas encore compris la meilleure façon de réaliser certaines choses !

Notez que clean-css prend également en charge la fusion less-plugin-clean-css

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

less-plugin-clean-css définit le --skip-advanced true par défaut, vous devez explicitement définir l'option advanced pour la fusion @media

@nfq Avec l'"approche mixin", les requêtes média sont toujours compilées en bas (ou n'importe où vous les déclarez).

@gyopiazza merci, ouais. Heureux de cette approche !!

@bassjobsen Je vais certainement l'utiliser sur un projet plus important. Je n'ai pas encore commencé à utiliser les plugins Less. Merci pour les conseils!