Less.js: ：ミックスインを拡張する

私はそれが好きです、しかしただ明確にするために..これはあなたが前にできなかった何かをすることを許しません、それはあなたが得ることを単に意味します..

.navbar,
.banner {
    // clearfix stuff
}

それよりも

.navbar {
    // clearfix stuff
}
.banner {
    // clearfix stuff
}

または私は誤解しましたか？

パラメトリックミックスインと通常のミックスインの両方が欲しいです

.navbar,
.banner {
    // clearfix stuff
}
.....

また

.clearfix,
.navbar,
.banner {
    // clearfix stuff
}
....

必要なときはいつでも、これがミックスインがすでにどのように機能するかと同じ方法であることを私は知っています。したがって、質問は主に、最適化の観点から最終的なCSS出力をより適切に処理するための柔軟性と方法を持っています。

もちろん

.clearfix,
.navbar,
.banner {
    // clearfix stuff
}

より短い

 .clearfix {
    // clearfix stuff
  }
 .navbar{
    // clearfix stuff
 }
.banner {
    // clearfix stuff
}

そして、重要になる可能性のあるより複雑な例については、この不足のためにSASSに切り替えた人もいることを私は知っています

通常のミックスインは変更できませんでした。 それらはほとんどLessの備品です。 @agatronic 、ええ、私もそう思います。 ただし、これには課題があります。たとえば、パラメトリックミックスインを拡張できるでしょうか。 もしそうなら、それはどのように機能しますか？ これがサポートされていると仮定して、パラメトリックミックスインを2回拡張し、次のように毎回異なる変数を使用するとします。

.transition(@transition) {
  -webkit-transition: @transition;
     -moz-transition: @transition;
       -o-transition: @transition;
          transition: @transition;
}
.navbar {
    &:extend(.transition(opacity .2s linear));
}
.banner {
    &:extend(.transition(opacity .3s linear));
}

私はそれがミックスインの2つのコピーを作成するかもしれないと想像します、それはコードより少なくなく、通常のミックスインに勝る利点はありません：

.navbar {
  -webkit-transition: opacity .2s linear;
     -moz-transition: opacity .2s linear;
       -o-transition: opacity .2s linear;
          transition: opacity .2s linear;
}
.banner {
  -webkit-transition: opacity .3s linear;
     -moz-transition: opacity .3s linear;
       -o-transition: opacity .3s linear;
          transition: opacity .3s linear;
}

ただし、この特定のmixin多く使用する場合がありますので、あなたは再び上のミックスインを使用するときに.dropdownと同じ変数と.banner 、それはこの中になる可能性があります：

.navbar {
  -webkit-transition: opacity .2s linear;
     -moz-transition: opacity .2s linear;
       -o-transition: opacity .2s linear;
          transition: opacity .2s linear;
}
.banner,
.dropdown {
  -webkit-transition: opacity .3s linear;
     -moz-transition: opacity .3s linear;
       -o-transition: opacity .3s linear;
          transition: opacity .3s linear;
}

そして、これが私にとってこれを面白くしている理由です。 他の人からのフィードバックも聞くのは良いことです

@jonschlinkertはい、それはさらに良いイラストです、ありがとう。 私が言ったように、それを両手で！ しかし、それは別のレベルの共犯を追加しているので、慎重に行う必要がある/行わない必要があることを理解してください

参照しているメソッドの拡張は、次のパターンで非常に簡単に実現できます。

.transition(@transition) {
    -webkit-transition: @transition;
     -moz-transition: @transition;
       -o-transition: @transition;
          transition: @transition;
}

.quickOpacity1(){
    .transition(opacity .2s linear);
}

.quickOpacity2(){
    .transition(opacity .3s linear);
}

.navbar{
    .quickOpacity1();
}

.banner,
.dropdown{
    .quickOpacity2();
}

上記は、2つの新しい宣言に半拡張ミックスインを挿入しています。

clearfixの場合、以下の同様のパターンを使用するのも簡単です。これにより、clearfixがクラスとして作成されるだけでなく、それらのclearfixスタイルが新しい宣言に挿入されます。

.clearfix{
  //clearfix stuff
}
.navbar,
.banner {
    .clearfix;
}

@krismeisterこれには混乱があるかもしれないと思います。 説明するパターンは、実際にはネストされたミックスイン、またはミックスイン継承パターンです。 その逆で作業を拡張します。

@jonschlinkertMixinの継承-素晴らしい名前です。 上記の両方の例では、親から出力を継承しようとしているように見えました。これは拡張機能のコア機能です。 あなたはおそらく私の例の出力があなたの期待された出力であったことに同意するでしょう。

ただし、元のコメントを読み直して理解しました。出力を1つのCSSルールに結合する必要があります。 もともと2と書かれていましたが。

実際、 :extendはかなり素晴らしいです。 私は完全なオタクに行くつもりですが、それはすべて「何がどこに移動するか」に帰着します。 「ミックスインのプロパティを、それを使用したセレクターに送信する」ようなミックスインを考えてみてください。 そして、 :extendをその逆、「それを使用したセレクターをミックスイン自体にビームする」と考えてください。 _selectorのプロパティではなく、セレクター自体だけです。 したがって、これを行った場合：

.some-mixin() {
    padding-top: 100px;
    background: #f7f7f7;
}


// a selector that is extending the mixin
.alert:extend( .some-mixin() ) {
    border: 1px solid #e5e5e5;
}
// another selector extending the mixin
section:extend(.some-mixin()) {
    margin: 20px 0;
}

その結果、次のようになります。

// The selectors that extended the mixin are now where the mixin used to be.
.alert,
section {
    padding-top: 100px;
    background: #f7f7f7;
}

// And the properties of the mixin did not get copied down below
// so we saved a line or two of code.
.alert {
    border: 1px solid #e5e5e5;
}
section {
    margin: 20px 0;
}

うまくいけば、それはもっと理にかなっています。 いつでも喜んでお手伝いさせていただきます。

@ agatronic 、 @ matthewdl 、 @ DesignByOnyx 、ちょっと考えて:extend[N]変更することについてどう思いますか。

ミックスインを拡張すると、目にも簡単になると思います。

section:extend[.some-mixin(), .another-mixin()] {
    margin: 20px 0;
}

どちらにしても大丈夫ですが、角かっこについて何かが正しいと感じています。

@jonschlinkert - []は、配列ではなくcssの属性を意味しますが、疑似セレクターへのリンクのために:extend()が選択されたため、通常の角かっこを使用する必要があると強く思います。

良い点、私は同意します。

角かっこは見た目も読みも良いと思いますが、すでに選択した構文に固執する必要があります。

extend（N）構文を高く評価し、@ agatronicと同じ理由で自然のCSSのように感じます

ミックスインを拡張することは悪い考えではありません。 構文例@jonschlinkertについてはよくわかりません。 私はそれが好きではないというわけではありません。 私はあなたが書いたものを実際に理解していません。

つまり、同じミックスインコンテンツを「プルイン」するクラスを定義したいが、結果のCSSでは実際には繰り返さないということだと思います。 私はそれを拡張ミックスインとは呼びません。 つまり、（拡張定義がセレクターに対して行うのと同じ方法で）ミックスイン定義を変更するのではなく、実際に結果のクラスを変更（拡張）します。

だから、私が間違っているなら私を訂正してください、しかしあなたのナビゲーションバー/バナー/ドロップダウンの例は以下によってサポートされません：

.navbar {
  .transition(opacity .2s linear);
}
.banner {
  .transition(opacity .3s linear);
}
.dropdown:extend(.banner) { }

つまり、通常どおりにクラスを拡張しますか？ 私はあなたの使用パターンに頭を悩ませようとしていますが、ミックスインにextendを使用することは、セレクターを拡張するための使用法や命名法と矛盾しているようです。 ミックスインを参照したセレクターを拡張せずに、拡張呼び出しでミックスインを参照する必要がある/必要な理由について、さらに詳しく説明していただけますか？

それが私がそれを得る方法です

必要な最終CSS出力

.sometingShared,
.anotherClass,
.anotherYetClass,
.yetClass {
    // amount of shared code here
}

.anotherClass,
.anotherYetClass {
    // did something dynamic with a
}

.yetClass {
    // did something dynamic with b
}

.anotherClass {
    // native another class code
}

.anotherYetClass {
    // native another yet class code
}

.yetClass {
    // native yet class code
}

必要な出力を取得するために、現在のバージョンのLESSを使用する必要がある方法

