Less.js: 条件付きCSSコード

http://www.lesscss.org/にアクセスして、警備員を検索します。

ミックスインを使用する必要をなくすために、機能リクエストを調べて、任意のcssでガードを許可します。

はい、私はそれを知っていますが、私たちが巨大なLESSを書いている場合、何百もの.mixinを書いて管理する必要があります
ミックスインがこの問題を解決するとは思わない。 ミックスインでさえ、この機能で多くのパワーを得るでしょう。
少ないCSSには、一部のプログラミング言語が持つほとんどすべての機能があります。

.button-maker (<strong i="8">@style</strong>: 'light') {
    cursor: pointer;
    display: inline-block;
    padding: 5px 10px;

    if(<strong i="9">@style</strong> == 'light'){
        /* adds light styling */
    }

    if(<strong i="10">@style</strong> == 'dark'){
        /* adds dark styling */
    }
}

私は本当に欠けているこの機能に大きな+1を追加します。 大きなコードベースで警備員を維持することは、本当に悪夢です。 これは本当に物事をはるかに簡単にするでしょう...

switchステートメントを追加することもできます。

@lukeapageこの問題を再度開いてください。 この問題/機能について話し合うべきだと思います

LESSはスクリプト言語ではありません。 構文/スタイルはCSSに似ています。

LESSは宣言型であることが意図されています。つまり、分岐ロジックやループなどの複雑な状況に対応できるものであってはなりません。

@pierresforge警備員が不足している例はありますか？

セレクターに警備員を配置することで解決できない場合はどうでしょうか。

話し合いは開かれています。私（またはコアチームの別のメンバー）を説得できれば、問題を再開します。しかし、会話は以前に行われており、多くの時間が費やされています。 。

http://lesscss.org/からの文章
「LESSは、変数、ミックスイン、操作、関数などの動的な動作でCSSを拡張します。」

はいLESSはスクリプト言語ではありませんが、それでも変数、関数、演算などの機能があります。
欠けているのは条件付きロジックです。

CSSメディアクエリは条件付きロジックに他ならないと思います。

<strong i="11">@media</strong> all and (max-width: 699px) and (min-width: 520px), (min-width: 1151px) {
  body {
    background: #ccc;
  }
}

CSSがガードのような条件付きロジックを持つことができるかどうか。 違いは何ですか。 ガードはそれをミックスインに拡張するだけです。
Guardsは、CSSコードブロックの外側の条件のみを許可し、コードブロックの内側は許可しません。
インスタンスについては、 https： //github.com/cloudhead/less.js/issues/1293#issuecomment-16929701を参照してください。警備員はそのような要件を支援できません。

HTMLにも条件付きロジックがあります。そうです。スクリプト言語ではなくマークアップ言語です。

<!--[if gte IE 9]><!-->        
    <script src="" />
<!--<![endif]-->

@lukeapageありがとう..

ガードは、メディアクエリが行うことと類似しています。 通常のCSSでは、セレクター内にメディアクエリをネストできないことに注意してください。 それらはドキュメントのルートにのみ配置できます。

いいえ、警備員が足りない例はありません。 ただし、ガードが保守性に最適ではない場合はたくさんあります。

例：

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  if (green(@coreBackgroundColor) > 50%) {
    background-color: darken(<strong i="7">@coreBackgroundColor</strong>, 20%);
  }
  else if (red(@coreBackgroundColor) > 30%) {
    background-color: darken(<strong i="8">@coreBackgroundColor</strong>, 15%);
  }
  else if (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(<strong i="9">@coreBackgroundColor</strong>, 8% );
  }
  else {
    background-color: @coreBackgroundColor;
  }
}

私の意味では、以下よりも簡潔で自明です（アルゴリズムは多くの要因に依存するため、ほとんどの場合、コードを再利用可能にする意味がない場合）。

.buttonBackground(@color) when (green(@color) > 50%) {
  background-color: darken(<strong i="13">@coreBackgroundColor</strong>, 20%);
}

