Less.js: セレクターを変数に保存する

不思議なことに、私はそのような要求がすでに存在することを絶対に確信していました。 どうやらそうではありません。
（明らかに、このアイデアは以前の多くのチケットに表示されていました：＃1174、https：//github.com/less/less.js/issues/1075#issuecomment-16891103など）
だから私が推測するようにしましょう。

ところで、万が一の場合に備えて（そして、考えられるimpl./syntaxの競合を考えるためにいくつかのユースケースを収集するために）：
どのように使用しますか？ 多くの場合、遅延評価のために期待どおりに機能しないと思います。 例えば：

a {
    <strong i="11">@r</strong>: &;
    b {
        something: @r;
    }
}

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

a b {
    something: a b; // not a!
}

@r値は、実際にはa b内で評価されるためです（つまり、定義した時点ではなく、使用されている場所）。
（したがって、特定のユースケースでは、実際には変数だけでなく、他の言語の構築が必要になる可能性があります。また、他の多くの関連するユースケースは、以前は＃1075の主題として検討されていました）。

多くの場合、遅延評価のために期待どおりに機能しません
特定のユースケースでは、変数だけでなく、実際には他の言語の構築が必要になる可能性があると思います

セレクターコンテキストが割り当てられている変数の評価によって呼び出された時点ではなく、定義された時点でセレクターコンテキストをキャプチャするには、その特別な言語構造が必要になります。 評価は、定義サイトでキャプチャされたコンテキストを出力する必要があります。

クロージャによる変数の検索と大差ありませんが、そうです。 関数ではなく、特別な言語構造が必要になります。

@rjgotten

はい、私たちは以前にいくつかのselector疑似関数について議論していたと思います（通常の関数解析ではセレクター固有のコンビネーターをすべて処理できないため疑似）そしてそれは疑似（つまりUrlような専用タイプ）
したがって、 <strong i="10">@foo</strong>: selector(&);ようなものは私が推測するトリックを行うことができます。 しかし、次の小さな問題が発生します。

a {
    <strong i="13">@var</strong>: selector(x, #y & .z);

    b {
        @{var} { // ? is it regular & or "saved-context-&" ?
            // ...
        }
    }
}

したがって、 &演算子/キーワード以外が必要になる可能性があります。 （または、専用の疑似関数、たとえばcurrent-selector() ...うーん、これで、すべての小さなグッズのAPIを汚染しないようにジェネリックPseudoFunction型をコーディングするというアイデアが生まれました。 ooch！:)。

言語に新しいものを追加することには一般的な躊躇があることは知っていますが、セレクター指定子は便利かもしれません。 私は|好きですが、 CSS @namespaceセレクター構文の一部です。 ただし、 |がセレクターを_開始_することを許可されているようには見えないため、競合しないようにする必要があります。 私はそれを使用しています。なぜなら、それは漠然と適切に見える数学の「絶対値」を思い出させるからです。そして、それは単純だからです。 会話を刺激するための単なる考え。

a {
  <strong i="10">@var</strong>: |x, #y & .z|; // starting w/ `|` means selector, in current context, ended w/ another `|`
  b {
    @{var} {
      //...
    }
  }
}

（実際には、_any_ varをすぐに処理して保存する必要があることなどを指定するために使用できますか？しかし、それは_way_オーバースコープのように感じます。）

通常の&またはsaved-context-&ですか？

セレクターコンテキストは、 selector()疑似関数が呼び出され、 &が_that_コンテキスト内で評価され、最終結果がこの新しいタイプに割り当てられるサイトでキャプチャされる必要があると思います。 Selectorツリーノードの。

例の@{var}を使用する場合のように、 Selectorタイプのツリーノードを保持する_any_変数がセレクターに補間される場合、結果のセレクターは同じ方法で構築する必要があります。 &補間器がセレクターに存在する場合のように、つまり; 1つのネストレベルからのセレクターを結合してプレフィックスを付けないでください。

この背後にある理由は、両方がキャプチャされたセレクターであるということです。 selector()はユーザーがキャプチャしたセレクターであり、 &は常に存在してキャプチャされた「親」セレクターです。

次に、ユーザーがキャプチャされたSelectorノードと_current_セレクターコンテキストの補間を必要とする場合、ユーザーはそれについて明示的にすることができます。 例： & @{var} { ... }

最後に