.somethingShared,
.anotherClass,
.anotherYetClass,
.yetClass {
    // amount of shared code here
}

.someMixin(@val) {
    // do something dynamic with val
}

.anotherClass,
.anotherYetClass {
    .someMixin(a);
}

.yetClass {
    .someMixin(b);
}

.anotherClass {
    // native another class code
}

.anotherYetClass {
    // native another yet class code
}

.yetClass {
    // native yet class code
}

提案された少ない構文

.somethingShared {
    // amount of shared code here
}

.someMixin(@val) {
    // do something dynamic with val
}

.anotherClass:extend(.sometingShared, .someMixin(a)) {
    // native another class code
}

.anotherYetClass:extend(.sometingShared, .someMixin(a)) {
    // native another yet class code
}

.yetClass:extend(.sometingShared, .someMixin(b)) {
    // native yet class code
}

拡張機能は、共有コードが実際に大量にある場合にのみ役立つ可能性がありますが、それ以外の場合は、通常のミックスインの使用が有利です。

そして、ちょっと遊んでみることを目的としたライブダミーサンプル

http://jsbin.com/opekon/1/edit
http://jsbin.com/opekon/2/edit
http://jsbin.com/opekon/3/edit
http://jsbin.com/opekon/4/edit

すでに述べたように、特定の状況では、私のように怠惰な人にとっては、パフォーマンスが大幅に向上する可能性があります:)柔軟性に影響があるという理由だけで、LESSコードを最適化する

これは、SASSが拡張機能を処理する方法に関するいくつかのことをカバーする拡張機能に関する素晴らしいブログ投稿です。他の人がこれをどのように行ったかから学ぶことはおそらく賢明です。 http://designshack.net/articles/css/semantic-grid-class-naming-with-placeholder-selectors-in-sass-3-2/

特に、ミックスインを拡張するという私の提案は、SASSの「プレースホルダー」と本質的に同じ最終結果を達成すると思いますが、役に立たない余分なプレースホルダーのみのクラスを作成する必要はありません。

編集：はい、ここにプレースホルダーをうまくまとめた別の投稿があります。 それはまさに私がミックスインを拡張することで提案しているものですhttp://maximilianhoffmann.com/article/placeholder-selectors

私は個人的に、他のすべての拡張関連機能よりもこれを好みます。 疑いもなく。 これは強い発言ですが、他の人が同意しない場合、私はそれを説明するのに良い仕事をしていないと思います。 これは非常に強力なものです。

SASSだと思います

 %tile {
  width: 200px;
  height: 200px;
  margin-right: 20px;
}

は、排他的に拡張するために設計されたパラメトリックミックスインと同等ですが、関心の分離という点ではおそらくそれほど悪くはありません。 しかし、ええ、それはCSSであり、可能な限り単純であるとは思われませんか？

@agatronicについて話している間、この拡張https://github.com/agatronic/less.js/blob/master/lib/less/tree/extend.jsは何であると想定されていますか？ それはすでにメインレスブランチにあることに注意してください。 noobの質問は申し訳ありません。

@ dmi3y1.4.0の準備ができたプルリクエストからプルされたextendの最初のバージョンです-これはextendノードを表します

ありがとう@agatronic 、今私は私がどれだけ逃したかわかります;）

@ dmi3yは、引き続き会話に追加してください。結論を導き出すことができるように、この問題をより高いレベルに保つようにしてください。 また、個人的に私に電子メールを送ってください。ミックスインとエクステンドがどのように機能するかについて話し合うことができます（私の連絡先情報は私のプロフィールにあります）。 また、このスレッドでのさらなる混乱を避けるための簡単なコメント。 あなたの例：

%tile {
    width: 200px;
    height: 200px;
    margin-right: 20px;
}

これは、SCSS「プレースホルダー」の構文です。これは、ミックスインの拡張で提案しているものと同様のことを実現するためにSCSS仕様に実装されました。 しかし、これはパラメトリックであることとは何の関係もありません。 パラメトリックミックスインは、単に_パラメーターを受け入れるミックスイン_です。つまり、使用するたびに値が変わる可能性があります。

@matthewdl

つまり、同じミックスインコンテンツを「プルイン」するクラスを定義したいが、結果のCSSでは実際には繰り返さないということだと思います。

と

あなたのナビゲーションバー/バナー/ドロップダウンの例は...によってサポートされていませんか？

いいえ、手術のポイントが失われています、それはまったく逆です。 おそらく、私の例ではパラメトリックミックスインに焦点を合わせるのを間違えたために混乱が生じました。

したがって、最初に、すべてのミックスインがパラメトリックであるとは限らず、多くはパラメーターを受け入れないように作成されていることを説明することが重要だと思います。 clearfixなどの一部のミックスインは、使用時に変数を変更せずに何度も使用されます。 これらは、ミックスインの拡張が有利である理由の完璧なユースケースです。

パラメトリックであろうとなかろうと、すべての栄光のミックスインには、使用するたびにそのプロパティが重複するという欠点があり

あなたの例を考えると、2つの完全に独立した無関係なポイントを作成する必要があります。

1. バナークラスは、拡張されているかどうかに関係なく、コンパイルされたCSSに引き続き表示されますが、バナークラスがミックスインの場合、使用された（拡張または混合された）場合にのみ結果のCSSに表示されます。 これだけでも価値があります。 と
2. 同じ正確なプロパティを何度も複製するのではなく、ミックスインを_拡張する場合、実際のセレクター自体をミックスインの場所にコピーします。

しかし、これはほんの一例です。 Twitter Bootstrapのある時点で、 .clearfix()ミックスインだけが他のセレクター内で20回以上使用され、 .container-fixed() 、 .make-row()などの他の4つまたは5つの構造ミックスイン内にもネストされていたと考えてください。 #grid > .core() 。 つまり、これらのミックスインは、使用されるたびに

これはもっと意味がありますか？ したがって、clearfixミックスインのプロパティを20回以上複製する代わりに、mixin自体の代わりにclearfixミックスインを使用するセレクターをグループ化し、プロパティは1回だけ宣言さ

そして、上記の私の2番目の例は、拡張がパラメトリックミックスインでどのように機能するかに焦点を当てているので、うまくいけば、これで全体像が完成し、今ではもっと意味がありますか？ そうでない場合は、上記にリンクした記事で混乱が解消されるはずです。 ミックスインの拡張は非常に強力で便利であり、ネストされたセレクターを拡張するのと同じ最終結果を達成できますが、ネストされたセレクターの代わりにミックスインを使用します。 これにより、希望する結果を提供する可能性が最も高い方法でセレクターを編成し、意図しない結果を回避できます。 @ DesignByOnyx 、 @ agatronic 、 @ matthewdl 、ここで欠けているものや忘れているものはありますか？ 混乱を解消するために私たちにできることはありますか？

ありがとう。 私はユースケースを理解していると思います、そして私はこの行がそれを最もよく言っていると思います：

バナークラスはミックスインであり、使用された場合（拡張または混合された場合）にのみ結果のCSSに表示されます

それは私には理にかなっています。 おそらく私がハングアップしているのは、全体的な:extend構文がまだ最終的ではないということです。 しかし、あなたは説得力のある主張をします。

セレクターブロックを完成させた後、ミックスインを拡張する動作がセレクターを拡張する動作と一致するようになった場合（主な違いは、先ほど言った行ですが、拡張されたCSSにはセレクターが出力されないということです）最初の使用法がない限り）、それは私には直感的です。

つまり、次のようなこと（または同等の構文）も実行できる場合は、次のようになります。

.facebook-button:extend( .button() all ) {
    border: 1px solid #e5e5e5;
}

...それから私から親指を立てます。 しかし、私にとっては、それはすべて、セレクターの:extendを解決するかどうか/方法/かどうかによって異なります。 しかし、構文はさておき、機能のアイデアとして、あなたは正しいです、それは健全です。

@jonschlinkertありがとうございます、あなたの支持に感謝します、そして確かに私ができる限り明確に私の考えを置くことで最善を尽くします。 将来の開発で何が起こっているのかを聞くのはかなりエキサイティングだと思います。 皆さん、それで素晴らしい仕事をしてください。

はい、この例では、以前の投稿で明示する必要がありました。

%tile {
   width: 200px;
   height: 200px;
   margin-right: 20px;
 }

Jonが提供するSASSチュートリアルから取られており、その主な目的は、使用されないクラスからのCSSの出力を破棄しないようにすることです。 したがって、この特定の角度では、LESSの空のパラメトリックミックスインのように見える可能性があります。 使用したいが終了スタイルシートに出力したくない場合。

