Less.js: グループメディアクエリ

ステートメントを再編成することで、意味を変える可能性なしに、どのようにそれを行うのですか？

意味が変わることはないと思います。 これは、通常の冗長タグを折りたたむのとまったく同じです。 例えば：

body {
    background: white;
}

body {
    padding: 0;
    margin: 0;
}

次のように折りたたまれます：

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

メディアクエリは、通常の要素セレクターの上にあるコントロールレイヤーとして機能する特別なトップレベルセレクターであるため、これはさらに当てはまります。 基本的に、それらは単一の意味しか持たず、ファイル内の残りのcssの影響を受けません。

さらに、バブルメディアクエリの順序をすでに維持しているわけではなく、まったく同じクエリに対して多くの冗長セレクターを作成するだけです。 それらをバッファリングして、処理の最後に単一のクエリに書き込むことができれば、それははるかにすっきりし、より小さなcss出力を生成します。

メディアクエリ内のセレクターの複雑さに関するルールは何ですか？ する
クエリは複雑さを増し、順序を上書きしますか？ 何か指摘できますか
スペック？

基本的に、はい。 メディアセレクターは、通常のスタイルルールをラップアラウンドし、クエリの条件が満たされた場合にのみ適用されるIFステートメントのようなものです。 たとえば、ブラウザの幅が特定のピクセル数未満の場合、クエリ内のルールがオンになり、既存のルールが上書きされます。

したがって、それぞれが単一のスタイルを持つ多数の同一のクエリを持つことは、すべてのスタイルが含まれる1つのクエリと機能的に同一になります。 クエリが同じである限り。

これがMozillaのドキュメントです

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

私が意味するのは、この例です。divが赤になります。つまり、メディアクエリ（両方とも画面）を並べ替えると、cssの意味が変わります。

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

div {
     background-color: red;
}

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

ルールセットが互いに直接続く場合にのみ組み合わせる必要があります。

これは@Soviutの元の例には含まれておらず、IMOでの使用が制限されているこの機能リクエストを作成しています

同意しますが、これがバブルメディアクエリにどのように適用されるかわかりませんか？ バブル化されたクエリは、構文上の糖衣構文のビットであることを忘れないでください。 通常、別のセレクター内にメディアクエリを埋め込むことはできません。 したがって、バブリングクエリに遭遇したときはいつでも、到着した順序で同一のバブリングクエリとグループ化することが安全に想定できます。

組み合わせることができる2つのバブルメディアクエリが隣り合っている場合、それをより少なくすることは非常に明白だと思います。メディアクエリを組み合わせることが安全であり、それが理にかなっている実際の例を挙げてください。それらをより少なく保つために？

網膜画像を処理する場合、複雑なメディアクエリをミックスイン内にラップし、スプライトミックスインを作成したので、これがいたるところにあります...出力CSSが増加しますが、より保守しやすくなります。

たとえば、スプライトミックスインは次のとおりです。

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

@mediaRetinaは次のとおりです。

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

次に、以下のように、各スプライト要素をラップするためのミックスインをさらに作成します。

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

そして、次のような他のLESSファイルで使用します。

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

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

}

この場合、生成されるCSSは次のようになります。

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

ここで、このケースが何度も繰り返されることを想像してください。 グループ化せずに、この余分な重みを軽減する唯一の方法は、すべての網膜スタイルを専用のLESSファイルに移動することです。これは、小さなサイトでは機能する可能性がありますが、大きなサイトでは非現実的です。

これは、特にモジュールが多数ある大規模なサイト（私たちのような）がある場合に、それらをグループ化して分離しておくことが理にかなっている場所です。

ただし、スタイルのオーバーライドについてあなたが何を意味するのかは知っていますが、デザイナーが望む可能性のあるカスケードを混乱させることなく、この正確な機能を安全に実装できるかどうかはわかりません。

私には、これは「セクション」（プレースホルダー）を定義してから、記述されている順序に関係なく、そこに配置するスタイルを定義できるように聞こえます。 これはサーバー側のテンプレートではかなり一般的です。サーバー側のテンプレートでは、「スクリプト」または「ヘッド」セクションがあり、ページが読み込まれたときにページにコンテンツを挿入できます。

したがって、基本的にLESSファイルでこれを実行できるようにしたいと思います。

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

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

@sectionは、コンパイル時に現在のセレクターに置き換えられます。

したがって、私のスプライトミックスインは次のようになります。

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