.buttonBackground(@color) when (red(@color) > 30%) {
  background-color: darken(<strong i="14">@coreBackgroundColor</strong>, 15%);
}

.buttonBackground(@color) when (red(@color) > 25%) {
  background-color: darken(<strong i="15">@coreBackgroundColor</strong>, 8%);
}

.buttonBackground(@color) {
  background-color: @color;
}

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;
  .buttonBackground(@coreBackgroundColor);
}

私はこれが議論の対象となることに同意しますが、それが多くのコア変更を伴わないのであれば、これはかなり素晴らしい追加になるでしょう。 ミックスインを追加しなくても、ほとんどのルールをまとめて1つの要素に適用できます。

このような状況が、私がコントラスト関数を作成した理由です。これは、他の方法では利用できない一種の条件付き操作として機能し、あなたが言うように、ガードを使用するよりもはるかに優れています。 条件の構文を追加するのではなく、一種のセレクターとして機能するある種のジェネリック関数を実装できると思います。

@Soviut Devilの提唱者-LESSでは、実際にメディアクエリをセレクター内に配置できます。これは多くの場合非常に便利です。

私はifsに反対しました。なぜなら、コードの複雑さが指数関数的に上昇し始め、LESSは単純でわかりやすいように設計されているからです。 現時点では、新機能の追加よりも言語を安定させるためのいくつかの推進力があります。

ただし、メディアクエリがセレクター内に表示されるようになったという論理に基づいて、悪魔の代弁者は、理論的には同じ原則に従うことができます。

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;

  <strong i="9">@when</strong> (green(@coreBackgroundColor) > 50%) {
    background-color: darken(<strong i="10">@coreBackgroundColor</strong>, 20%);
  }
  <strong i="11">@when</strong> (red(@coreBackgroundColor) > 30%) {
    background-color: darken(<strong i="12">@coreBackgroundColor</strong>, 15%);
  }
  <strong i="13">@when</strong> (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(<strong i="14">@coreBackgroundColor</strong>, 8% );
  }
}

or

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  background-color: darken(<strong i="15">@coreBackgroundColor</strong>, 20%) when (green(@coreBackgroundColor) > 50%) ;
  background-color: darken(<strong i="16">@coreBackgroundColor</strong>, 15%) when (red(@coreBackgroundColor) > 30%);
  background-color: darken(<strong i="17">@coreBackgroundColor</strong>, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

ifsよりも宣言的で、既存のLESSに近い構文であり、各ステートメントを個別に評価します（LESS / CSSが定義されているように）。

あるいは（またはそれに加えて）、同様に、ミックスインの評価を評価ポイントに添付します。

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  .backgroundMixin(<strong i="22">@coreBackgroundColor</strong>, 20%) when (green(@coreBackgroundColor) > 50%) ;
  .backgroundMixin(<strong i="23">@coreBackgroundColor</strong>, 15%) when (red(@coreBackgroundColor) > 30%);
  .backgroundMixin(<strong i="24">@coreBackgroundColor</strong>, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

間違いなく、ステートメントレベルのガードは、ミックスインレベルのガードIMOと同じくらい、またはそれほど複雑ではなく、異なるロジックでもありません。 おそらく、例2と3は、言語に対してそれほど拡張的ではありません。 考え/議論のためにそこにそれを投げると思っただけです。

私の宣言警備員の提案については、誰も言うことがなかったと思います。 ;-)

実際、いや、言うことはあまりありません。 それは素晴らしいことです、IMO :)

ええ、それらがすでにミックスイン上にあり、メディアクエリが要素内にある可能性がある場合、それらを拡張するためのロジックは合理的であるように思われます。 @lukeapageや@jonschlinkertなどがどう思うか興味があります。

@matthewdl ：+1：

彼らが議論されている問題について、私はすでに彼らをサポートしていると思います.... :)

@lukeapage問題＃748について話しているのですか？ もしそうなら、私は構文に少し追加しました。 ;-)

ifまたは@whenの形で自分の願望を表現するためにチャイムを鳴らしたいと思います。