私はこの議論に飛びつき、次のコメントについて自分自身に明確さをもたらしたいと思います。

バナークラスがミックスインの場合、使用された（拡張または混合された）場合にのみ、結果のCSSに表示されます。

したがって、より一般的なclearfixの例を使用すると、これはLESSであり、結果のCSSですか？：

.clearfix() {
    &:before,
    &:after { content: " "; display: table; }

    &:after { clear: both; }
}
.something:extend( .clearfix() ) { }

/*
.clearfix:before,
.clearfix:after,
.something:before,
.something:after {
    content: " ";
    display: table;
}
.clearfix:after,
.something:after {
    clear: both;
}
*/

私は当初、 .clearfixクラスがコンパイルされたCSSから省略されたままになることを期待していました。 個人的には、コンパイルされたCSSでクラスを「必要」とはしません。マークアップで使用せず、CSSで余分なバイトを使用するからです。 どちらにしても強い意見はありませんが、この点を明確にすることで、今後のコメントを増やすことができます。 ありがとう。

これは...結果のCSSですか？：

私はあなたが求めている嬉しいんだけど、いや、唯一の.somethingクラスは、得られたCSSに表示されます。 ですから、あなたは当初の期待に正しかったのです。

プレースホルダーのリンクを読んでください。そうです、ミックスインを拡張する方が、物事を実行して同じ機能を取得するためのより良い方法であり、より少ない方法だと思います。

あなたの上記の点を冷やすために

.clearfix() {
    &:before,
    &:after { content: " "; display: table; }
    &:after { clear: both; }
}
.something:extend( .clearfix() ) { }

/*
.something:before,
.something:after {
    content: " ";
    display: table;
}
.something:after {
    clear: both;
}
*/