この構文（または実装）である必要はありません。ASP.NETRazor構文に基づいています。これは、私がよく知っている構文であり、構文が気に入っているためです。

その良い例..そして良いユースケース..あなたはすることができます

@media-section

（またはmedia-group）これにより、メディアをグループ化するように指示されなくなります（オプションで、メディアクエリにメディアがすでに存在する場合は、ルールをどこにでも移動できるようにマージします）。どういう意味ですか？

私はそれが良い考えだと思いたくなります（そして実装するのはそれほど難しくありません）

@ media-groupの場合は+1

+1 @ media-group

もう1つのオプションは、true / falseをグループ化するためのグローバルオプションを持つことです。

うーん、これはおそらく良い考えです。 選択的なグループ化が必要になる場合はありますか？

ほとんどの場合、人々はメディアクエリをもっとコンパクトにしたいと思っているので、今のところグローバルオプションが道かもしれません。 選択的なグループ化が必要だと主張する人がいた場合は、後で新しいキーワードを追加できます。

グローバルグループ化オプションの場合は+1。

はい.. @importで、複数のキーワードを追加することは方法ではなく、オプションを追加することはあまり議論の余地がないことがわかったためです。

オプションを追加すると、すぐに役立ち、作成された場合に選択的なインポートを使用してオーバーライドとして共存できるため、追加すると思います。

こんにちは、私はこの問題を見て、メディアクエリをグループ化する必要があるときに作成した小さなアプリを共有したいと思いました。 これは完成したアプリではありません。 将来のツールのためのいくつかの研究のようなものです。 ですから、私はあなたにその考えを示したいと思います。なぜなら、それは本当に実行されなければならないものだと思うからです。 （バグやその他の問題がある可能性があります）が、Twitterブートストラップを含む最後のプロジェクトでテストしましたが、正しく動作します。 （ルールの順序に問題はありません）私に知らせてください;）

http://mqhelper.nokturnalapp.com

こんにちは！

誰かがこれに割り当てられていますか？ これは、少ないファイルで作成したときにcssファイルを減らすのに非常に役立つ可能性がある優れた機能です。 このようにして、開発者はこれらすべての@mqを簡単に操作できるようになります。

@AoDev mqhelperは間違いなく正しい方向への一歩であり、今のところCSS

はい。ただし、私のアプリの目標は、「実際のツール」の一部になることではありません。 ここで多くの人がメディアクエリのグループ化が問題になるのではないかと考え、それが可能であることを示したかったのを見ました。 コードは、アイデアを持ち、その一部を使用したい場合、より少ない開発者のためにあります。 しかし、必要に応じて、これを「実際の」モジュールにすることができます:)

私はすでにそれを管理しました、それは素晴らしい作品です、ありがとう。

@ Soviut @ lukeapage選択的なグループ化が最も理に

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

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

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

こんにちは、メディアクエリのグループ化は本当に素晴らしい追加になるでしょう。 それまでの間、私はこのアイデアを思いつきましたが、プロパティの重複を避けるために、今後の:extend機能で使用できるかどうか疑問に思います。

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

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

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

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

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

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

@AoDevによって作成されたツールは、「オールオアナッシング」アプローチが実際に重要ではないことを示すのに最適です。 メディアクエリのグループ化は、スタイルのグループ化/並べ替えと同じ副作用を受けません。 オールオアナッシングメソッドに欠陥があることを示す実際の例（ @AoDevによって作成されたツールに対してテスト済み）を誰かが提供できますか？

@kamranayubは、私が扱っている正確な状況を完全に説明しました。 個人的には、この実装の何らかの形を見たいと思います。 @DesignByOnyx 、以下のテストコードは@AoDevのツールで正しくコンパイルされません。 私は、kamranayubが述べたようなこの種のスタイリングをしたいと思います。 大規模なサイトで複数の少ないファイルを処理する場合は、はるかにクリーンです。

.footer ul {

  margin: 10px;

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

  li {

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

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

}

使用する構文が少ないため、機能しません。 それは働くことを意味します
CSSを使用します。
2013年7月2日午後9時19分、「PMacom」 [email protected]は次のように書いています。

@kamranayub https://github.com/kamranayubは、正確な説明を完全に説明しました
私が扱っている状況。 個人的には、何らかの形を見たいです
この実装の。 @DesignByOnyx https://github.com/DesignByOnyx 、
以下のテストコードは、 @ AoDevhttps：//github.com/AoDevで正しくコンパイルされません。
道具。 私は、kamranayubが述べたようなこの種のスタイリングをしたいと思います。
大規模なサイトで複数の少ないファイルを処理する場合は、はるかにクリーンです。

.footer ul {

マージン：10px;

@media @ layout-tablet、@ layout-full {
フォントサイズ：13px;
フォントの太さ：太字;
}
@media @ layout-mobile {
フォントサイズ：10px;
パディング-左：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) }

}
}

