Less.js: Gruppenmedienanfragen

Wie machen Sie das, ohne die Bedeutung möglicherweise zu ändern, indem Sie die Aussagen neu ordnen?

Ich glaube nicht, dass die Bedeutungen geändert werden können. Dies wäre genau dasselbe wie das Zusammenklappen normaler redundanter Tags. Zum Beispiel:

body {
    background: white;
}

body {
    padding: 0;
    margin: 0;
}

Würde zusammengelegt zu:

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

Dies ist bei Medienabfragen noch mehr der Fall, da es sich um spezielle Top-Level-Selektoren handelt, die als Kontrollebene über den normalen Element-Selektoren fungieren. Im Grunde haben sie nur eine einzige Bedeutung und werden vom Rest der CSS innerhalb der Datei nicht beeinflusst.

Darüber hinaus behält weniger bereits die Reihenfolge der geblasenen Medienabfragen bei, es erstellt nur viele redundante Selektoren für genau dieselbe Abfrage. Wenn sie gepuffert und am Ende der Verarbeitung in eine einzelne Abfrage geschrieben werden könnten, wäre dies viel sauberer und würde eine kleinere CSS-Ausgabe erzeugen.

Welche Regeln gelten in Bezug auf die Selektorkomplexität in Medienabfragen? Mach das
Abfragen erhöhen die Komplexität und überschreiben jede Reihenfolge? Kannst du auf irgendwas zeigen?
Spezifikationen?

Im Wesentlichen ja. Medienselektoren sind wie IF-Anweisungen, die normale Stilregeln umschließen und nur gelten, wenn die Bedingung der Abfrage erfüllt ist. Wenn die Breite des Browsers beispielsweise weniger als eine bestimmte Anzahl von Pixeln beträgt, werden die Regeln in der Abfrage aktiviert und überschreiben die vorhandenen Regeln.

Viele identische Abfragen mit jeweils einem einzigen Stil wären also funktional identisch mit einer Abfrage mit allen darin enthaltenen Stilen. Solange die Abfrage gleich ist.

Hier ist eine Dokumentation von Mozilla

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

Was ich meine, ist in diesem Beispiel.. das div wird rot - was bedeutet, dass eine Neuordnung der Medienabfragen (beide für den Bildschirm) die Bedeutung des CSS ändern würde

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

Es sollte nur kombiniert werden, wenn die Regelsätze direkt aufeinander folgen.

was sie im @Soviut- Originalbeispiel nicht

Ich stimme zu, aber ich verstehe nicht, wie dies auf Medienabfragen mit Blasen zutreffen würde? Denken Sie daran, dass sprudelnde Abfragen ein bisschen syntaktischer Zucker sind; Normalerweise können Sie eine Medienabfrage nicht in einen anderen Selektor einbetten. Es kann also mit Sicherheit davon ausgegangen werden, dass Sie jedes Mal, wenn Sie auf eine sprudelnde Abfrage stoßen, diese mit identischen sprudelnden Abfragen in der Reihenfolge ihres Eintreffens gruppieren.

Wenn Sie zwei sprudelnde Medienabfragen nebeneinander haben, die kombiniert werden können, wäre es meiner Meinung nach sehr naheliegend, dies in weniger zu tun. Können Sie ein konkretes Beispiel geben, wo es sicher wäre, die Medienabfragen zu kombinieren und es sinnvoll ist? um sie im Weniger getrennt zu halten?

Beim Umgang mit Retina-Bildern haben wir die komplexe Medienabfrage in ein Mixin verpackt und Sprite-Mixins erstellt, also haben wir dies überall ... es erhöht das Ausgabe-CSS, ist aber wartungsfreundlicher.

Hier ist zum Beispiel unser Sprite-Mixin:

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

Wobei @mediaRetina ist:

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

Im Folgenden erstellen wir weitere Mixins, um jedes Sprite-Element wie folgt zu umschließen:

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

Und verwenden Sie es in anderen LESS-Dateien wie dieser:

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

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

}

In diesem Fall sieht das generierte CSS wie folgt aus:

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

Stellen Sie sich nun vor, dass dieser Fall viele Male wiederholt wird. Ohne Gruppierung besteht die einzige Möglichkeit, dieses zusätzliche Gewicht zu verringern, darin, jeden Retina-Stil in eine dedizierte LESS-Datei zu verschieben, was für kleine Sites funktionieren kann, aber für eine große Site unrealistisch ist.