おそらく、 .clearfix() {定義が.clearfix {場合、拡張定義内で角かっこを付けて、または付けずに呼び出しても、出力に違いはありません。

拡張機能に疑似クラス構文を使用することは完全に間違っています。
「extendsth」は「matchsth」と等しくないため、セレクターがすべきDOM構造については何の意味もありません。

あなたは少ない人が多くの悪い考えを「発明」しました。 最も有名なのは、ミックスイン表記としての「reuse」.xxx（クラスセレクター）です。少なくとも、プレーンCSSからプリプロセッサへの移行が容易になります。しかし、：extend構文は私が聞いた中で最悪のアイデアです。

私たちの問題についてこの種の暴言を威厳を持たせたくはありませんが、これらのことを聞いたのはこれが初めてではないので、CSSについて話して空気をきれいにしましょう。

あなたは少ない人が多くの悪い考えを「発明」しました。 最も有名なものは、ミックスイン表記としての「再利用」.xxx（クラスセレクター）です。....：extend構文は私が今まで聞いた中で最悪のアイデアです。

.xxxは暗黙的なミックスインと呼ばれます。 それは機能し、理解しやすいです。 実際、この構文は、CSS仕様では、たとえば、実際のスタイル設定にat-rulesを使用するほど「侵襲的」ではありません。 @keyframesは、スタイリングとして説明されるものに最も近く、CSS構文での識別子の生成に一致する識別子が使用されるため、私が言っていることの例外と見なされる可能性があります。 キーフレームを超えて、一般にCSS at-rulesは、主に高レベルの構成と、文字エンコード（ @charset ）などのスタイル自体の外部を意味する「外部」情報に基づくスタイルまたはスタイルシートの操作のために予約されています。デバイス固有の条件に応答する（ @media ）。

その上、私はもっと悪い考えを考えることができます。 スタイリングにat-rulesを使用するのと同様に、同じ機能に2つのat-rulesを使用するのも別の方法です。 もちろん、それはすべてあなたの目標に依存します。個人的にスタイルに触れずにプログラムでスタイルを操作したい場合は、パーサーが理解しやすい、より鈍くて明白な文法構造を使用することにはおそらく利点があります。 Stylusを使用しているように見えるので、他の構文が有利である理由についてのあなたの見解を聞いてみたいと思います。

「extendsth」は「matchsth」と同じではありません。セレクターがすべきDOM構造については何も意味しません。

正しい。 nth _something_を持つ疑似クラスは、CSS仕様では「構造的」疑似クラスとして記述されています。 ただし、疑似クラスには、「動的」、「否定」、「ターゲット」、「空白」、「UI要素の状態」、「言語」の6種類があります。 CSS仕様が実際に「拡張」機能を記述している場合、それは「否定」と「ターゲット」の疑似クラスの間のカテゴリとして非常にエレガントに位置する可能性があります。

疑似クラスでは、ドキュメントツリーの情報に基づいて選択できますが、これは拡張機能の最適な使用法ではない可能性があります。

完全に間違っている

他のすべてのプリプロセッサを組み合わせたものよりも大きいコミュニティは間違いありません。 他に何を言うことがありますか？

@hax - :extendスレッドで他のみんなと同じように独自のソリューションを提案した場合、マインドレストローリングは知識に基づいた議論に変わる可能性があります。 経験豊富なフロントエンド開発者とLESSのヘビーユーザーの間で何週間にもわたるさまざまな提案と審議を経て、 :extend構文で満足のいく解決策にたどり着きました。 より良い提案があれば、私を信じてください-私たちは皆耳です。

@jonschlinkertに追加するには、 .this:not(.that) { }と.this:matches(.that) { }と.this:extend(.that) { }はカテゴリ的に類似しています。 つまり、「セレクター 'this'を指定し、それをセレクター 'that'に特定の方法で関連付けます。」 LESSは、CSSで導入された概念と構文を拡張することが多いため、言語のかなり論理的な拡張です。 私たちはCSS仕様に細心の注意を払い、その結果、その特異性を反映しています。 概念に奇妙な点がある場合は、CSSから始めることをお勧めします。 そのため、ミックスインガ​​ードでは、「AND」は「and」という単語で表され、「OR」はコンマで表されます。これは、メディアクエリでの方法だからです。 私たちの目標は、CSSを修正または変更することではなく、CSSの操作をはるかに簡単にし、CSS作成者にとってLESSを完全に馴染みのあるものにすることです。 :extendはその一例です。 :not使用方法を知っている場合は、 :extend使用方法を知っています。

これにもっと「暗黙の」構文を使用して、親のネストを回避し、パラメトリックミックスインの拡張を容易にした場合はどうなるでしょうか。

今日、私たちは次のようなパラメトリックミックスインを使用しています。

.square {
  .border-radius(9px);
}

このようにミックスインを拡張するのではなく（通常のクラスを拡張する可能性があるため）：

.square {
  &:extend(.border-radius);
}

このように拡張できます：

.box {
  .border-radius:extend(9px);
}
.square {
  .border-radius:extend(9px);
}
.rectangle {
  .border-radius:extend(4px);
}

区別がセミコロンで「拡張されたミックスイン」は終了ということであると、括弧内の値または値を宣言します.border-radius:extend(9px); 、むしろ括弧内拡張するクラスを一覧表示し、中括弧で新しいセレクタブロックを開始するよりも、 .border-radius:extend(.some-class) {} 。 IMHO、これは暗黙のミックスイン（ .border-radius; ）と同じくらい微妙です。これは、LESSの最もクールな機能の1つであり、やはりIMHOです。

レンダリングされた出力では、「拡張パラメトリックミックスイン」は、次のように元のミックスインの場所にレンダリングされます。

.box, 
.square {
    -webkit-border-radius: 9px;
    -moz-border-radius: 9px;
    border-radius: 9px;
}
.rectangle {
    -webkit-border-radius: 4px;
    -moz-border-radius: 4px;
    border-radius: 4px;
}
.some-other-class, 
.another-class, 
.and-another {
    -webkit-border-radius: 2px;
    -moz-border-radius: 2px;
    border-radius: 2px;
}

だから私は個人的にこれが好きです。なぜなら、セレクターブロック内の「通常の」拡張構文から十分に逸脱して、何が起こっているのかを十分に明らかにし、何を説明しすぎる必要がない既存のより少ない規則の微妙さを伴うからです。あなたはコードで達成しようとしています。 この機能は間違いなく私の個人的なウィッシュリストの一番上にあります。

元のリクエストで指定したclearfixの例を使用すると、次のようになります。改訂された構文では次のようになります。

.clearfix() {
    // ...
}
.navbar {
    .clearfix:extend(); // instead of &:extend(.clearfix());
}
.banner {
    .clearfix:extend();
    &:extend(.some-class); // "implicit mixin" being extended
}

私はあなたがこれで行くところが好きです。 よりフレンドリーなアプローチは、次のように_existing_mixin構文の最後に:extendを使用することだと思います。

.box {
  .border-radius(9px):extend;
}
.square {
  .border-radius(9px):extend;
}
.rectangle {
  .border-radius(4px):extend;
}

:extend後に親を省略することについての何かは、それが既存の拡張構文とは異なる目的を果たしているように感じる場合に役立ちます。

私はこれで何でもできますが、拡張構文と一貫しているので.border-radius:extend(9px);を好みます、IMOはそれがミックスインであることは明らかですが、パラメーター/値が拡張されていることも意味します-これは説明に役立ちます出力が「グループ化」される理由。

@ jonschlinkert-この時点で、私はあなたの意見を非常に高く評価し、あなたが最善だと思う決定をサポートします。 あなたのメソッドは、ミックスイン自体に渡されるのではなく、9pxが「拡張」に渡されているように感じます...しかし、私はどちらでもかっこいいです。

@DesignByOnyx親切な言葉をありがとう。 あなたが言っていることは非常に理にかなっています、私の「レンズ」の拡張（Less）は次のようなものでした：

.this:extend(.that) {}

ですから、あなたの主張は私自身の見解と一致しています。 @matthewdlまたは@lukeapageどちらかがこれについて何か意見/意見を持っていますか？ 両方の構文が機能する可能性があると思いますが（おそらく他の構文も）、確かにどちらの構文でも「将来の保証」に焦点を当てていなかったため、どちらかでいくつかの落とし穴がある可能性があります。 これが起こるのを楽しみにしています。ミックスインの拡張はLessにとってエキサイティングな機能だと思います。現時点で考えられる他のどの機能よりも、DRYコードの生成に多くの効果があります。

なぜLessコンパイラは自動的に「正しいことをする」ことができないのですか？ 言い換えると、このミックスインをコードで宣言している場合：

.someMixin {
    color: red;
}

そして後で私はそれを次のように使用します：

#someElement {
    .someMixin;
}

コンパイラがこのLessコードをこのCSSに最適化するのに十分賢くないのはなぜですか？

.someMixin,
#someElement
{
    color:red;
}

この動作を実現するために、ユーザーとして：extendsキーワードを手動で追加する必要があるのはなぜですか？ コンパイラーは、この最適化を実行できることを認識して実行できるほど賢くなければなりません。

個人的には、これは：extendsのアイデアが混乱していると思います。 「extends」キーワードの概念全体は、「これをXにして、A、B、およびCを追加する」ことを意味します。 しかし、この文脈では、拡張を再定義することを提案します。「このことXは実際にはYと同じなので、YとXが等しいと宣言して、一度書くだけです。」 これは、何かを「拡張する」という標準的な概念に反します。

ええ、私は以前に同じことを考えていて、それを投稿するつもりでしたが、それを考えた後、ミックスインに「拡張動作」を自動的に適用することは、Less.jsにはあまりにも意見が多いと判断しました。 具体的には、セレクターの継承（拡張）はコードの削減に非常に有益な素晴らしい概念ですが、この機能について私が読んだ不満の大部分は、コードをくまなく調べることを困難にする抽象化レイヤーを追加することです問題がある場合はデバッグします。

素晴らしい心は同じように考えますが、私は個人的にこのアイデアに反対票を投じます。なぜなら、a） extend機能が完全に安定し、仕様がより完全になるまで、「通常の」ミックスインをいじってはいけないからです。b）多くの開発者が自分でこの呼びかけをしたいと思っていると思います。c）問題の事実があなたを作るミックスインについての多くの風変わりなことを忘れているということであるとき、物事はしばしばとても明白でカットアンドドライに見えます提案は少なくとも実装するのが難しく、おそらく開発者が私たちが持っているすべての「ミックスインハック」を使用できるようにしながら実装することは不可能です...ええと、彼らは知り、愛するようになりました。

：extends（）構文はまだかなり不器用なハックであり、直感的ではなく、新しいユーザーに説明するのが困難です。

より良い解決策は、ユーザーが適切な出力スタイル（圧縮、最適化など）を選択したときに、上記のようにコンパイラーにCSSを自動的に最適化させることです。 ユーザーが非圧縮出力スタイルを選択した場合、コンパイラーはこれらの最適化を回避し、生成するDRYコードを少なくする必要があります。

さらに、ソースマップを使用してデバッグの問題を解決できます。 彼らは、Lessミックスインから来るコンパイルされたCSSの場所を簡単に指摘することができます。

@bdkjonesは、コードでこれを実現する方法についての提案とともに、「CSSを自動的に最適化する」ための新しい機能リクエストを作成してください。 この種の入力はいつでも歓迎です。

ポイントを取った！ 私は最後のコメントでそれほど厳しいことを意味していませんでした。 私は時々夢中になります。

コードに関しては、CodeKitで忙しいのではないかと思います。 私はあなたたちに言語をハッシュさせます！

全くない！ 本当に、あなたがCodeKitに関与しているのを見ました、あなたの継続的なインプットを望んでいます。 すべての機能がすべての人を満足させるわけではありませんが、フィードバックと強い意見だけが車輪を回し続けます！

@bdkjones問題はカスケードです。 ユースケースでは機能しますが、セレクターのグループ化は、すべての場合に望ましい結果をもたらすとは限りません。これは、セレクターをドキュメント内の「前」に移動して、それらのセレクターを上書きする宣言を防ぐ可能性があるためです。

しかし、ここで進化したミックスイン拡張構文に対するあなたの声明に同意します。 セレクターXはセレクターまたはミックスインYを拡張する必要があるため、これは奇妙に思えます。

.border-radius(9px):extend;

拡張構文を誤用していると思います。 存在する拡張構文がミックスインに適合しない場合（これは完全にもっともらしいです）、 @ bdkjonesが指摘するように、メタファーを混乱させる方法で拡張構文を拡張するのではなく、ミックスインに適切な構文を見つけることをお勧めしますアウト。

拡張構文を誤用していると思います

同意しません。 動作する場合は、それを使用してください。 理由もなく新しい構文を作成するのはなぜですか？ 提案された構文には素晴らしい前例があると思います。提案の背後にある豊富な例と裏付けとなる理由を示しますが、提案された構文についてのあなたの意見は非常に主観的なようです。 そして、最近その声明を数回行ったので、構文が乱用されていると思う理由を説明できますか？ または、構文が悪用されているのはどの時点であるかを説明しますか？ または、「extend」構文を使用せずに、ミックスインを拡張する方法についての考えを共有しますか？

ユースケースでは機能しますが、セレクターのグループ化は、すべての場合に望ましい結果をもたらすとは限りません。これは、セレクターをドキュメント内の「前」に移動して、それらのセレクターを上書きする宣言を防ぐ可能性があるためです。
..。
拡張構文を誤用していると思います。 存在する拡張構文がミックスインに適合しない場合（これは完全にもっともらしいです）、bdkjonesが指摘しているように、メタファーを混乱させる方法で拡張構文を拡張するのではなく、ミックスインの正しい構文を見つけることをお勧めします。

いいえ。彼は何も指摘しませんでした。彼は私たちに、使いやすさを減らすように促しました。それが彼の収益でした。 彼が提案した方法は間違っていましたが、意図は良かったです。 彼が考えていなかったのは、あなたが今指摘したカスケードです。 一般にextendを使用する場合は、カスケードを考慮する必要があります。 ミックスインの代わりにextendを使用する人は誰でもそれを知っていると思います。 したがって、Less.jsでは、意味がある場合に使用するか、意味がない場合に使用しないかを選択できます。 CSSの最初の「C」がカスケードを表すという事実は、カスケードが重要でない場合に重複するスタイルを統合する利点を否定するものではありません。 ここで何が欠けていますか？

それで、あなたはあなたの感情を明確にすることができますか？ この機能、または構文に反対ですか？ 構文に反対している場合は、物事を動かし続けるために何か他のものを提案してください。そうでない場合は、この言語にとって有望な機能の進行を妨げないようにしてください。

この機能、または構文に反対ですか？

私は絶対にその機能に賛成です。 これは明らかな方向です。 このスレッドで構文を再度確認しました。 いくつかの考え：

まず、これは私にとって厄介です：

.something:extend( .clearfix() ) { }

二重括弧は奇妙です。 しかし、これは既存の拡張構文を忠実に採用しているため、十分に公平です。 だから、私は何か他のもの、おそらく拡張以外のものを提唱していたのです。

それからあなたが提案したこれがあります、私は同様の理由で考えます：

.border-radius(9px):extend;

...既存の拡張仕様に反しているように見えるので、アレルギー反応がありました。 だから、それは私には誤用のように思えたところです。

しかし

実際には2つの選択肢があることに気づきました。 1つは、ミックスインに対して別のことを行うことです。 しかし、他のオプションは、次のようなミックスインを含むすべてのものについて、既存の拡張仕様を改訂することです。

#namespace {
  .box-template {
    .subelement {
      // we'll add the all flag to extend everything here
    }
  }
}
.clearfix() {
  // a clearfix mixin
}
.text-shadow(@shadow) {
  -moz-text-shadow: @shadow;
  text-shadow: @shadow;
}
.some .random .selector {
  // with properties
}
.mybox {
  .clearfix:extend;
  #namespace > .box-template:extend !all;
  .text-shadow:extend(2px 2px #ff0000);
  .some .random .selector:extend;
}

しかし....完全なセレクター（ .some .random .selector ）を使用すると、読み取りが間違ってしまいます。 .selectorだけに拡張子が付いているようです。 そして、「拡張する」という言葉は、この宣言の重要な言葉であるときに失われ始めます。 &:extend()書かれたときはそうではありません

だから、私はこれらのオプションの1つを提案します：

// Migrating existing syntax, but ommitting a parens requirement when used with &:

.mybox {
  &:extend .clearfix;
  &:extend #namespace > .box-template !all;
  &:extend .text-shadow(2px 2px #ff0000);
  &:extend .some .random .selector;
}

// Adopting something similar to the SASS approach

.mybox {
  <strong i="24">@extend</strong> .clearfix;
  <strong i="25">@extend</strong> #namespace > .box-template !all;
  <strong i="26">@extend</strong> .text-shadow(2px 2px #ff0000);
  <strong i="27">@extend</strong> .some .random .selector;
}

ミックスインとメディアクエリの拡張に関する議論は、特に複数のセレクターとミックスインを拡張したい場合、 :extendへの元の構文アプローチはそれほど柔軟ではないことを強調したと思います。

：extendを正しく取得することが重要だと思います。 ミックスインに「extend」を使用したい場合は、extend構文を修正する必要があると思います。

私は.border-radius(9px):extend;提案しません@ DesignByOnyxは.border-radius:extend(9px);を提案しました

しかし、どちらの構文でも問題ありません。 または、 .border-radius(9px) !extend;または.border-radius:shamallamadingdongscoobiedoo(9px):extendmyass （jk）を実行することもできますが、ミックスインの動作によって何も変わらないか、まったく拡張されないため、私には関係ありません。

だから、あなたがそれらすべてを行う必要性をどのように思いついているのかわかりません、あなたはおそらくあなた自身のために物事を過度に複雑にしているでしょう。

この機能要求はmixin_の代わり_toミックスインの継承されたプロパティをコピーする機能を持っていることについて明示的であり、それはすでによく、現在のミックスインの振る舞いで確立されたルールに従って、今もして優先順位と同じ振る舞いを持っています<strong i="14">@import</strong> (reference)機能（ところで、私は実際にかなり使用していて、大好きです）。 一言で言えば：

• ミックスインを使用すると、そのプロパティがミックスインを呼び出すセレクターの場所にコピーされます。
• extendを使用すると、_extending_セレクターが_extended_クラスの場所にコピーされます。
• したがって、ミックスインを拡張すると、呼び出し側セレクターがミックスインの場所にコピーされます。

2年間の討論、100を超える投稿、多くの調査の後で、構文に関する討論を再ハッシュして延長したい理由がわかりません。すでに、 @extendよりもはるかに柔軟であるというケースがあります。

ところで、私はあなたがここで何を意味するのかわかりません：

完全なセレクター（.some .random .selector）を使用すると、誤った読み取りを開始します。 .selectorだけに拡張子が付いているようです。 そして、「拡張する」という言葉は、この宣言の重要な言葉であるときに失われ始めます。

それが現在実際に機能しているので、私はそれが混乱していることに同意しません。 「CSS開発者はグループ化されたセレクターがどのように機能するのかわからない」と言っているようなものではありませんか？ :hoverまたは:afterどうですか？ CSS開発者は、他のpseduosと同じように機能するため、これをうまく理解できると思います。

.some .random .selector:extend(.something) {}

.some .random .selectorではなく.selector .some .random .selectorであるセレクターに拡張を適用するか、セレクターブロック内に押し込むことができるので、これがもたらす柔軟性が気に入っています。

ミックスインとメディアクエリの拡張に関する議論は

ミックスインを拡張することで解決できることに気付いたので、メディアクエリの問題を閉じました。 「すべての道は_____に通じています」ミックスインを拡張します。 ;-)

特に:extend( .some-selector )がすでに確立されており、悪意を持って議論されているため、2セントを投入して、parens内のparens（ :extend( .some-mixin() ) ）はそれほど気になりません。 私は、二重の親が決して理想的ではなく、それがちょっと奇妙に感じることに同意します。 しかし、ミックスインとセレクターを「拡張」に関して同じように扱うことが重要だと思います。これは、従来のLessで同じように扱われるのとほぼ同じです。

header {
    .some-selector;
    .some-mixin;
    .some-mixin();
}

このように、私はこれを行うことによって実際にそれほど悪く（または制限されている）とは感じません：

header {
    &:extend( .some-selector );
    &:extend( .some-mixin );
    &:extend( .some-mixin() );
}

しかし、ミックスインとセレクターを「拡張」に関して同じように扱うことが重要だと感じています。これは、従来のLessで同じように扱われるのとほぼ同じです。

私はその点で同じページにいます。

2年間の討論の後、100を超える投稿を延長するために、構文に関する討論を再ハッシュしたい理由がわかりません。

それはしたいという問題ではありません。 いいえ、したくありません。 しかし、当時は、後で処理するためにミックスインをシャッフルしました。 この構文がすべてに対して機能するように機能するかどうかを確認したいだけです。 質問が機能しない、または一部の用途ではエレガントでないと感じた場合は、質問を再検討しても問題はありません。 LESSは長い間存在し続けてきました。 迅速に行うよりも、正しく行うことが重要です。

だから、私たちはこれでクールですか？

.mybox {
  &:extend(.clearfix());
  &:extend(#namespace > .box-template all);
  &:extend(.text-shadow(2px 2px #ff0000));
  &:extend(.some .random .selector);
}

parens内のparens-：extend（.some-mixin（））-特に：extend（.some-selector）がすでに確立されているので、それほど気になりません

はい、そうです。実際、Less.jsでも、既存の拡張構文を使用したダブルペアレンの前例がすでにあります。 そして、すでに設定されている先例は、私たちがミックスインで提案しているものほど目には簡単ではありません。 現在、これを行うことができます：

.one:nth-child(5) {
  color: red;
}
// We can extend psuedos
.two:extend(.one:nth-child(5)) {
  background: blue;
}
// And attributes
.two:extend(.one, [hidden]) {
  width: 2px;
}

既存のCSS構文にもネストされた親があり

したがって、ここには_nestedparens_と_nestedpseudo-class_の両方の構文があります。 そして、私はそれで問題はありません、それは明らかなIMOです。

だから私は@DesignByOnyxに同意し

実際、元の構文では、複数のコンマ区切りのクラスまたはミックスインを拡張できます。

.banner {
    &:extend(.clearfix(), .border-radius(4px), .alert, .navbar-fixed-top, [hidden]); 
}

それは仕事をします、そしてそれはきついです。 ここに不満はありません。

だから、私たちはこれでクールですか？

うん。 完全に。 それはすでにCSSのやり方です。 だから私はそれでいいです。

うん。 完全に。 それはすでにCSSのやり方です。 だから私はそれでいいです。

だから、それは合格するようになるでしょう。

質問、現在：extendで複数のセレクターがサポートされているとは思わないので、「all」キーワードがその形式のどこに収まるのか疑問に思いますが、それはおそらく別の問題の一部であるはずです。

シュリンケルトさん、あなたはあなたの主張をしました。 あなたは法律を制定すべきだった。 ;）

現在、：extendで複数のセレクターをサポートしているとは思いません。

しかし、私たちはそうします;-)私はそれを広範囲に行いました。 ちょうど以前にこれをしました：

.global-nav {
  // Extend and override bootstrap styles
  &:extend(.navbar, .navbar-fixed-top all, .navbar-inverse); // this works, and it's pretty handy
  &.hidden:extend(.navbar.hidden) {}
  &.visible:extend(.navbar.visible) {}
  &:hover {
    background: lighten(@brand-primary, 5%);
  }
  .navbar-brand {
    padding-left: 20px; 
  }
  .navbar-nav > .active > a {
    &, &:hover, &:focus {
      background-color: darken(@brand-primary, 5%);      
    }
  }
}

シュリンケルトさん、あなたはあなたの主張をしました。 あなたは法律を制定すべきだった。 ;）

Pfft、笑ああやめて！

私はこの構文だと思うことを追加したいだけです：

.foo {
  &:extend( .bar() );
}

素晴らしいです。 かっこが気まずい感じはまったくありません。

しかし、主に私はあなたたちに急いでもらいたいので、私がお気に入りのプリプロセッサでSASSで取り組んでいるすべてのクールなことを行うことができます：D

フィードバックをありがとう、 @ mgerring ！

+1この機能を待っています。 良い仕事を続けてください:)

元の投稿へ：

.clearfixed {
   // stuff
}
.clearfix() {
    &:extend(.clearfixed);
}
.navbar {
  .clearfix();
}
.banner {
  .clearfix();
}

たぶんこれは投稿時に機能しませんでしたか？ しかし、それはあなたが望んでいたものに非常に近い何かをもたらします：

.clearfixed,
.navbar,
.banner {
  // stuff
}

@aaronmw 、はい、確かにあなたの例は同じですが、この提案の重要なポイントは、他の場所で定義されたミックスインを拡張する機能です（つまり、ミックスイン自体を変更できない、または変更したくない場合、たとえば他のファイル、共有ライブラリなど）

ええ、@ Seven-phases-maxのポイントによれば、これはあなたが説明する方法で行うことができますが、慣用的ではありません。

そうです—申し訳ありませんが、私は今このスレッドをもっと読み、私たちが何を目指しているのかを見てきました。 私が使用した「スケルトン」クラスは、.clearfixedクラスがミックスインの外部で明示的に参照されることは決してないため、コンパイルされた出力では単なるゴミです。 ＆：extend（.clearfix（））は今では意味があり、とてもエキサイティングです。 今のところ、CSSを散らかしているスケルトンクラスを扱います。

ここで素晴らしい議論！

：+1：

では、いつこの機能を期待できるのでしょうか。 OOCSSのような概念では、「抽象クラス」のような構造を作成すると非常に便利です。

• ネスティング/スコープおよびミックスインと通常のクラスにどのように対処するかを決定します。

.a {
  color: green;
}
#thing {
  .a() {
    color: black;
   }
}

.b:extend(#thing .a) {}  //
.b:extend(.a) {}  // and if so is the output wrapped by #thing?
.b:extend(.a()) {}  // do I need special format to say extend only that mixin?

• 引数を処理しますか？ ミックスインを同じ引数と組み合わせますか？
• ミックスイン定義を削除しないようにto-css-visitorに変更します
• 拡張ビジターにミックスイン定義にアクセスしてもらい、新しいクラスで新しいルールセットを作成します

最も難しいのは、実際にどのように機能するかを_正確に_決定することだと思います。

ネスティング/スコープおよびミックスインと通常のクラスにどのように対処するかを決定します。

私はミックスイン拡張を次のように解釈しようとします：
.b:extend(.a(1, 2, 3)) {}は、内部で.a(1, 2, 3)を呼び出し、通常の方法で拡張する「b」のスコープ内に匿名のノンパラメトリックミックスイン（つまり単純なセレクター）を作成するのと同じように動作する必要があります。

.a(<strong i="11">@a</strong>, <strong i="12">@b</strong>, @c) {
    // ...
}

.b:extend(.a(1, 2, 3)) {}

これと等しくなければなりません：

.a(<strong i="16">@a</strong>, <strong i="17">@b</strong>, @c) {
    // ...
}

#__anon_a_1_2_3 {.a(1, 2, 3);}

.b:extend(#__anon_a_1_2_3) {}

＃__ anon_a_1_2_3が出力に表示されないことを除いて。 そのようなアプローチは、特別なルールを発明することなく、多かれ少なかれ簡単になるはずだと思います。

したがって、上記の概念を#thing .a例に適用すると、次のようになります。

.a {
  color: green;
}
#thing {
  .a() {
    color: black;
   }
}

.b:extend(#thing .a) {} // since we do ignore parens on mixin call and have ...
// no plans changing this (?), it should probably create .b {color: black} 

.b:extend(.a) {}  // there's only one .a in this scope so it's -> .b {color: green}

.b:extend(.a()) {}  // same as above -> .b {color: green}

一方、「オプションのパレン」は実用的な観点からは非常にマイナーなものであるため、より厳密にして、 extend内のパラメトリックミックスインにパレンを要求することもできます（圧力はかかりません）。 extend 、とにかく完全に互換性がないため、プレーンなミックスイン呼び出し構文を継承します）。

ミックスインを同じ引数と組み合わせますか？

理想的にはそうです。そうでないと、全体が役に立たなくなります。例：

.b:extend(.a()) {}
.c:extend(.a()) {}

作成する必要があります：

.b, .c {color: green}

うーん、マージは実装するのが最も難しいようです。

もう1つの問題はスコープです。最近＃1730で発生したように、ミックスインは「相対」スコープパスを使用し、拡張は「絶対」を使用するため、両方を組み合わせると一種の競合が発生します。

.div {color: green}

body {
   .div {color: red}

   p-a       {.div()}    // -> body p-a {color: red}
   p-b:extend(.div)   {} // -> body p-b {color: green}
   p-c:extend(.div()) {} // -> ???
}

そして、この例をパラメトリックミックスインで書き直すと、さらに混乱します。

私は2セントを提供して、今は一歩下がって「拡張ミックスインをどのように使用すべきか」と言うのに良い時期かもしれないと言いたいです-そして

.dog() {
    .leg { ... }
    .ears { ... }
    .fur { ... }
}

ユーザーが次のことをしたいと思う状況に焦点を当てるべきではないと思います。

.dog() {
    .leg { ... }
    .ears { ... }
    .fur { ... }
    .tail:extend( .leg() ) { 
        .toes { display:none; } 
    }
}

これはフリンジケースシナリオIMOであるだけでなく、ユーザーはとにかく次のようなスタイルを作成する必要があります。

.dog() {
    .leg, .tail { ... }
    .ears { ... }
    .fur { ... }
    .tail .toes { display:none; }
}

ミックスインを拡張するための99.8％のユースケースは、開発者が長年にわたって蓄積したスタイルでいっぱいの大規模なLESSライブラリを使用できるようにすることです。 この大規模なライブラリには、次のようなものがたくさんあります。

.clearfix() { ... }
.modal() { ... }
.alert-box() { 
    &:extend( .modal() ); 
    &.message { ... } 
    &.warning { ... } 
    &.error { ... } 
}
.grid-wrap() { ... }
.form-input() { ... }
.form-select() { ... }
.button( <strong i="16">@bgColor</strong>, <strong i="17">@textColor</strong> ) { ... }
[... thousands more like this ...]

そして、彼らはスタイルを書くことに集中することができます：

.page-wrap:extend( .grid-wrap(), .clearfix() ) { ... }
input[type="text"]:extend( .form-input ) { ... }
textarea:extend( .form-input() );

必要に応じてこれを行うこともできますが、このプロジェクトでは使用されていないため、「モーダル」スタイルは最終出力に表示されません。

.inline-error:extend( .alert-box.error )

ええ、 @ DesignByOnyxには

@DesignByOnyxと@calvinjuarezは、理解することはできません。

フリンジシナリオをサポートしないアプローチを考え出すことができれば、私はとても幸せです。それは、メインの拡張サポートでやったことのようなものです（必要に応じて、より多くのキーワードで拡張できます）。しかし、何がどのようにサポートされるかについての計画が必要です。

上記の静脈の@ seven-phases-max、私は今のところパラメトリックミックスインを無視して幸せです。

うーん、マージは実装するのが最も難しいようです。

• しかし、それはマージされていますか？ 既存のエクステンドと同じアプローチを使用します。たとえば、一致するものを見つけてそれに追加します。したがって、両方のエクステンドを3番目の場所であるミックスインに配置するほどマージされません。これは、特別なものとして出力されます。そのgenCSSのケース

また、@ seven-phases-maxのスコープに対する2番目の例は、誰かに影響を与える可能性が非常に高いと思います。同じ名前のミックスインと空のパラメトリックミックスインが必要です。

@lukeapage ：+1：

実際、@ seven-phases-maxはそれを正しく行っていると思います。 だから：+1：そこにも。

@ lukeapage-私は「:extendは次のように機能するため、「ローカル」スコープの機能をすでに超えており、「遅すぎて戻る」フェーズIMOに入りました。

.block { color: green; }

.component {
  .block { color: red; }    
  div:extend( .block ) {};
}

/*
.block,
.component div {
  color: green;
}
.component .block {
  color: red;
}
*/

次のコードが上記と異なる動作をする理由はわかりません。最終的な出力に.blockクラスがないという利点があります。

.block() { color: green; }

.component {
  .block() { color: red; }  
  div:extend( .block() ) { };
}

/*
.component div {
  color: green;
}
*/

ところで、命名規則にはわずかなずれがあります:)たとえば、私にとって「パラメトリックミックスイン」とは、パラメーターが0のミックスインを含む、パラメーターで定義されたミックスインを意味します（つまり、 .mixin() {}は「パラメトリック」ミックスインです）。 また、「ノンパラメトリック」ミックスインは単純なセレクターです（つまり、 .mixin {} ）。 これまでのところ、このドリフトは誤解を生まなかったと思います（たとえば、上記のほとんどの例では、 .mixin() {}が「ノンパラメトリック」ミックスインと呼ばれるかどうかはコンテキストから明らか
ドキュメントでは、単純なセレクターも「ミックスイン」と名付けられており（ミックスインされるとすぐに）、設計上「ノンパラメトリック」ミックスインでもあることをお見逃しなく。 したがって、「ノンパラメトリック」についてのみ.mixin() {}を参照することは、かなりあいまいな場合があります（技術的には、引数の数ではなく、定義括弧の有無に違いがあります）。
OK、これは私のいつものブーブーブーでした。 :)

@lukeapage

今のところ、パラメトリックミックスインを無視してよかったと思います。

つまり、ゼロ以外のパラメータを持つミックスインの拡張をサポートしていませんか？ 私はそれで大丈夫です。 私はそれがどのように実装されるかを推定しようとしていました（ゼロとゼロ以外のパラメーターのミックスインを区切ることなく統一された方法で、後者が最終的にジャンプしたときにショーストッパーにならないように）。

しかし、それはマージされていますか？ 私は既存の拡張と同じアプローチを使用します。たとえば、一致するものを見つけてそれに追加します。

そうです、ミックスインの拡張を実際の引数とマージする際に起こりうる問題についてもっと考えていたと思います。例：

.b:extend(.a(1, 2, 3)) {}
.c:extend(.a(1, 2, 3)) {}

一方、ゼロパラメータミックスインにも隠れた驚きがあると思います。例：

.a {color: red}
.a {width: 2px}

.b:extend(.a) {}   // creates two `.b` blocks (it is expected since there're two `.a` blocks anyway)

.c {.a}            // creates one `.c` block (OK, this is just how mixins work)

.d() {color: blue}
.d() {width: 10px}

.e {.d()}          // creates one `.e` block (OK, this is just how mixins work)

.f:extend(.d()) {} // tada! another room for complains if this creates two `.f` blocks :)

まあ、多分これは深すぎます（そしてまた今のところそれを心配するには小さすぎます）。

.f:extend(.d()) {} // tada! another room for complains if this creates two .f blocks :)

「この例では、 .d()はパラメトリックであるため、2つの.fブロックを作成するべきではない」という考えで？

ええ、ミックスインが次の結果になることを考えると、私はあなたのポイントを見ることができます：

.f {
  color: #0000ff;
  width: 10px;
}

IMHO段階的に行うことが理にかなっている場合は、それを説明するだけかもしれませんが、苦情自体を回避するために何かを実装することは_しません_。 もちろん、これは私の2cです。 また、説明した動作で実装されている場合は、機能を追加するときに、「拡張セレクターからのCSSブロックをマージする」ための機能リクエストを作成して、苦情を回避することもできます...？

しかし、私は苦情自体を避けるために何かを実装しません。

私は絶対に同意します。 私は、「変更するには遅すぎる」ものの1つになる可能性のある驚きをさらに予測しようとしています。

：+1：ええ、私はあなたの考え方が好きです！

私はこの議論がまだ続いているのが好きです。 この議論のいくつかのポイントに戻りましょう。 まず、一般的な使用法に関しては、これは同じです。

.mixin {} == .mixin() {}

.mixin {}がクラスとして出力されることを除いて。 パーサーではおそらく異なる方法で処理されることを知っていますが、使用法では、プロパティと値のペアをダンプします。

意味：

.mixin1() {
    color: red;    
}
.mixin2 {
    color: blue;
}
.use1 {
    .mixin1;
    foo:bar;
}
.use2 {
    .mixin2;
    foo:bar;
}

この少ない構文履歴のために、私がこれを行うことができるのは理にかなっています：

.mixin1() {
    color: red;    
}
.mixin2 {
    color: blue;
}
.use1 {
    &:extend(.mixin1);
    foo:bar;
}
.use2 {
    &:extend(.mixin2);
    foo:bar;
}

私にとって、これは議論の余地がありません。元のミックスインの使用法の多くのインスタンスのドロップイン置換として：extendについてよく話しました。

素人にとって、これはおそらく直感的に同じです。なぜなら、.mixin1は、括弧で書かれているかどうかに関係なく、歴史的に次のように参照できるからです。

.use1 {
    &:extend(.mixin1);
    foo:bar;
}
.use1 {
    &:extend(.mixin1());
    foo:bar;
}

だから、私はこれを期待します：

.mixin1() {
    color: red;    
}
.use1 {
    &:extend(.mixin1());
    foo:bar;
}
.use2 {
    &:extend(.mixin1());
    bar:foo;
}

...出力する...

.use1, .use2 {
    color: red;    
}
.use1 {
    foo:bar;
}
.use2 {
    bar:foo;
}

ミックスインが2回定義されている場合、その姉妹であるクラスセレクターと同様に、拡張すると2回置き換えられます。

.mixin1() {
  color: red;
}
.mixin1() {
  width: 30px;
}
.use1 {
  &:extend(.mixin1);
  foo: bar;
}
.use2 {
  &:extend(.mixin1);
}
//output

.use1, .use2 {
  color: red;
}
.use1, .use2 { 
  width: 30px;
}
.use1 {
  foo: bar;
}

もちろん、ミックスイン名が出力に表示されることを除いて、ミックスイン定義の括弧を削除した場合、これが基本的にextendの動作方法です。したがって、既存の拡張動作に従うことは理にかなっています。

パラメータ（私の90％のユースケース）では、入力によって区別されることを除いて、同じことです。

.col(@width) {
  width: @width;
  display: table-cell;
}

.col1:extend(.col(10%)) { }
.col2:extend(.col(10%)) { }
.col3:extend(.col(80%)) { }

//output 

.col1, .col2 {
  width: 10%;
  display: table-cell;
}
.col3 {
  width: 80%;
  display: table-cell;
}

私にとって、ミックスインを拡張する理由は、パラメーターをグループ化することであり、非常に簡潔な出力を生成できる、より強力なミックスインライブラリにつながります。 パラメータなしでミックスインにそれらを使用することはそれほど重要ではありません。なぜなら、今日、既存のLess機能を使用して、目的の結果を生成できるからです。

これを推進し続けてくれた皆さんに感謝します。 かなり強力な追加になると思います。

：+1包括的な内訳をありがとう@ matthew-dean-私はあなたがカバーしたすべてに同意します。 最近の議論のトピックの1つであるこのシナリオについてのご意見をお聞かせください。

.mixin() { color: red; }

.component {
    .mixin() { color: blue; }

    > li:extend( .mixin() ) { ... }
}

LESSが現在機能している方法では、グローバルスコープ内のミックスインのみが拡張されます。つまり、赤いスタイルが拡張されます。 私は個人的にこの動作に問題はありません。誰かが上記のコードを記述して青いスタイルが普及することを期待する可能性がありますが、extendsの「グローバル」動作はドキュメントのワンライナーだと思います。

// this is ".mixin()", which is being extended
.mixin() { color: red; }

.component {
    // this is ".component .mixin()", which is not. 
    .mixin() { color: blue; }

    > li:extend( .mixin() ) { ... }
}

extendsの「グローバル」な振る舞いは、ドキュメントのワンライナーだと思います。

完全に同意します。 ここに灰色の領域を導入するのはひどい考えだと思います。

私にとって重要なのは一貫性です。 現在の動作がローカルスコープのセレクターを拡張しない場合、またはミックスインを使用する必要がない場合。 後でローカルでセレクターを拡張する場合は、ミックスインも拡張する必要があります。 人々は、ライブラリ全体である：extendのパターンを信頼できるはずです。

（もっと簡潔に言うこともできますが、「 @ jonschlinkertのコメントに+1」。;-)

この時点で、この機能を混乱させるようなユースケースを誰かが提供できますか？ @ matthew-deanからのこの包括的な概要とその後の応答から始めて

幸せな休日。 メリークリスマス。 フェリーチェフィエスタ！

本当に素晴らしい概要。 @ matthew-deanとそれに続くすべてのコメントに同意します。 ：+1：

@ matthew-deanにも同意します。 彼はうねりの仲間のようで、私は彼の手を振りたいです。

（-匿名）

@ matthew-ディーンワード。 ：+1：

この機能を使用すると、Bootstrapのグリッドシステムコードを非常にクリーンにすることができます。

：+1：@cvrebertに同意しました！ いいだろう！

ただ再訪します。 ほぼコンセンサスがあり、実装が必要だと思いますよね？

私はこれについてもっと情報を見つけようとしていますが、それはすべてを読んでいる迷路のようなものです。 これは実装されたことがありますか？ もしそうなら、誰かが私にドキュメントの適切な領域を教えてくれますか？

@ josh18いいえ、機能リクエストがまだ開いている場合、これは通常、実装されていないことを意味します。

よろしくお願いします。何かが足りない場合に備えて、もう一度確認したいと思いました。

ある時点で、ウィキのオープン/実装予定の機能を要約することを計画していますが、まだ時間がありません。

ある時点で、ウィキのオープン/実装予定の機能を要約することを計画していますが、まだ時間がありません。

@ matthew-dean +1

こんにちは、みんな！ 私が理解している限り、この機能はSASSプレースホルダーにいくらか似ています。 これがいつ実装されるのか知りたいだけですか？

やあ、
自分の時間や他の貢献者を予測するのは難しいと思います
彼らが興味を持っていることを実行するので、よくわかりません。 私が言えるのは
私たちはそれを優先度が高いと考えています、それは私のリストの次の大きなものです。

ご回答ありがとうございます。 これが実装され、機能するのを楽しみにしています。 :)