私は、ガードが普遍的に優れており、条件付きを使用するよりもLESSコードの複雑さを軽減するという感情に同意しません。 警備員が実際に私のLESSファイルを醜く読みにくくしているが、 if / @whenは実際には非常に読みやすいという実際的な状況を見つけています。 ガードとif / @when条件文は本質的に単なるツールであり、どちらも物事を美しくまたは醜くするために使用でき、さまざまな状況により適しています。 地獄、私はLESSの最も基本的なセレクター拡張機能のみを使用して1GBを超えるRAMを消費し、CPUを数分間攪拌したままにする約300bの.lessファイルを作成できます。

最近のプロジェクトでは、デスクトップとモバイルの両方を強力にサポートすることを目的として取り組んでいましたが、最終的には、インラインメディアクエリでこれを行うだけでは不十分であると判断しました。 どちらのモードにも使用しない余分なcssを提供することは、良い音ではありませんでした。さらに、背景画像の二重読み込みをカスケードしようとして、時間を無駄にせずにデータURIを埋め込むことができずに、それを回避する必要があるという問題もありました。モードが使用しない画像全体を提供します。 そして、2つのスタイルシートをカスケードしようとしてこれに対処すると、1つのクラスのスタイルを宣言する場所が2つあるので、混乱が少なくなります。

私の決定は、MediaWikiがRTLを処理する方法から、1つから2つのスタイルシートを提供することによってページを取得することでした。 MediaWikiは、LTRでスタイルシートを記述し、スタイルシートを反転して2番目のRTLスタイルシートを作成することでこれを行います。 LTRがRTLを処理するために、LTRに指定されたすべてをオーバーライドしようとする必要はありません。 同様に、メインのスタイルをmain.less（およびスタイルを分離するためにそこから参照される可能性のあるファイル）に書き込むことにしました。そのファイルは直接コンパイルされません。 代わりに、desktop.lessとmobile.lessの2つのスタイルシートがあり、どちらも<strong i="14">@mobile</strong>: true/false; 、 <strong i="16">@desktop</strong>: true/false;のようなものを設定し、サイズなどのいくつかの少ない変数をオーバーライドします。 このようにして、main.lessは最終的にdesktop.cssとmobile.cssの両方になり、メディアクエリ/テストを処理して、どちらを他の場所にロードするかを決定できます（本当に必要な場合は、どちらをロードするかを実際に決定できます）メディアクエリもサポートしていないデバイス）。

ただし、1つの問題は条件付きブロックです。 「モバイルはこれらのスタイルを必要としない」または「デスクトップはこれらのスタイルを必要としない」と私が判断したコードの部分があります。 現在、これをより少ないコストで実行できる唯一の方法は、次の方法です。
（（わかりました。技術的には、アコーディオンナビゲーションを使用していないため、これらのスタイルは架空のものですが、私が行っていることには当てはまります））

.navigation {
  color: @text-color;
  // [...]
  // Navigation is an accordion on the desktop so include our accordion styles
  .dummy() when (<strong i="21">@desktop</strong> = true) {
    .accordion-styles();
  }
  .dummy();
}

この状況では、 @whenのようなものを使用する方がはるかに理解しやすいでしょう。

.navigation {
  color: @text-color;
  // [...]
  // Navigation is an accordion on the desktop so include our accordion styles
  <strong i="26">@when</strong> (<strong i="27">@desktop</strong> = true) {
    .accordion-styles();
  }
}

私は実際に、lessファイルを前処理して、 @when構文のようなものを、動的に生成されたミックスイン+ガードが作成され、その直後に含まれるハックに変えることを検討しました。
言うまでもなく、プリプロセッサを前処理するという考えが、物事を理解しやすくする良い考えのように聞こえる場合...現在のプリプロセッサに何か問題があります。