Hier ist es sinnvoll, sie zu gruppieren und getrennt zu halten, insbesondere wenn Sie eine große Site mit vielen Modulen haben (wie unsere).

Ich weiß jedoch, was Sie mit dem Überschreiben von Stilen meinen, und ich bin mir nicht sicher, ob Sie genau diese Funktion sicher implementieren können, ohne möglicherweise die Kaskadierung zu beeinträchtigen, die ein Designer möglicherweise möchte.

Für mich klingt das eher so, als könnte man einen "Abschnitt" (einen Platzhalter) definieren und dann Stile definieren, die darin platziert werden sollen, in welcher Reihenfolge sie auch immer geschrieben werden. Dies ist bei serverseitigen Vorlagen ziemlich üblich, wo Sie einen Abschnitt "Skripte" oder "Kopf" haben und Ihre Seiten dann beim Laden Inhalte in diese einfügen können.

Also, ich möchte dies im Wesentlichen in einer WENIGER Datei tun können:

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

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

Das @section würde beim Kompilieren durch den aktuellen Selektor ersetzt.

Mein Sprite-Mixin würde also einfach zu:

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

Es muss nicht diese Syntax (oder Implementierung) sein, ich basiere auf der ASP.NET Razor-Syntax, da ich damit vertraut bin und mir die Syntax gefällt.

Es ist ein gutes Beispiel.. und ein guter Anwendungsfall.. Du könntest tun

@media-section

(oder Mediengruppe), die dann weniger sagen würde, um die Medien zusammenzufassen (optional in die Medienabfrage einzufügen, wenn sie bereits existierte, was es Ihnen ermöglicht, die Regeln dorthin zu ziehen, wo Sie sie platzieren möchten).. vielleicht ist das so Was meinst du?

Ich bin versucht zu denken, dass es eine gute Idee ist (und nicht allzu schwer umzusetzen)

+1 für @media-group

+1 @media-group

Die andere Option wäre eine globale Option zum Gruppieren von wahr/falsch.

Hmm, das ist wahrscheinlich eine gute Idee. Gibt es einen Fall, in dem eine selektive Gruppierung erforderlich wäre?

Ich denke, in den meisten Fällen möchten die Leute nur, dass ihre Medienanfragen kompakter sind, sodass eine globale Option vorerst der richtige Weg sein könnte. Sollte jemand behaupten, eine selektive Gruppierung zu benötigen, könnten später neue Schlüsselwörter hinzugefügt werden.

+1 für eine globale Gruppierungsoption.

ja... weil wir bei @import dass das Hinzufügen mehrerer Schlüsselwörter nicht der richtige Weg ist und das Hinzufügen einer Option weniger umstritten ist.

Ich würde sagen, die Option hinzufügen, da sie sofort nützlich wäre und als Überschreibung mit einem selektiven Import koexistieren könnte, sollte sie jemals erstellt werden.

Hallo, ich habe gerade dieses Problem gesehen und wollte eine kleine App teilen, die ich erstellt habe, um Medienabfragen zu gruppieren. Dies ist keine fertige App. Eher wie eine Recherche für ein zukünftiges Tool. Ich möchte Ihnen nur die Idee zeigen, weil ich wirklich denke, dass es etwas ist, das umgesetzt werden muss. (es kann Fehler und andere Probleme geben), aber ich habe es mit meinem letzten Projekt getestet, das Twitter-Bootstrap enthält und es funktioniert einwandfrei. (kein Problem mit der Reihenfolge der Regeln) lass es mich wissen ;)

http://mqhelper.nokturnalapp.com

Hallo!

Ist jemand damit beauftragt? Es ist eine großartige Funktion, die sehr nützlich sein kann, um CSS-Dateien zu verkleinern, wenn sie mit weniger erstellt werden. Auf diese Weise wird es für Entwickler einfacher, mit all diesen @mqs zu arbeiten.

@AoDev mqhelper ist definitiv ein Schritt in die richtige Richtung, ich könnte es vorerst als Teil eines CSS-Linting-Prozesses als nützlich ansehen. Ich denke, es braucht nur die Kernfunktionalität, die aus dem Front-End-Zeug in Ihrer Demo extrahiert wird.