この機能の+1。 CSSのサイズを小さくするのに非常に役立ちます。

この機能の+1。

この機能の+1。

+1見て興味を持って、ありがとう！

：+1：

この号が作成されてから2年が経過しました。 2014年11月以降の優先度の高いタグ。マイルストーンは1.6.0または2.0.0です。 素晴らしい。 少ないのは2.5になりました。

@Grawl

PRをする準備ができているということですか？

@ seven-phases-maxそれは私が思っていたものとほぼ同じです。 そのような資格の表示。 ;）

@ Seven-phases-maxlolいいえ私はただのフロントエンド/デザイナーです。
@Celcは本当にひどく見えます😅

この号が作成されてから2年が経過しました。

ええ、とにかく、私はあなたに何を払っていますか？ ;-)

残念ながら参加を手伝うことはできませんが、私はこのリクエストに大いに賛成です！

これは、複雑で効果的なフレームワークを構築するための非常に重要な機能です。

3年と数えます。 幸いなことに、Sass v4が登場し（ sass-*プレフィックス付き関数付き）、Lessを取り除くことができます。

@stevenvachon私たちはSassに対して恨みを抱いていません。 もちろん、彼らはある意味で競争相手ですが、プロジェクトは異なる哲学を持っており、それらを呼び出すことによって私たちを傷つけようとすることは無意味です。