—
このメールに直接返信するか、Gi tHubhttps：//github.com/less/less.js/issues/950#issuecomment-20369038で表示してください
。

LESSが処理された後、 @ AoDevのツールで使用されるロジックを実行するという提案はありますか？ それが頭のてっぺんから望んでいることではない場合は考えられません。

LESSが処理された後、 @ AoDevのツールで使用されるロジックを実行するという提案はありますか？ それが頭のてっぺんから望んでいることではない場合は考えられません。

これは暫定的なオプションだと思います。 @ AoDevのソリューションをgrunt.jsモジュールでラップして、LESSが処理された後に自動的に実行できるようにすることを検討します（これは、前処理が行われているという前提に基づいています）オンザフライではなく、展開前に実行）

不平を言うタスクは、暫定的には確かに素晴らしく、生のCSSに普遍的に役立ちます。 ただし、 @ media magic LESSがすでに実行している量を考慮すると、グループ化オプションは論理的であるように思われます。

繰り返しになりますが、Gruntタスクは、モバイルスタイルシートをその場でロードしたい人のために、メディアクエリを独自のファイルに完全に分離できる可能性があると述べました。

あなたがそれについて言及したので、スタイルシートを分離することは持っている便利なオプションです-現在、あなたはそれをするためにあなたのソースファイルを特別に構築する必要があるでしょう。

おそらく、メディアクエリをグループ化し、オプションで分割するための個別のメディアクエリオプティマイザーツールの余地がありますか？

絶対。 CSSOがこれをすでに行っているかどうかはわかりません。私が知っている唯一のCSSリライターであり、Gruntタスクも関連付けられています。 ただし、メディアクエリなどを個別のファイルに分割することはできません。 同様に、その書き換えは、DOM構造とは対照的に、同一のセレクターと属性に基づいた非常に基本的なものです。

Mqhelperはすでに個々のメディアクエリを返しますgithubをチェックしてください
詳細については、ページをご覧ください。 分離されたcssファイルはそこから構築できます。
2013年7月5日午前10:08、「Soviut」 [email protected]は次のように書いています。

絶対。 唯一のCSSであるCSSOがすでにこれを行っているかどうかはわかりません
私が知っているリライターには、Gruntタスクも関連付けられています。 それでも
メディアクエリなどを個別のファイルに分割することはできません。 同様に、
その書き換えは非常に基本的であり、同一のセレクターと属性に基づいています。
DOM構造とは対照的です。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/less/less.js/issues/950#issuecomment-20505834で表示してください
。

それほど長くはなく、それほど難しくないもののように聞こえます
（グループ化オプションと個別のファイルオプションの両方）
実装したい私はあなたに助けを与えることができます...

これを実装するために、ある種の「セクション」または「グループ」のアイデアに移行することを思いとどまらせたくありません（それは良いことだと思います）。 ただし、誰かが通常のcss用に定義されているコードで@mediaプロパティ情報を定義する機能を希望しているが、コードの他の場所で単一の@mediaクエリにグループ化されている場合は、 LESS機能で現在実行できる少なくとも2つの方法であり、配置を適切に制御できますが、提案されたソリューションが必要とする以上の追加のコーディングを使用することは確かです（したがって、必ず作業を続けてください）。 検討：

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

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

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

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

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

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

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

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

これはこのcssを生成します：

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

私は次のようなことをしたいと思っていました：

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

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

// end of adapted Gridpak LESS

// Namespaced mixin sets

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

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

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

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

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

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

しかし、グループ化されていない場合、生成されたcssは少しかさばります

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

このhttps://github.com/buildingblocks/grunt-combine-media-queriesには解決策がありますが、現時点では最小幅で注文するだけなので、主にモバイルファーストサイトで役立ちます。

IMO問題をスコープグループ化制御に一般化することは理にかなっています。これにより、問題＃930の解決策が提供されます。

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

素晴らしいツール@krava ！ ありがとう