Ja, aber das Ziel meiner App ist es nicht, Teil eines "richtigen Tools" zu sein. Ich habe hier gerade viele Leute gesehen, die sich gefragt haben, ob das Gruppieren von Medienabfragen ein Problem sein könnte, und wollten zeigen, dass dies möglich ist. Der Code ist für die Entwickler von weniger da, wenn sie eine Idee haben und Teile davon verwenden möchten. Aber ich kann es zu einem "richtigen" Modul machen, wenn du willst :)

Ich habe es schon geschafft, es ist eine schöne Arbeit, danke.

@Soviut @lukeapage Ich denke, eine selektive Gruppierung ist am sinnvollsten. Alles oder nichts zerstört den Versuch, die Kaskade aufrechtzuerhalten. Sollte etwas Ähnliches zum Erweitern sein, oder vielleicht buchstäblich ein Gruppen-Keyword hinzufügen. Wie diese Syntax wäre großartig:

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

Hallo, die Gruppierung von Medienabfragen wäre eine wirklich schöne Ergänzung. In der Zwischenzeit bin ich auf diese Idee gekommen und frage mich, ob sie mit der kommenden :extend Funktion verwendet werden könnte, um doppelte Eigenschaften zu vermeiden:

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

Das von @AoDev erstellte Tool dem von @AoDev erstellten Tool ), das zeigt, wie fehlerhaft die Alles-oder-Nichts-Methode ist?

@kamranayub hat die genaue Situation, mit der ich es zu tun @DesignByOnyx , der folgende @AoDev nicht richtig kompiliert. Ich würde es vorziehen, diese Art von Styling zu machen, wie Kamranayub erwähnt hat. Es ist viel sauberer, wenn Sie mit mehreren Dateien weniger auf größeren Websites arbeiten.

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

}

Es funktioniert nicht, weil Sie weniger Syntax verwendet haben. Es soll funktionieren
mit CSS.
Am 2. Juli 2013 um 21:19 schrieb "P Macom" [email protected] :

@kamranayub https://github.com/kamranayub hat das genau erklärt
Situation, mit der ich zu tun habe. Persönlich würde ich gerne eine Form sehen
dieser Umsetzung. @DesignByOnyx https://github.com/DesignByOnyx ,
der Testcode unten wird nicht richtig mit @A oDev kompilierthttps
Werkzeug. Ich würde es vorziehen, diese Art von Styling zu machen, wie Kamranayub erwähnt hat.
Es ist viel sauberer, wenn Sie mit mehreren Dateien weniger auf größeren Websites arbeiten.

.Fußzeile ul {

Rand: 10px;

@media @layout-tablet, @layout-full {
Schriftgröße: 13px;
Schriftdicke: fett;
}
@media @layout-mobile {
Schriftgröße: 10px;
Polsterung-links: 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) }

}
}

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/less/less.js/issues/950#issuecomment -20369038
.

Ist der Vorschlag, die vom Tool von auszuführen , nachdem das LESS verarbeitet wurde? Ich kann mir keinen Fall vorstellen, in dem das nicht das wäre, was ich aus dem Kopf will.

Ist der Vorschlag, die vom Tool von auszuführen , nachdem das LESS verarbeitet wurde? Ich kann mir keinen Fall vorstellen, in dem das nicht das wäre, was ich aus dem Kopf will.

Ich denke, das ist eine Option für die Zwischenzeit. Ich würde in Betracht ziehen , die Lösung von @AoDev in ein grunt.js-Modul zu verpacken, damit es automatisch ausgeführt werden kann, nachdem das LESS verarbeitet wurde (dies basiert auf der Annahme, dass die Vorverarbeitung durchgeführt wird) vor der Bereitstellung durchgeführt, nicht im laufenden Betrieb)

Eine Grunt-Aufgabe wäre sicherlich in der Zwischenzeit nett und universell für rohes CSS nützlich. Bedenkt man jedoch, wie viel LESS bereits leistet, erscheint eine Gruppierungsoption logisch.

Andererseits könnte die Grunt-Aufgabe die Medienabfragen vollständig in ihre eigenen Dateien aufteilen, für diejenigen, die mobile Stylesheets im Handumdrehen laden möchten.

Nun, da Sie es erwähnen, ist das Trennen der Stylesheets eine nützliche Option - derzeit müssten Sie Ihre Quelldateien speziell dafür erstellen.