もちろん、誰からでもプルリクエストを歓迎します。 この機能を使用して、機能的なプルリクエストを喜んでマージします。

私は誰かを傷つけようとはしていません。実際、おそらくそのようなことを防ごうとしています。 自分の気持ちや、その結果としての新しい方向性を表現したほうがいいと思います。 後でより早く知る方が良いと思います。 みんなが去る前に。 たとえば、Bootstrap v4はLess.jsを使用しないため、ユーザーベースに大きな打撃を与えると確信しています。 もちろん、あなたはそのような政治をあなたが望むすべてを無視することができます。

@stevenvachonなぜそんなにオフトピックなのですか？ SassとLessはどちらも素晴らしいです。 私は純粋なJSが大好きです。 node-sassをインストールするにはacコンパイラが必要ですが、これは環境によっては面倒な場合があります。 すでにLESSに組み込まれていて、すべてのニーズを満たす：extend機能を使用しました。 この問題がまだ解決されていない理由すらわかりません。

ちなみに、私はRails開発者であり、Rubyプロジェクトでない場合はgulp + LESSを使用します。

オフトピック？ この機能は3年間実装されておらず、非常に便利です。

SassがJSで書かれているといいのですが、そうではなく、それが最も重要なことではありません。 その機能はです。 Sassではプレースホルダーを拡張できますが、Lessではミックスインを拡張できません。