そして真実は、これは私のデスクトップ/モバイル技術だけに当てはまるわけではないということです。 これは、テーマスキームにも同様に当てはまります。 あなたのテーマで1つのメインレスファイルを書いてください。 次に、その少ないファイルを含めるだけのファイルをたくさん用意し、配色などを制御するためにいくつかの少ない変数を設定します。 色の微調整は問題なく機能しますが、 @use_horizontal_navのようなものを実際に使用できることがわかったら、すぐに崖から逃げ出します。

@dantmanは1.5.0の時点で、リンクされているcssスタイルのガードはこれを行うことができます

.navigation {
  & when (<strong i="7">@desktop</strong> = true) {
    color:red;
  }
}

あなたの例では砂糖です。

唯一の欠点は、現時点ではそれが新しいセレクターであると考えているため、以前のセレクターとマージされないことです。 ただし、これによって問題が発生する可能性は低く、将来のバージョンで修正される予定です。

わかりました、それを機能として文書化できますか？

正直なところ、 @whenと比較して非常に理解しやすいかどうかもわかりません。以前に、.lessファイルで& when(...)を見ていたら、それが何であるかを理解できたかどうかはわかりません。一目でした。 @when & when() $ 2 $＃$がいいかもしれません。

@ matthew-deanがこの種の条件付き構造を追加すると、LESSコアファイルの保守とテストが難しくなる可能性があることに同意します。 また、.lessファイルはデバッグが困難です。

私たちが今得ているのは芸術作品です。人々は文字通り10分未満でLESSの基本を理解し、学ぶことができます（ネストとミキシングについて話します）。条件付きステートメントを追加すると、他の種類の人々に物事を消化するのが難しくなります。デザイナーや愛好家。 ガードを使用してIFステートメントを模倣またはシミュレートしようとすることは、存在せず、解決策を必要としない問題を悪化させようとするだけです。

開発者がコンパイルする前にLESSファイルをより複雑にし、制御する必要がある場合、より優れた制御、柔軟性、および複雑さを実現するために、PHPなどの言語を使用してより少ないファイルを前処理することを止めることはできません。これを行うには、想像力を使って最も正確または便利な方法でこれを行うだけです。

たとえば、「myfile.less.php」という名前のファイルがあり、条件付き、スイッチ、配列、およびPHPで表示できるすべての凝ったものを含むクレイジーなコードがあり、その「.less.php」ファイルから別のファイルを吐き出します。最終的なLESSコードを持つ「myfile.less」と呼ばれるこの方法で、PHPを使用してすべてのサーバー変数をクエリし、新しい.lessファイルに含めるまたは除外する@importsを決定できます。これ以上、大量の愚かな変数を渡す必要はありません。 LESSコンパイラであり、IFまたはSwitch構造のシミュレーションを模倣するために、醜く読みにくい愚かなガードを作成する必要はありません。

基本的なワークフローは次のようになります

1-キャッシュの有効期限が切れているかどうかを確認します
1-スクリプトを呼び出して、すべてのファイル「.less.php」ファイルを検索して前処理します
2-スクリプトを呼び出してすべての「.less」ファイルをコンパイルします
3-キャッシュを更新

@enav私は熱心に反対します。 開発を減らすだけでなく、問題を解決するために2つの言語を使用する必要がない、ノードの最上位に基づくエンタープライズソリューションで使用します。

@dantman文書化されていないことがかなりありますが、そうです、それを文書化する必要があります。 ドキュメントを拡張し、ウェブサイトを大幅に改善するために、less-docsで進行中の努力があります。 そこに問題を追加します。

@lukeapage 、ええ、最近気づきました。 変更ログをざっと見てみると、svg-gradientやpropertyが+とマージされていることに気づきました。

厳密に言えば& when ...は、文書化された2つの機能&とCSS Guardsの単純な組み合わせであるため、すでに文書化されています。 しかし、専用の例はもちろん害にはなりません。

@ Seven-phases-max、私はそのドキュメントを知りませんでした。 見た目からすると、これは古いサイトを置き換えるための不完全な新しいドキュメントセットであり、「これはまもなくlesscss.orgリポジトリに移動されます。すべてが公開されるまで、このサイトへのリンクを避けることをお勧めします。」 コメント。 そのようなものが作業中であることを知ってうれしいです。