Vielleicht gibt es hier Spielraum für ein separates Media-Query-Optimierungstool, um die Media-Queries zu gruppieren und optional aufzuteilen?

Absolut. Ich bin mir nicht sicher, ob CSSO dies bereits tut, da ich der einzige CSS-Rewriter bin, der auch mit einer Grunt-Aufgabe verbunden ist. Aber selbst es kann Dinge wie Medienabfragen nicht in separate Dateien aufteilen. Ebenso ist das Umschreiben sehr einfach und basiert auf identischen Selektoren und Attributen im Gegensatz zur DOM-Struktur.

Mqhelper gibt Ihnen bereits einzelne Medienabfragen zurück. Überprüfen Sie den github
Seite für weitere Details. Von dort können getrennte CSS-Dateien erstellt werden.
Am 5. Juli 2013, 10:08 Uhr, schrieb "Soviut" [email protected] :

Absolut. Ich bin mir nicht sicher, ob CSSO dies bereits tut, da es das einzige CSS ist
Umschreiber, der mir bekannt ist, hat auch eine Grunt-Aufgabe damit verbunden. Aber selbst
Es kann Dinge wie Medienabfragen nicht in separate Dateien aufteilen. Ähnlich,
seine Umschreibung ist sehr einfach und basiert auf identischen Selektoren und Attributen.
im Gegensatz zur DOM-Struktur.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/less/less.js/issues/950#issuecomment -20505834
.

Es klingt nach etwas Sinnvollem für weniger langfristige und nicht allzu schwierige
(sowohl eine Gruppierungsoption als auch eine separate Dateioption), wenn einer von euch würde
gerne umsetzen kann ich dir helfen...

Ich möchte nicht entmutigen, sich zu einer Art "Abschnitts-" oder "Gruppen"-Idee zu bewegen, um dies zu implementieren (ich denke, das ist gut). Wenn jedoch jemand die Möglichkeit wünscht, die Eigenschaftsinfo @media im Code zu definieren, wo sie für das reguläre CSS definiert ist, aber sie an anderer Stelle im Code in einer einzigen @media Abfrage gruppieren möchte, gibt es gibt es mindestens zwei Möglichkeiten, die derzeit mit WENIGER Funktionalität durchgeführt werden können, was eine gute Kontrolle der Platzierung bietet, aber zugegebenermaßen mit etwas zusätzlicher Codierung, die über dem liegt, was die vorgeschlagene Lösung erfordern würde (also auf jeden Fall weiter daran arbeiten). Erwägen:

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

Was erzeugt dieses 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;
}

Ich wollte etwas machen wie:

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

aber ohne Gruppierung ist das generierte CSS etwas sperrig

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

Es gibt eine Lösung für dieses https://github.com/buildingblocks/grunt-combine-media-queries, die jedoch derzeit nur nach Mindestbreite sortiert und daher hauptsächlich für mobile First-Sites nützlich ist.

IMO ist es sinnvoll, das Problem auf die Bereichsgruppierungssteuerung zu verallgemeinern, die eine Lösung für Problem #930 bietet

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

Tolles Werkzeug @krava ! Danke

Ausgezeichnet!!! IMO macht es Sinn, KRAVAs Feature auf LESS zu implementieren

+1

Ich möchte es als Plugin tun. sollte nicht zu schwer sein. aber zu viel zu tun!

Ich denke, Plugins sollten eine niedrigere Priorität haben als ein System zum automatischen Laden von Plugins (options.json). Aber ja, ein Plugin macht als zusätzliches Feature Sinn.

Ist diese Option schon implementiert?
Dies würde mein ausgegebenes CSS wahrscheinlich um die Hälfte reduzieren, da ich Medienabfragen innerhalb von Komponenten verwende und sie gerne in der Ausgabephase gruppieren würde.

In Bezug auf die Neuordnung des Selektors: Wenn Sie ein "group"-Schlüsselwort verwenden, um etwas zu gruppieren, wissen Sie, dass es aus dem aktuellen logischen Fluss entfernt und in einem gruppierten Bereich platziert wird.

http://helloanselm.com/2014/web-performance-one-or-thousand-media-queries/
Gemäß diesem Artikel ist es nicht erforderlich, die Medienanfragen zu gruppieren.
Aber ein Plugin ist gut.