素晴らしい!!! IMOは、KRAVAの機能をLESSに実装するのが理にかなっています

+1

プラグインとしてやりたいです。 それほど難しくないはずです。 やることが多すぎる！

プラグインは、プラグインを自動ロードするシステム（options.json）よりも優先度を低くする必要があると思います。 しかし、はい、プラグインは付加的な機能として意味があります。

このオプションはまだ実装されていますか？
これにより、コンポーネント内でメディアクエリを使用するため、出力されたcssが半分に削減され、出力段階でグループ化されます。

スレクターの並べ替えに関して、「group」キーワードを使用して何かをグループ化すると、現在の論理フローから削除され、グループ化された領域に配置されることに注意してください。

http://helloanselm.com/2014/web-performance-one-or-thousand-media-queries/
この記事によると、メディアクエリをグループ化する必要はありません。
しかし、プラグインは優れています。

結果のCSSファイルのサイズであるため、パフォーマンスの問題ではありません。 数十の<strong i="5">@media</strong> screen and (max-width: 480px)文字列が、CSSファイルサイズの観点から加算され始めます。

私はSOについてこの質問をしましたが、誰かがこの問題に部分的に答えました。

@ Seven-phases-maxはあなたに答えを与え、彼の答えの中でこの問題に戻って言及しました。 非常にメタ;）

メディアクエリを後処理するのではなく、ミックスイン方式でマージする方が間違いなく好きです。 これにより、入力が簡単になり、何をどのようにマージするかをより細かく制御できます。

ここのコメントで、私がすべてのプロジェクトで使用しているソリューションを見ることができます。
https://github.com/less/less.js/issues/950#issuecomment -17723748

検索を行ったところ、メディアクエリのグループ化を行う2つのgruntプラグインが見つかりました。

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

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

メディアクエリの組み合わせは、 gulpでも利用できます。
http://github.com/konitter/gulp-combine-media-queries

v2以降、プラグインを使用できるため、 https：//github.com/bassjobsen/less-plugin-group-css-media-queries （およびhttps://github.com/bassjobsen/less-plugin-pleeease）を参照して

これはプラグインでサポートされており、コアに移行することは優先されないため、終了します（AFAIK-これが間違っている場合は@ less / adminが正しい）。

@gyopiazza上記のhttps://github.com/less/less.js/issues/950#issuecomment-17723748について質問があり

@nfqこれは完全な初期化ではなく、単に「デフォルト」の空の定義です。 カスタムの.step*()ミックスインを提供しない場合に必要です（つまり、「デフォルト」の.step*()定義など、さまざまなファイルにこれらのものが含まれている可能性があり、それらのレンダリングは一般的なものであると想定されます。ユーティリティ/ライブラリコード、カスタム.step*()定義はテーマ/プロジェクト固有のコードにあります）。

@nfq実際には必要ありません。
@ Seven-phases-maxが述べたように、メディアクエリは存在しないミックスインを呼び出すため、コードでミックスインを使用しない場合にエラーを回避すると便利です。

ところで、この手法の利点は、メディアクエリを組み合わせると、コンパイル時間が（少し）遅くなることです。

@gyopiazza迅速な返信ありがとうございます。 コンパイル時間は気になりません。大規模なプロジェクトの場合は、すべてのメディアクエリをメインのスタイルシートの下部にグループ化することを強くお勧めします。 私はいくつかのプラグインを試しましたが、私たちのユースケースにとって最も簡単で便利な方法を見つけました。 ありがとう！！

@ Seven-phases-maxありがとう、あなたの答えは理にかなっています。 私はあまり使用しませんが、特定のことを達成するための最良の方法をまだ理解していません！

また、clean-cssはv3以降の@mediaマージをサポートしており、 less-plugin-clean-cssもサポートしていることに注意してください。

main.lessで：

header {
    color: green;

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

footer {
    color: green;

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

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

less-plugin-clean-cssは、デフォルトで--skip-advancedをtrueに設定します。 @ mediaのマージには、 advancedオプションを明示的に設定する必要があります。

@nfq 「ミックスインアプローチ」では、メディアクエリは引き続き下部（または宣言した場所）でコンパイルされます。

@gyopiazzaありがとう、ええ。 このアプローチに満足！

@bassjobsen私は間違いなくこれをより大きなプロジェクトで使用します。 私はまだ実際にLessプラグインを使い始めていません。 ヒントをありがとう！