私が知っていた唯一のドキュメントであるlesscss.orgの現在のドキュメントを参照していましたが、現在、ミックスイン機能としてドキュメントガードのみを参照しており、他の場所で利用できることを示唆していません。

警備員はこれほど良くありません。 :(

これは必須の機能であり、scassにも存在します。

このための+1

本日は、この号が発行されてから数年後にこのコメントが出されたので、今、頭に浮かぶことが1つあります。

元の議論での@whenに対する抵抗の一部は、追加のルールです。 しかし、今考えてみると、必要ないはずです。

これらの2つのブロックが等しいことを考えると：

.a {
  & .b { color: blue; }
}
.a {
  .b { color: blue; }
}

次に、これら2つのステートメントもパーサーによって等しいものとして受け入れられる必要があります。

.a {
  & when (1=1) { color: blue; }
}
.a {
  when (1=1) { color: blue; }
}

& when以外の理由がない場合、構文的には本当に厄介です。 &を省略して、親セレクターとのセレクター結合を暗示するのはずっと前から存在しているため、親セレクターのガードを暗示するために&を省略しても、飛躍のようには見えません。 また、ブロックルート関数がプラグインで使用するためにパーサーによって受け入れられるようになったため、2013年のように奇妙に見えることはなくなりました。

これを再開する理由は見当たらない。 結局のところ、私たちはすでに＃2072を持っています

when (1=1) { color: blue; }

二人のキャラクターの経済のためだけに大きな混乱ボックスを開く？

警備員はこれほど良くありません。

ランダムな不合理なコメントをコメントする価値すらないと思いました。 すべての位置の背後に何かがあるはずです（そうでなければ、条件付きコードは不完全であり、 ifは、ほとんどすべての言語で単一の条件がなくても_anything_を書く方法を知っているという理由だけでばかげています）。

これを再開する理由は見当たらない。 結局のところ、私たちはすでにwhen (1=1) { color: blue; }を持っています

えーと…いや、そうじゃないの？

しかし、そうすべきであるのは合理的です。 私たちはそれを許可し、それで終わらせることができます。

リンクするはずの機能リクエストが見つかるまで待ちます（申し訳ありませんが、終了する前に誤ってEnterをクリックしました）

したがって、これを＃2072にマージします。

@ seven-phases-max

この問題は「保護された自己実行ブロック内での変数の再定義を許可する」と呼ばれ、その問題の下部にある接線の議論には、select / caseおよびvbscriptiif（[ifcond]、[then]、[else]）に類似したユースケースが含まれていました。それはおそらく議論のためのより論理的なピックアップですが、それはおそらく裸のとき以上に機能します。 Buuut ...おそらくそれはwhen ()対& when ()の質問だけで新しい問題として提起されるべきです。

when（）vs＆when（）の質問だけで。

あなたはこれに真剣に取り組むことはできませんね？ 正確には何のために？ $＃ &を削除しても、 whenはifにはなりません（すべての理由で＃2072を参照）。 それで、それをそのままにして、それで終わらせてください。

ねえ、あなたはそれをワンランク下げてくれますか？ 気が動転している場合は、少し時間を取って後で戻って、新しい号に投稿した理由を確認してください。 これらの最初の議論以来、いくつかのことが進化してきました。

私は気分を害するつもりはありませんでした。
私の：

それで、それをそのままにして、それで終わらせてください。

ただの返事でした：

私たちはそれを許可し、それで終わらせることができます。

@ Seven-phases-maxわかりました、テキストでトーンが失われます。 いずれにせよ、私はこのアイデアにひどく執着していませんでした、そして全体として、既存の@when提案はとにかくより良い/より用途が広いです。

「sass」は少ないよりはましだと思います。 すでにif-elseがあります。 それは本当に難しく、コーディングの多くの行が少なくなります。 動作するが、ニーズを完全に満たしていない場合。 さらに、ループを少なくすることもできますが、言語には独自の機能が必要です。

@aukgit仕事に適したツールを使用してください。 SCSSの方が適している場合は、それを使用することをお勧めします。 SassとLessは非常に異なるプロジェクトです。

@ matthew-何ヶ月も学習を減らし、「少ない」コミュニティがより良くなりたくないのであれば、たくさんのことを書いた後の学部長は、私たち両方にとって損失です。 それが、ブートストラップが少ないものから「sass」（https://github.com/twbs/bootstrap/tree/v4-dev）に移行した理由だと思います（最初の理由はコンパイルが速いことでした）。 最初のソースは「less」でしたが。 現在、彼らは元のソースを「sass」で記述し、それをlessに変換します（逆の場合）。

別物 ：

「適切な仕事のための適切なツール」

ここでは適用しないでください

少ない| Scss | スタイラス同様のプロジェクト。 当時人気だったものから始めましたが、今では「少ない」コミュニティは自分自身を改善したくないようです。

「少ない」の背後にある考え方は、書く量を減らし、より多くのことを行うことです。 どこかでそれは削減を行いますが、どこかでそれはより多くの書き込みを必要とします。

コメントしてくださってありがとうございます。

ファンボイッシュな時代遅れのプロパガンダ。 これらの偏った、または単に誤った発言のすべてを議論するのは時間の無駄です。

例えば：

本当に複雑な条件付きコードを作成する方法はありません。

ええ、「スパゲッティコードを書くためのツールが必要です」-このように。 このようなコードを書く場合、確かにLessは間違いなくあなたのツールではありません。

「less」は、sassやstylusとは非常に異なる「x」を実行すると思います。 他のすべては同様のことをしますが、「less」はそれが同様の種類ではないと主張します。 :)