まったく話題から外れているわけではありませんが、待望の機能です。 （とにかくあまり好きではありませんが、さまざまな理由で）

それはただ作られることを懇願します。

PS私の場合、私は実際にはjsの知識が少しあるデザイナーであり、ほとんどがdom関連のものであり、less.jsコードベースに貢献できる開発者からはほど遠いです。とにかく悲しい話です）

プロジェクトの非常に興味のあるサポーター）

公共サービスの案内

いつでもプルリクエストを送信するか、開発者と協力してプルリクエストを取得できます。この機能が統合される可能性が非常に高くなります。Less.jsライブラリには、このスレッドの人々のような個人からのより定期的な投稿が必要です。 。 それは一人の責任ではありません。 それは、このスレッドを見るか、この機能を必要とし、それを実現するために時間をかける一人の個人に完全に依存しています。

開発者ではないという回答の場合、新機能に必要なドキュメントを提供したり、ウェブサイトでサポートを設計したり、テストを実行したり、フィードバックを提供したりするなど、開発以外の役割でこのプロジェクトをサポートできる方法は他にもたくさんあります。問題、プロジェクト管理、Stack Overflowに関する質問への回答、ブログ投稿の作成、Lessに関するツイート、CSSおよびWebコミュニティへの貢献、Lessライブラリの作成について。