a {
    <strong i="24">@var</strong>: selector(x, #y & .z);

    b {
        @{var} { ... }
    }
}

生成する必要があります

x, #y a .z { ... }

一方

a {
    <strong i="31">@var</strong>: selector(x, #y & .z);

    b {
        & @{var} { ... }
    }
}

生成する必要があります

a b x,
a b #y a .z { ... }

うーん、 @{var}対& @{var}はかなり人工的に見えますが、これはこれらがLessでどのように機能するかではありません。 ... { & div ...と... { div ...は常に等しいステートメントでした。 また、これを数えなくても、 x, #y * .z他の場所で定義されているa b x, #y a b .zが必要な場合はどうすればよいですか？

私はセレクターの関数のような構造のファンではありません。 ただし、継承されたセレクターを参照、変更、または転送（変数に割り当てて再利用）できることをサポートしています。

ただし、念のために言っておきますが、これは＃1075（親セレクターをターゲットにする）のバリエーションであるか、 リストであり、単一の評価されたセレクター（またはミックスイン）ではなく、出力はセレクターリストであり、評価されたルールセットではないため、エイリアシングミックスインとは異なりますか？ この機能は違うと思います。 これらすべてが同じ方向に動いていることを確認したいだけです。

@ matthew-dean
それは実際に、評価されたルールセットをキャプチャし、さらに使用するためにそのリストを出力することではなく、実際のセレクタリストをキャプチャすることです。

extract(list,index)ような関数が更新され、セレクターリストからセレクターコンポーネントを抽出できるようになることや、ユーザーが興味深い方法で簡単に操作できるようにセレクターの操作を容易にする同様の拡張機能を想像できます。 たとえば、BEMなどの特定の命名スキームに従うコンポーネントの場合。

例：ミックスインが与えられた

.my-bem-component(<strong i="10">@a</strong>, @b) {
  // Component will only ever be constructed on the first selector in
  // a list, for simplicity.
  <strong i="11">@selectors</strong> : selector(&);
  <strong i="12">@selector</strong>  : extract(<strong i="13">@selectors</strong>, 1);

  // Generate a clean block name, cleared of modifiers.
  // Grabs e.g. "bar" from ".foo > .bar--baz"
  @block-name : replace(<strong i="14">@selector</strong>, "\.([^\.\s]+)--\S+$", "$1" );

  // Generate the modifier name and generate different CSS for
  // BEM classes that have one.
  // Grabs e.g. "baz" in ".foo > .bar--baz"
  @mod-name : replace(<strong i="15">@selector</strong>, "\.+--(\S+)$", "$1" );

  .generate-block();
  // When @mod-name matches <strong i="16">@selector</strong>, no replacement has
  // occured and we are infact in the situation where we have no
  // BEM modifier and generate the 'base' component.
  .generate-block() when (@mod-name = "@{selector}") {
    @{selector} {
      prop-a : @a;
    }
    @{selector}__element {
      prop-b : @b;
    }
  }

  .generate-block() when (default()) {
    @{selector} {
      prop-a : @a;
    }
    @{selector} > .@{block}__element {
      prop-b : @b;
    }
  }
}

次の少ない

.block {
  .my-bem-component(foo, bar);
}
.block--caps {
  .my-bem-component(FOO, BAR);
}

CSSを生成します

.block {
  prop-a : foo;
}
.block__element {
 prop-b : bar;
}
.block--caps {
  prop-a : FOO;
}
.block--caps > .block__element {
  prop-b : BAR;
}

Sassは、これを長い間持っていました。この手法が非常に巧妙に使用されている例は数多くあります。 私の例のようなコードファクトリで、または他の目的で。

はどうかと言うと：

less / less-meta＃16（コメント）との競合の可能性（単一のセレクターを変数に割り当てる）

個人的には、次のような動作を想定しています。
「トリビアル」セレクター値（例： .mixin 、 .ns.mixin 、 #foo .bar 、 bazなど）幸いなことに、これはミックスイン/関数として使用/定義できるすべてのものをカバーします）は変数に直接割り当てられます（または関数にパラメーターとして渡されます）。 つまり、実際にはすでにこれがあります：

<strong i="15">@var</strong>: .ns.mixin; // OK, its just Anonymous value (representing an arbitrary identifier) 
function(.mixin); // error: TODO 

^これは（本質的に）セレクターとはまったく関係ありません-これらの値は、 @var(...)または@var[...]ステートメント
（一般に、論理的な規則は、ミックスイン識別子が（内部的には）セレクターであることを忘れることですが、常にドットまたは#プレフィックスを持つ識別子、および.ns > .mixinようなものと考えることです。最終的には冗長で役に立たないものとして消えていきます:)

複雑または「本物」のセレクタに対し必要selector理由構文/パーサのあいまいさの擬似機能。 つまり、次のようなものです。

• <strong i="29">@var</strong>:foo>bar <-セレクターと（潜在的に）論理式
• <strong i="32">@var</strong>:.1+.2; <-arithm式と有効なLessセレクター
  （など、すべての特定のセレクターシンボルを思い出してください-ほとんどすべてが値解析コンテキストで何かと競合します。これは、上記の値がパラメーターとして関数/ミックスインに渡される可能性がある場合、さらに劇的になります。たとえば、次のことは不可能です。 selector()サポートするに
  less: some-function(abc, selector(#foo .is :not(> bar)[baz="qux"], abc), selector(bla), 42); // ^ remove `selector()` and try to parse

私はセレクターの関数のような構造のファンではありません。

要約すると、 selector疑似関数は、現在および潜在的な構文とセマンティクスの競合を永久に排除するために必要です。 したがって、ここには本当に多くのオプションがあるのではないかと思います（値とセレクターの解析コンテキストは、なんらかの方法で分離する必要があります）。

（上記のすべては、 selector()によって返される値が呼び出し可能なエンティティとして使用できないことを意味するわけではありません（例： @var() 、おそらく-しかし、それは単に不必要/役に立たないので、ほとんど価値がありませんわざわざ）。

@rjgotten

extract(list,index)ような関数を更新して、セレクターも抽出できるようにすることを想像できます。

確かに、そのような文字列にセレクターが含まれていると仮定して、文字列を処理するように関数を調整できますが、それは、そのようなすべての関数（ extractだけでなく）を更新/調整/変更する必要があることを意味します。 反対のアプローチは、より効率的で負担が少ないでしょう。 つまり、専用のselector-string->values変換関数であるか、ノードの適切な構造をselector直接返すこともできます（どちらの場合でも、最も難しい部分は、使用するたびにセレクターコンビネーターをパック/アンパックする方法です。 -ケースは異なる表現を好む場合があります）。

（セレクター補間機能自体は、最終的に@{var}を適切な形式に変換する必要があることに注意してください。したがって、その変数の値がどの形式であるかは、文字列、匿名、その他のいずれであっても、実際には重要ではありません。ノードの構造-変換のトリックのほとんどは同じままです）。

@block-name : replace(<strong i="17">@selector</strong>, "\.([^\.\s]+)--\S+$", "$1" );

正直なところ、これは「インラインJavaScriptとLessHatのようなハッカー」の生まれ変わりのように見えます。禁止することはできませんが、積極的に宣伝します。
（例がかなり不幸であることを数えないでください<-行を数えます）私はむしろless-plugin-bem-selectorsものを提案したいと思います（ここであなたは単にget-block-name関数を持つことができます。 &機能）そのような醜い正規表現の代わりに（「CSSプリプロセッサを任意のテキストプロセッサとして使用する」アプローチは、最終的にはPostCSSのようなものにひどく緩むでしょう）。

そして、 &対context-saving-&に戻ると、これまでのところ、関数の専用フラグ、たとえばselector(..., lazy or not) 、またはまたは、 other-than-&-keyword （例： ₸ ）。 評価ポイントのあいまいさを自動的に解決するための安全な方法を見つけることはできません。

less-plugin-bem-selectorsことを提案したい

絶対。 正規表現ベースの抽出は、カスタム関数を含まない例を提供するためだけのものでした。 ;）

私はセレクターの関数のような構造のファンではありません。

また、見た目だけを意味する場合⁞#foo:not(.bar)⁞場合もありますが、すでに無料のシンボルが不足していることはご存知でしょう。 したがって、疑似関数構文が提案されるのは、とにかくurlような概念がすでにあるためです（したがって、新しい概念が壊れる可能性がある、または壊れる可能性があることを考える必要はありません）。

さて、楽しい部分です。

私はcurrent-selector関数の迅速で汚いプラグイン実装を作成しました（それがどれほど肥大化する可能性があるかを確認するために、もちろんvar lazy-evaluationのためにあまり役に立たないことを期待しています）、そして何を知っていますか？ この基本的な例：

div {
    <strong i="9">@x</strong>: current-selector();
    span {
        r: @x; // -> div
    }
}

結果はr: div :)
コンパイラコードのどの部分がこの特定の動作を処理するのか正確にはわかりませんが、魔法を説明するためのより高度な例を次に示します。

div {
    <strong i="15">@x</strong>: current-selector();     // [1]
    <strong i="16">@y</strong>: current-selector() @v;  // [2]
    <strong i="17">@z</strong>: current-selector(@v);   // [3]
    <strong i="18">@v</strong>: whatever;
    span {
        1: @x; // div
        2: @y; // div span
        3: @z; // div span
        4: current-selector();  // [4] div span
    }
}

[2]ステートメントと[3]ステートメントのみが2回呼び出されます（つまり、実際には遅延評価されます）が、 [1]は呼び出されません（値に変数が含まれていないためと思われますが）繰り返しになりますが、これが意図的なものなのか、それともキャッシュの単なる副作用なのか、それともコードの幸運なバグである可能性があるのか​​はわかりません。たとえば、この行がこのキャッシュの副作用を引き起こす可能性がありますが、明確ではありません。なぜそれが余分な変数の影響を受けるのか-つまり、より多くの研究が必要です）。

つまり、プラグインベースのcontext-saving-&が可能であるように見えます（もちろん、 <strong i="29">@var</strong>: &代わりに<strong i="31">@var</strong>: current-selector()ようなものを使用することを除いて）関数はすべきではありませんがパラメータがある場合、それ以外の場合は遅延評価されます（変数が渡された場合）-最初に4つあるように計画していたので、これは悲しいことです:)。
かなり虐待的ですが、回避策/ポリフィルとして機能する可能性があります。 より実際の例も必要に応じて機能します。

div#zoo {
    <strong i="35">@x</strong>: current-selector();
    span {
        <strong i="36">@y</strong>: replace(<strong i="37">@x</strong>, div, body);
        r: @y; // OK, body#zoo
        @{y} { 
        // ^ not very useful this way (except maybe bem stuff) since you can't remove div
            color: red;
        }
    }
}

つまり、後続の変数の割り当て/関数呼び出しは、初期変数の評価ポイントに影響を与えません。

@ seven-phases-max
大好きです。

パラメータ引数が存在する場合、遅延評価が現在作業中にスパナをスローしている場合でも、_that_はおそらく「実際の」実装で回避できるものです。

また、見た目だけを意味する場合は...もちろん他の構造、たとえば⁞＃ foo：not （.bar）⁞かもしれ

けっこうだ。 使用法に関しては、これについて頭を悩ませていませんし、より良いアイデアもありません。 これには何か特別なことがあったと思いますが、そうではないかもしれません。 ある時点で$()についての議論があったことは知っていますが、結局$ 。 ところで、それはselectors()あり、 selector()ないでしょうか？ （ & ）セレクターをいくつでも含めることはできませんか？

そして、 selector(&)はcurrent-selector()よりも理にかなっているようです。 つまり、「Xオブジェクトからセレクターリストを作成します。 &でも文字列でもかまいません」。 最終的な構文が何であれ、引数として&が必要になるようです。

そして、 selector(&)はcurrent-selector()よりも理にかなっているようです

これらは別のものです。 current-selectorは、 &単なる関数バリアントです（後者はパーサーでサポートされていないため）。 selector(...)は、パーサーが任意のセレクター（ &含む）をサポートするためのパッチです。

selectorsについては、そうですね。 しかし、これは単一セレクターのユースケースの99％であるため、ほとんどのユーザーにとって複数形はあまり目立たないように聞こえると思います（ほとんどの場合、セレクターとしてh1, h2, h3 {}というタイトルを付け、Less parentセレクターについて話し続けます（セレクターの場合

ああ、わかりました。

@ matthew-dean
複数形と単数形は、CSS仕様の作成者以外はほとんど互換性があります。 実際、それを作成してください。CSS仕様自体でさえ、単数形と複数形の交換使用の餌食になることがあるため、仕様の作成者を含むすべての人にとって。

とても陽気に。 複数形の「セレクター」は、コンマ区切りのセットを指定する公式の方法ではありません。 複数形の厳密に正しい用語は、_セレクターリスト_であると私は信じています。

したがって、このあいまいな参照が実際にどれほど深く根付いているかを確認できます。

複数形の厳密に正しい用語は、セレクターリストだと思います。

ええ、昨日もw3cを検索しました。これは「セレクターのグループ」、「セレクターのリスト」などです。「セレクターは、コンビネーターで区切られた1つ以上の単純なセレクターのシーケンスのチェーンです」という奇妙なものはありません。そこにあります:) 「セレクター」形式は、主に「セレクタータイプ」のことを説明するために使用されます。

「セレクターは、コンビネーターによって分離された単純なセレクターの1つ以上のシーケンスのチェーンです」

そして、それがコンマ区切りのリストを参照している可能性があると考えている人にとっては、そうではありません。 その引用の完全な形式は次のようになります。「_ complex_selectorは、コンビネータで区切られた1つ以上の単純なセレクターのシーケンスのチェーンです。」

CSS仕様には別の問題があり、「セレクター」の一般化された形式は、仕様が正式に_complexselectors_と呼んでいるものを参照するために主に使用されます。 複雑なセレクターは単純なセレクターです。例： tag ; #id ; .class ; [attr] ; など、コンビネータを介してチェーンされます。例： > ; + ; ~など

ul > liようなものは、複合セレクターと呼ばれます。

警告以下は少し暴言になります：

CSSの仕様は、悲しいことに、一貫性のない、名前の悪い用語の窮地にあります。 後ろに行くほど、徐々に悪化します。 CSS3モジュールのロードがCSS2.1モジュールを参照し続けることや、古いCSS2.1ドキュメントを逐語的にコピーすることによって新しいCSS3モジュールが指定されたことを助けません。 ただし、セレクターとビジュアルフォーマットモデルの仕様は最悪の違反者です。 非常にあいまいで、似たような音の、またはわかりにくい名前の付いた用語。

たとえば、 [*|attr^="value" i]など、 ul > liよりもはるかに簡単なものを考えてみましょう。 後者は、技術的には単純なセレクターとして分類されます。 （はい、そうです。）

後者のビジュアルフォーマットモデルの仕様の一部を、数年前のある時点で、よりデザイン志向の同僚の1人に説明する必要がありました。 ラインボックスの概念を扱っている箇所を調べているときに、実際にいくつかのヒューズが脳内で飛んでいたと思いますが、それは最悪の部分ではありませんでした。 （正気度にほとんど価値がない場合は、テーブルフォーマットモデルである魔法のララランドに足を踏み入れてみてください。）

オープンソースプロジェクトのドキュメントの多様な喜び...

たとえば、 [*|attr^="value" i]など、 ul > liよりもはるかに簡単なものを考えてみましょう。 後者は技術的には単純なセレクターとして分類されます

それは実際には私には理にかなっています、笑、それはコンビネータを使用しないからです。 それは正確に定義に従います。 多くの記号を使用しているからといって、それがより「複雑」になるわけではありません。 ul > liは、2セットのクエリを含むため複雑です。つまり、 li一致するすべての要素をクエリし、それぞれからツリーをトラバースして、 ul含まれる要素を判別します。 後者は、個々の要素を1回だけテストします。 これは1つのクエリなので、単純なセレクターです。

複数形の「セレクター」は、コンマ区切りのセットを指定する公式の方法ではありません。 複数形の厳密に正しい用語は、セレクターリストだと思います。

そうです、あなたは正しいです。 「セレクター」は、実際には要素を選択できるように定義されたビットですが、 ul > li > .titleは「セレクター」の単数形です。 したがって、 selector()は、実際には、おそらく意味的に近いと思います。

@ seven-phases-max

quick-n-dirtyプラグイン関数で別の小さな問題に遭遇しました：名前空間のミックスインからのアクセスを正しく処理しません。 名前空間は通常のRulesetタイプのフレームであるため、その名前がセレクターに追加されます。

実際の実装では、おそらくその場合もカバーする必要があります。

[編集]
それを機能させる秘訣は、関数コンテキストのスタックのフレームの1つがMixinDefinitionであるかどうかを確認し、それが_is_の場合は、そのスタックの次のxフレームをスキップすることです。ここでxは、 MixinDefinitionのスタック上のフレームの量と同じです。

（基本的に、これはMixinCallがMixinDefinition実行するときにスタックに追加される「クロージャー」フレームをスキップします。）

「古い」ラベルを削除しました。 これはまだ調査するのに良い問題です。

たぶんcurrent-selector()はそれほど悪くはありません。 ただし、明確にするために、実際にはcurrent-selectors()ます。 しかし、それはまだ少し冗長です。 もっと簡潔な「capturing＆」の関数名を考えればもっと賛成だと思います。

より簡潔な「capturing＆」の関数名。

&()という名前を付けてください。 結局のところ、それは概念的には&にあるもののゲッターにすぎません。
例えば

.rule {
  <strong i="11">@selectors</strong> : &();
}

🤔
ええ、それは大丈夫なはずです。 異議はありますか？

提案された機能を理解しているかどうかを確認するために要約してみます。

新しい関数&()は、現在のコンテキストで&が出力する内容を返し、これを可能にします。

.component { // I only write "component" once!  Much concise, such DRY!
  <strong i="9">@this</strong>: &();

  /* base styles */

  &_child {
    /* styles for the child */
  }

  &-variant { // component-variant styles all together, and inside the `.component` block
    /* nothing too schmancy so far */
    @{this}_child {
      /* IT'S MAGIC! */
    }
  }
}

そして、それはすべてこれを出力します。

.component {
  /* base styles */
}
.component_child {
  /* styles for the child */
}
.component-variant {
  /* nothing too schmancy so far */
}
.component-variant .component_child {
  /* IT'S MAGIC! */
}

それはすごいので、私はそれが大好きです。

これについてもっと考えると、私にとって最も魅力的なのは（最初のパスの後、気が狂ったら止めてください）、標準化されたコンポーネントの「ブロック」（ルールセット）スタイルを持つ可能性だと思います。 基本的に、保存された単純なセレクター文字列値の代わりに、関数が_ " &にマップされることをほぼ望んでいますが、スコープでは変数は" _で定義されており、このオーサリングスタイルが可能になりますコンポーネントの場合（これをBehavior Aと呼びます）：

.component{ <strong i="8">@this</strong>:&();
  /* default styles */
  @{this}_child {
  // ↑ The crucial difference: `@{this}` here behaves _like `&`_, **NOT** like `.component`
    /* child default styles */
  }
}

次に、「 &代わりに@thisどこでも使用する」と言うことができます。

私の唯一の懸念はフリップケース（これをビヘイビアBと呼びます）ですが、そのビヘイビアが必要な説得力のあるケースは考えられません。 つまり、なぜ誰かがこれをやりたいのかわかりません。

.foo { <strong i="16">@and</strong>: &();
  @{and} {
    /*stuff meant to live under selector `.foo.foo` */
  }
}

それを達成するための現在の方法は_はるかに_簡潔であるため（そして、語彙で&が明確になったら、読みやすくなります）。

.foo {
  && {
    /*stuff meant to live under selector `.foo.foo` */
  }
}

行動Aよりも行動Bの説得力のあるケース（実装の難しさは別として）はありますか？

これは、作業を開始する前に回答する必要があると思う質問の1つにすぎません。

TL; DR：私の投票は、 &()を動的にすることです。つまり、本質的に_ " &ですが、静的な_"の値を返すのではなく、より深い "_ではなく、ここにネストされているかのようになります。今& 。 "_

@calvinjuarez期待される出力を記述していないため、例はやや混乱します。したがって、理論の領域では多少見えますが、基本的には次のようになります。

.component{
  <strong i="7">@this</strong>: &();  // <strong i="8">@this</strong> is now assigned the value of `.component`
  @{this}_child { a: b; } // this variable, when evaluated, forms the selector .component_child
}
// therefore this output is:
.component .component_child {
  a: b;
}

静的な「現在の＆の値」を返すのではなく、本質的に「＆ですが、より深くではなくここにネストされているかのように」を意味します。

これが何を意味するのか本当にわかりません。

これについて考える別の方法。 この：

.component {
  <strong i="6">@this</strong>: &()
}

書くことと同等です：

.component {
  <strong i="10">@this</strong>: .component;
}

@ matthew-dean

はい。 しかし、ミックスインのレンズを通して考えてみてください。 &()は、ミックスインの呼び出し元のセレクターコンテキストを取得します。

これにより、作成者自身が自然な方法でクラス名のルートを自由に決定できるミックスインベースのコンポーネントを作成できます。 与えられた例

.my-button {
  #buttons.base();
  #buttons.size( ... );
  #buttons.inset-icon-support( left right );
}

.my-button--wide {
  #buttons.size( ... )
}

.my-button--condensed {
  #buttons.size( ... )
}

そこで使用されるミックスインは、 &()を介してクラスを読み取り、それを適切に出力に組み込むことができます。 たとえば、2番目と3番目のルールでキャプチャされたセレクターは、BEM構文を分解して、ネストされた要素セレクターのオーバーライドを生成するために使用できる基本ブロッククラスを取得できます。

あれは; セレクター名をパラメーターとして渡す必要なしに、 .my-button--wide > .my-button__textようなセレクターを生成するために使用できます。 呼び出し先セレクターコンテキストからのみ。

このようなミックスインベースの_コンポーネントファクトリ_は、スタイリングフレームワークを使用することで発生する、私たちの道や高速道路の問題の多くを回避します。 フレームワークを登録できますが、実際に組み込むコンポーネントとその名前をきめ細かく選択できます。

@rjgotten

そこで使用されるミックスインは、＆（）を介してクラスを読み取り、それを適切に出力に組み込むことができます。 たとえば、2番目と3番目のルールでキャプチャされたセレクターは、BEM構文を分解して、ネストされた要素セレクターのオーバーライドを生成するために使用できる基本ブロッククラスを取得できます。

ええ、わかりました。 おそらくミックスインで最も便利です。 私は間違いなく、直接セレクター名を使用するよりも&()のユーティリティを取得します。 私のポイントは、与えられた例で&()の値を明確にしようとすること

さらに言えば、これは優れた構文ソリューションだと思います。誰かがそれを採用したい場合は、個人的に&()実装を進めることに👍を与えます。

@ matthew-dean

期待する出力を記述していないため、例はやや混乱しています。

おっと、お詫びします。 正しく言い換えます。 以下のCSSにLessをコンパイルすると、 &()方が強力な機能になると思います。

.component { <strong i="10">@this</strong>:&();
  /* default styles */
  @{this}_child {
  // ↑ The crucial difference: `@{this}` here behaves _like `&`_, **NOT** like `.component`
  // (since it's in the same rule block and scope level).
    /* child default styles */
  }
}

.component {
  /* default styles */
}
.component_child {
  /* child default styles */
}

この場合、 <strong i="15">@this</strong>:&();が<strong i="17">@this</strong>:.component;と同じように動作する場合、この機能をミックスイン内のユーティリティ_only_に委任していますが、提供できるものはまだまだあると思います。

静的な「現在の＆の値」を返すのではなく、本質的に「＆ですが、より深くではなくここにネストされているかのように」を意味します。

これが何を意味するのか本当にわかりません。

これは、 .thing{ & {} }と.thing{ <strong i="11">@amp</strong>:&(); @{amp} {} }が同じ出力を生成するはずだと思うことを意味します。

つまり、より実際的には、簡単なBEMを実行するためにミックスインを作成する必要はありませんが、インラインで定義することができます。 私の古い例の1つに戻ります：

_component.less_

.component { // I only write "component" once!  Much concise, such DRY!
  <strong i="16">@this</strong>: &();

  /* base styles */

  @{this}_child {
    /* styles for the child */
  }

  @{this}-variant { // component-variant styles all together, and inside the `.component` block
    /* nothing too schmancy so far */
    @{this}_child {
      /* IT'S MAGIC! */
    }
  }
}

↓↓↓

_component.css_

.component {
  /* base styles */
}
.component_child {
  /* styles for the child */
}
.component-variant {
  /* nothing too schmancy so far */
}
.component-variant .component_child {
  /* IT'S MAGIC! */
}

利点：チームに&と@{this}どちらを意味するのかを尋ねる必要はありません。 「どこでも@{this}使うだけ」と言うだけです。

実際には、コンポーネントファクトリミックスイン定義の内部的な一貫性も高まります。

_hypothetical-button-mixin.less_

#button () {
  .size(large) { <strong i="7">@button</strong>: &();
    @{button} { // same scope, so it behaves _exactly_ like `&`.
      font-size: 1.8rem;
    }
    @{button}-primary { // same scope, so it behaves _exactly_ like `&`.
      border-width: 5px;
      @{button}_icon { // nested scope, behaves like the parent selector at the mixin call (.btn).
        height: 1.8rem;
        width:  1.8rem;
      }
    }
  }
}
// ...

_hypothetical-styles.less_

.btn {
  #button.size(large);
}

_hypothetical-styles.css_

.btn {
  font-size: 1.8rem;
}
.btn-primary {
  border-width: 5px;
}
.btn-primary .btn_icon {
  height: 1.8rem;
  width:  1.8rem;
}

つまり、.thing {＆{}}と.thing { @amp ：＆（）; @ {amp} {}}は同じ出力を生成するはずです。

はい、私たちは同じことを言っていると思いますが、この例で確認させてください。 これが、この機能とインプレース&です。

.mixin() {
  <strong i="10">@this</strong>: &();
  .a {
    .b @{this} { c: d; }
  }
}
.component {
  .mixin();
}

// outputs:
.component .a .b .component {
  c: d;
}

一方：

.mixin() {
  .a {
    .b & { c: d; }
  }
}

生成されます：

.b .component .a {
  c: d;
}

@calvinjuarez誰もあなたの例とは違うことを提案していないと思うので、私は混乱したと思います。 &()は、基本的にその場所で評価されたthis.selectors.toCSS()ようになります（実際にはそうではありませんが、

@ matthew-dean
すべてのリストメンバーに基づいてセレクターを拡張するための特別な動作を含め、セレクターリストをセレクターの実際のリストとして公開する場合は、実際にはさらに_もっと_素晴らしいでしょう。

例えば持っている

.a, .b {
  <strong i="8">@this</strong> : &();

  @{this} {
    c : d;  
  }
}

出力

.a .a,
.a .b,
.b. .a,
.a .b {
  c : d
}

ネイティブの&と同じように。

はい、それはまさにそれがすることです。 3.5では、セレクターで評価された変数により、セレクターリスト全体が新しいセレクターリストとして再解析されます。 そうです、それは期待どおりに機能します。 私が最近行ったいくつかのPRのおかげで、実際には非常に簡単です。

2018年7月7日には、10時34分AMで、rjgotten [email protected]書きました：

@ matthew-dean
すべてのリストメンバーに基づいてセレクターを拡張するための特別な動作を含め、セレクターリストをセレクターの実際のリストとして公開すると、実際にはさらにすばらしいでしょう。

例えば持っている

.a、.b {
@this ：＆（）;

@{これ} {
CD;
}
}
出力

.a .a、
.a .b、
.b。 .a、
.a .b {
CD
}
ネイティブと同じように。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

.component{
 <strong i="6">@this</strong>: &();  // <strong i="7">@this</strong> is now assigned the value of `.component`
 @{this}_child { a: b; } // this variable, when evaluated, forms the selector .component_child
}
// therefore this output is:
.component .component_child {
 a: b;
}

余分な.componentは、私が反対しているものです。 私はそれがこのように機能するはずだと提案しています：

less .component{ <strong i="12">@this</strong>: &(); // <strong i="13">@this</strong> is now assigned the value of `.component < &` @{this}_child { a: b; } // this variable evaluates like `&_child` } // therefore this output is: .component_child { // < Note: `.component_child` !== `.component .component_child` a: b; }

ただし、この機能は別の方向に進んでいるようです。 私の立場を明確にしたかっただけです。

私はそれがこのように機能するはずだと提案しています：

つまり、セレクターにプレーンな_string_ではなく_selector list_である置換トークンがある場合、置換トークンは&が指定された場合と同じように機能し、ネストの結果として生じる通常のセレクターチェーンを_無効にします_。

&()が、実際のセレクターリストとして識別できるノードタイプを出力する場合、その動作は比較的簡単に実現できると思います。

実際、専用ノードタイプを出力する場合は、後でキャプチャされたセレクターリストを_操作_するプラグイン関数の作成にも役立つ可能性があります。

私には、＆（）に一度に多くの作業を行わせるように聞こえます。 セレクターを変数に保存したい場合、それは1つのことですが、その_content_のために、その変数でセレクターチェーンを無効にすると、構文が不明確になります。 その変数はどこからでも取得でき（たとえば、ミックスインから渡される）、セレクターリストは単純な変数の割り当てによって生成できます。 つまり、変数の使用法から、変数の内容に基づいて異なる連鎖動作が発生するかどうかは明らかではありません。

チェーンを無効にしたい場合は、暗黙の＆を別の値に置き換えることを指定する必要があると思います（フォーマットを許してください、私は私の電話にいます）-

。成分 {
@var ：＆（）;
＆（@ var）_child {} //またはそのような「＆の置換」構文
}

したがって、結果が望ましい理由はわかりますが、IMOでは、セレクターリストの取得元に基づいて変数のマージ動作を「マジックスイッチ」することはできません。 これには2つの異なる機能が必要です。

ああ...私は実際に&(...)ものが好きです...

ハ、本当に？ &() （＆からセレクターをキャプチャ）と&(@arg) （＆をセレクターに置き換える）のセマンティックな混乱はないと思いますか？

誰かが&を本質的に破棄するために空のセレクターに置き換えたいと思うかもしれないので、それらを混合しないことを検討したいかもしれません。 （ルートに子を配置します。）多分&(“”) .childかもしれませんが？

私は知らない、それはいくつかの考え/考慮に値する。

また、「親セレクターにはターゲットが必要」のスレッドで述べたように、継承されたセレクターの特定の部分を（または完全に）置き換えるユースケースがあるので、それを考えると、それらは2つの別々の問題として追跡する必要があると思います。 この問題は、キャプチャと

この円を閉じるために、ここで、関数のような構造を使用して&をインプレースで変更することに言及しました。 -https ： //github.com/less/less.js/issues/1075#issuecomment -397697714

したがって、「 &継承を変更する方法/かどうか」についての議論が親セレクタースレッドに残っているといいのですが、このスレッドは、 <strong i="9">@var</strong>: &()が- &セレクターを変数に配置します。 私の考えでは、他のスレッドにもかかわらず、これはまだ問題ないようです。 両方を行う機会があるかどうかはわかりません。

私はこれをやろうとしています

.html, .css, .js, .php, .mysql, .jquery, .txt, .java {
    <strong i="6">@html</strong>: '\f2d0';
    <strong i="7">@css</strong>: '\f034';
    <strong i="8">@js</strong>: '\f121';
    <strong i="9">@php</strong>: '\f120';
    <strong i="10">@mysql</strong>: '\f1c0';
    <strong i="11">@jquery</strong>: '\f78c';
    <strong i="12">@java</strong>: '\f11b';
    <strong i="13">@txt</strong>: '\f15c';
    &:before {
        content+_: @&;
    }
}

しかし、これが実装されるまでは機能しません