@aukgit

「less」は、sassやstylusとは非常に異なる「x」を実行すると思います。

_なぜ_同じことをする必要がありますか？ たとえば、 [1]と[2]を参照して、設計間の主な違いを見つけてください。 したがって、この概念は気に入らないかもしれませんが、気に入らないツールを使用するように強制される人は誰もいません。

今、私はそれを取得します。 ありがとう。 本当に、それは本当にこれまでで最も誤解されている言語です。 ダグラス・クロックフォードが言うように、JavaScriptでさえ誤解されていません。

人々はjsで間違いを犯しますが、多くの認識があります。 'Less'の場合​​、最初のページ（less.org）に、lessとは何かを説明する必要があります。

ありがとう。

ミクセンを書いた：

以下：

.if-value-present(@attribute; <strong i="7">@value</strong>: '') {
    .x (@value) when not (<strong i="8">@value</strong> = '') {
        @{attribute}: @value;
    }

    .x(@value);
}

.if-value-present-multi(@attributes; @values) {
    .iter(@i) when (<strong i="9">@i</strong> > 0) {
        .iter(<strong i="10">@i</strong> - 1);
        // loop

        <strong i="11">@attr</strong>: extract(<strong i="12">@attributes</strong>, @i);
        <strong i="13">@value</strong>: extract(<strong i="14">@values</strong>, @i);

        .if-value-present(<strong i="15">@attr</strong>, @value);
    }

    <strong i="16">@len</strong>: length(@values);
    .iter(@len);
}
.x {
    <strong i="17">@var</strong>: c1,c2, c3;
    <strong i="18">@val</strong>: v1, '', 'wddww';
    .if-value-present-multi(@var;@val);
}
.x{
    .if-value-present(content, 'new val');
}

CSS出力：

.x {
  c1: v1;
  c3: 'wddww';
}
.x {
  content: 'new val';
}

「少ない」コミュニティがより良くなりたくないのなら、それは私たちの両方にとって損失です

「私が欲しいX機能がサポートされていない」==「より少ないコミュニティはより良くなりたくない」と考えるのは間違いだと思います。 それは私たちをどこにも連れて行かない。

制御フローの改善に取り組むために、Githubについていくつかの議論があります。 実際、このスレッドは拒否されず、＃2072にマージされました。 閉じた3年前のスレッドについてコメントしました。 ＃2072とは少し違うかもしれないと思った他のアイデアもありましたが、本質的にはそうではないと確信していました。