これらのタスクの多くは開発者である個人によって行われているため、開発に貢献できる時間はこれらの他のタスクに費やされます。

あなたが開発者であり、あなたの応答が「時間がない」である場合、それがこの問題が未解決のままである正確な理由です。 機能が完了したかどうかは100％自分次第なので、「誰か」が完了していない理由を尋ねるのは役に立ちません。 _あなたはその誰かです。_あなたがこのプロジェクトに参加した場合、私はそれが起こることを_保証します_。 Web上で最も人気のあるオープンソースツールの1つに参加することができます。 あなたは...数千人の生活に違いをもたらすことができますか？ 数十万人？ 数百万？ また、副次的な利点として、お気に入りの機能が後でではなく早く発生するようにすることができます。

あなたが起こるために、このまたは任意の機能が必要な場合は、それを実現します。 よろしくお願いします。 私たちはあなたと一緒に働きたいです！ このコミュニティが大きくなるほど、より少ないものがどんどん良くなっていきます！

そして、聞いてください。時々、人々が本当に貢献する時間がまったくないのに、それでも特定の機能を実現したいと本当に望んでいることを感謝します。 それはいいです。 あなたがそのシナリオにいるなら、あなたはあなたを助けるために彼らの時間（そして時にはお金）を寄付する人々への共感と感謝を目指していると私は言います、そして私はLessコミュニティの他の人々が最善を尽くすと確信しています彼らができるように、そうし続けます。

心から、
Less.jsコアチームのメンバー、Matthew Dean

私はすでに自分のプロジェクトをサポートしており、彼らの機能要求に耳を傾けています。 正直なところ、Less.jsコアを掘り下げる時間がありません。

sassプレースホルダー（または「サイレントクラス」）のサポートのためにここに来る人は、このコメントを読んでください。 （＃1851とそのようなクラスが「参照」ファイルにないため）そこまで到達することはできませんが、何もないよりはましです。