Es ist nicht so sehr eine Frage der Leistung, sondern der Größe der resultierenden CSS-Datei. Dutzende von <strong i="5">@media</strong> screen and (max-width: 480px) Strings summieren sich in Bezug auf die CSS-Dateigröße.

Ich habe diese Frage auf SO gestellt und jemand hat eine teilweise Antwort auf dieses Problem gegeben.

@seven-phases-max hat Ihnen die Antwort gegeben und in seiner Antwort auf dieses Problem zurückgegriffen. Sehr Meta ;)

Ich bevorzuge definitiv die Mixin-Methode, um die Medienabfragen zusammenzuführen, anstatt sie nachzubearbeiten. Dies ermöglicht eine einfachere Eingabe und mehr Kontrolle darüber, was zusammengeführt wird und wie.

Hier in den Kommentaren können Sie die Lösung sehen, die ich in all meinen Projekten verwende:
https://github.com/less/less.js/issues/950#issuecomment -17723748

Ich habe gerade eine Suche durchgeführt und zwei Grunt-Plugins gefunden, die Medienabfragen gruppieren:

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

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

Kombinierte Medienabfragen sind auch für gulp verfügbar.
http://github.com/konitter/gulp-combine-media-queries

Seit v2 können Sie Plugins verwenden, siehe https://github.com/bassjobsen/less-plugin-group-css-media-queries (und https://github.com/bassjobsen/less-plugin-pleeease)

Wird geschlossen, da dies von einem Plugin unterstützt wird und keine Priorität für den Wechsel in den Kern ist (AFAIK - @less/admin korrekt, wenn dies falsch ist).

@gyopiazza Ich habe eine Frage zu https://github.com/less/less.js/issues/950#issuecomment -17723748 oben: Warum müssen Sie das Mixin initialisieren? Ich meine, das CSS kompiliert ohne die init. Ich schätze, ich versuche, bewährte Verfahren und Verwendung zu verstehen.

@nfq Dies ist nicht ganz eine Initialisierung, sondern nur eine leere "Standarddefinition". Es ist notwendig , falls Sie bieten nicht Ihre benutzerdefinierten .step*() Mixins (dh es wird angenommen , dass Sie diese Dinge in verschiedenen Dateien haben kann, zB „default“ .step*() Definitionen und ihre Rendering sind in einigen generic Dienstprogramm-/Bibliothekscode, während benutzerdefinierte .step*() Definitionen in Ihrem themen-/projektspezifischen Code enthalten sind).

@nfq Es ist eigentlich nicht notwendig.
Wie @seven-phases-max erwähnt, ist es nützlich, Fehler zu vermeiden, falls Sie die Mixins in Ihrem Code nicht verwenden, da die Medienabfragen das nicht vorhandene Mixin aufrufen.

Der Vorteil dieser Technik besteht übrigens darin, dass das Kombinieren von Medienabfragen die Kompilierungszeit (ein bisschen) verlangsamt.

@gyopiazza Danke für die schnelle Antwort. Die Kompilierungszeit macht mir nichts aus und bei großen Projekten ziehe ich es definitiv vor, alle Medienabfragen am Ende des Haupt-Stylesheets zu gruppieren. Ich habe einige der Plugins ausprobiert, fand aber für unseren Anwendungsfall den einfachsten und bequemsten Weg. Vielen Dank!!

@seven-phases-max Danke, deine Antwort macht Sinn. Ich benutze viel weniger, habe aber noch nicht verstanden, wie man bestimmte Dinge am besten erreicht!

Beachten Sie, dass clean-css seit v3 auch das Zusammenführen von @media unterstützt, ebenso wie das less-plugin-clean-css

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

less-plugin-clean-css setzt --skip-advanced standardmäßig auf true. Sie sollten explizit die Option advanced für das Zusammenführen von

@nfq Beim "Mixin-Ansatz" werden Medienabfragen immer noch unten kompiliert (oder irgendwo, wo Sie sie deklarieren).

@gyopiazza danke, ja. Zufrieden mit diesem Ansatz!!

@bassjobsen Ich werde dies auf jeden Fall bei einem größeren Projekt verwenden. Ich habe noch nicht damit begonnen, Less-Plugins zu verwenden. Danke für die Tipps!