今では、より良い機能がないようです

Lessには_more_機能がありません。これは本当です。 これは仕様によるものです。 これは、1日でLessを学習できるようにするためであり、Lessの機能は一般的なユースケースの99％をカバーしています。 Sassの学習曲線は急です。 Sassは非常に多くの機能が肥大化していたため、コンパイルを続行できるようにするためだけに、低レベルのCベースのコンパイラを構築する必要がありました。 これは素晴らしい成果です。 しかし、結局のところ、スタイルシートを作成しているだけの何かの素晴らしい証拠ではありません。

現在、彼らは元のソースを「sass」で記述し、それをlessに変換します（逆の場合）。

本当ですが、それは複数の要因に基づいており、それらが何であるかを尋ねることができます。 今日、LessでBootstrapを使用している人がたくさんいるので、Lessユーザーを放棄するのは間違いだと個人的に感じています。

結局のところ、条件文を書くために必要なフープについてのあなたの不満は_間違っていません_。 ここで提供されている例は、単に言語に適合していません。 ＃2072のスレッドをお読みになることをお勧めします。

（これは実際には少しオフトピックですが、私はただ疑問に思っています）

<strong i="7">@var</strong>: c1, c2, c3;
<strong i="8">@val</strong>: v1, '', 'wddww';

そして、 .if-value-present-multiを呼び出す以外に、これらの変数をどのように使用するでしょうか。
（そして、これらの変数は他の何かに使用されます）代わりに、プロパティと値のペアだけを使用するのは意味がありません。例：

<strong i="14">@rules</strong>:
    c1 v1,
    c3 'wddww';
   // no need for c2 since it has no effect

さらに、 .x {content: 'new val'}だけが必要な場合、 .x {.if-value-present(content, 'new val')}を書く目的は何でしょうか。 そして、何もしない場合は.x {.if-value-present(content)}と書きますか？

（正直なところ、私は[1]を見ましたが、1つだけコメントすることはありません：（_時間を節約するために_） elementsやlesshatなどの古代のライブラリを破棄することを検討してください-そして代わりにautoprefixerを使用してください。しばらくの間、どちらのCSSプリプロセッサにもベンダープレフィックスライブラリは必要ありません）。

これは通常、「機能要求」のほとんどが「XY問題」で発生する方法です。 （関連分野での同様の失敗の他の良い例：＃1400と＃1894、機能が完全に役に立たないというわけではありません（したがって、両方が開いたままになります）が、実際のユースケースを尋ね始めると、通常は明らかになりますXを解こうとしてYが間違っていた）。

さてここにユースケースがあります：
最後のパラメータが指定されていない場合は、3つのパラメータを使用してmixnを作成しようとしました。その場合、mixn内にその属性が作成されるため、条件が役立ちました。

ここではhttps://github.com/aukgit/WeReviewProject/blob/master/WereViewApp/Content/Less/remixens/sensitive/sensitive-placements.less同じmixenを何度も何度も実装しようとしましたが、それを達成できました。非常に簡単に条件付き。

私は今それを手に入れました..ありがとうございました。

@aukgitこれらのミックスインを簡単に折りたたむことができるはずです。

https://gist.github.com/matthew-dean/e617bc1f71528843ef9fa73d70427bcf

@ matthew-deanに時間を割いて、私を助けてくれてありがとう。 :)私はあなたにとてもいっぱいです。

:)

「sass」は少ないよりはましだと思います。 すでにif-elseがあります。

どちらの言語にも独自の問題があります。

動的なインポートがないこと、そしてそれを実装することに消極的であることは、私がSassからLessに切り替えたい主な理由です。 何年もの間、この機能を備えたものは少なくなっています。

ただし、従来の制御構造（FORループやIF-ELSEステートメントなど）とクリンジに値する構文がないため、この動きを妨げることがあります。

岩と固い場所の間に立ち往生しているような気がします...

@ jslegers ＃249と同じコメント。 lessには、v1.x以降、さまざまな形式の条件付き制限があります（新しいバージョンではますます増えています）。

@ seven-phases-max

私は、IFステートメントの代替としてのガード付きミックスインとLessのループの代替としての再帰的ミキシングを認識しています。 しかし、Lessの制御構造に関するドキュメントで見つけたのはこれだけです。 そして、多くの言語でプログラミングの経験を持つ人として、私は彼らの構文が混乱し、正直に言うと、非常にやりがいのあるものだと感じています。

言及する価値のあるもの以外に他の制御構造がある場合、私はそれらをドキュメントで見つけることができませんでした。

とにかく、...のようなもの

scss a { <strong i="11">@if</strong> $time == morning { color: red; } <strong i="12">@else</strong> if $time == afternoon { color: blue; } <strong i="13">@else</strong> { color: grey; } }

...または...

scss <strong i="17">@each</strong> $author in $list .photo-#{$author} background: image-url("avatars/#{$author}.png") no-repeat

...またはこれ...

scss <strong i="21">@for</strong> $i from 1 through 8 { $width: percentage(1 / $i) .col-#{$i} { width: $width; } }

...私の意見では、Sassの方が、Lessのガードされたミックスインや再帰的なミックスインと似たようなものを書くよりもはるかに読みやすく、はるかにエレガントです。

そのようなステートメントの欠如とLessの全体的な読みにくい構文（Sassと比較して）は、私がSassに固執することを好む2つの主な理由であり、私のプロジェクトの1つでLessを検討することすら気が進まない。

そして、SassがLessよりもはるかに人気が高まっていることを考えると、そのように感じているのは明らかに私だけではありません。

@jslegers例として、投稿する前に、すでに利用可能なものを確認してください。
残りの部分（人気など）については、このように単純化された方法で何かを議論する意味はありません（Stylusにはこれがすべてありますか？）、Lessが他のCSSプリプロセッサを置き換えることもクローンになることも宣言されていません。 そして最後に、最も一般的な間違いは、何かの人気がその何かの作者の主要かつ唯一の目標であると考えることです。

それらを投稿する前に、すでに利用可能なものを学ぶようにしてください。

文書化を改善するか、探しているものが見つからない場合は、探しているものを直接指し示すようにしてください。

残りの部分（人気など）については、このように単純化された方法で何かを議論する意味はありません[...]そして最後に、最も一般的な間違いは、何かの人気がその作者の主要かつ唯一の目標であると考えることです。

参考までに、私は人気が品質や有用性の強力な指標であることを暗示したことはありません。 実際、多くの場合、その逆です。

それでも、なぜ人々がLessからSassに移行するのかを見ると、それはかなり簡単です...

個人的には、通常の「PHPスパゲッティが欲しい」（上記の間違ったツールに関する投稿を参照）以外は何も見えず、2012年も数えていません（これらの例のほとんどは、現代のLessではかなりコンパクトになることをすでに示唆していますが、起きたくないようです）。
しかし、気にしないでください。通常、私は明確な誤った情報を主張するだけです。何かが起こるか起こらないかについての個人的な意見の議論は、完全に私の興味の対象外です。

個人的にはいつもの「PHPスパゲッティが欲しい」以外は何も見えません

Sassの代わりにLessを使用すると、もっと複雑なことをしたいと思うとすぐに、コードが必然的に「PHPスパゲッティ」のように見えるようになります（PHPがスパゲッティコードの縮図だと思う場合は、明らかにABAPプログラミングを行ったことはありません）。基本的な変数やミックスインよりも、しかし私はここで間違っていると考えたいと思います。

これらの例のほとんどは現代のLessではかなりコンパクトになることをすでにほのめかしましたが、目覚めたくないようです

それなら、私を起こして、私の無知から私を解放することができる情報源を私に与えるために努力してみませんか？

誰かが私を間違っていると証明することほどエキサイティングなことはほとんどありません。 私の経験では、それが成長するための最良の方法です...