Less.js: 数学の扱い方

物事を大きく変えたり、画板に戻ったりしたくないと思います

はい、これを開始することを提案したのは、3.0で「デフォルト」の厳密な計算が必要な場合にのみ、現在のものよりも軽いものを発明する必要があるためです（そして、新しい--alt-strict-mathを導入せずにすべての問題を修正できる可能性がありますfontようなハードコーディングソリューションの背後に隠れた問題があるため、 --alt-strict-mathオプションは非常に非現実的です...）。

私はその成長に気づいていませんでした

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

:(

現時点では、最初にstrictMathsを拡張することに賛成だと思います。

• オフ
• 分割
• の上

次に、2.0.0の場合、デフォルトを除算に設定します

そう..

メディアクエリ-オフの場合、サブノードの分割に切り替えます
フォント-オフの場合、サブノードの除算に切り替えます
calc（-オフまたは除算の場合、サブノードのオンに切り替えます

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

うん、私は彼らが_any_「shorhandproperty」で「shorthandvalues」（すなわちx/y ）を許可することに向かっていると思います...

関連： https ：

別のオプション..計算呼び出しを処理しますが、単位がそれを可能にする場合のみです。
calc（1％+ 2％）=> 3％
calc（100％-10 px）=>変更なし

これによりcalcは修正されますが、＃1627および関連するものは修正されません。
はい、 calc(100% - 10 px) => unchangedはcalcソリューションになる可能性がありますが、これはless-heavy-than-parens-everywhereソリューションの必要性をキャンセルするものではありません。

厳密な計算が再検討されている場合は、 percentage()ようなLess関数の中に余分な括弧を必要としないことをお勧めします。 厳密な計算をオンにすると、引数を二重にラップする必要があります。 これにより、 percentage(16 / 17)とpercentage((16 / 17))両方が有効になるため、混乱や見つけにくいバグの可能性が大幅に減少します。

@calvinjuarez V2は、プラグインが環境に任意の数の関数を追加できるプラグインサブシステムを提供します。この意味で、コアは、そのような組み込み関数が単一の値または式を期待するかどうかを判断できません。 16/17を受け入れることができ、 16/17関数に渡される前に評価するのは正しくありません（大まかに言えば、内部的には少し複雑です）。

その文脈では、 ./変更は私のお気に入りのようですが、非常に劇的な変更になることは理解しています（ (/)と比較した場合、カウントしないと、 .前に空白が必要になりますたとえば、 16 ./17あり、 16./17で16 ./17ありません。

現在有効なcssを壊すことが少ないもう1つのことは、背景の省略形です。

background: url(image.png) 50%/300px no-repeat;

現時点では、最初にstrictMathsを拡張することに賛成だと思います。

オフ
分割
の上
次に、2.0.0の場合、デフォルトを除算に設定します

申し訳ありませんが、2.0がリリースされる前にこれに応答しませんでした。 それは良い本能だと思います。 裸の除算演算子は、CSSの多くと単に競合し、人々がより多くのCSS3機能を使用するにつれてますます競合します。 そして、多くの場合必要ではないので、すべての数学に括弧を必要としないという人々の反発を理解しています。

@ seven-phases-max

16/17を受け入れることが許可されている場合、関数に渡される前に16/17を評価すると正しくなくなります。

厳密に言えば、そうです、それは絶対に正しいです。 これは、特にカスタム関数の場合、関数に到達する前に評価しないでください。 ただし、それが理にかなっている場合は、関数がこのような引数を処理することを選択できるようにするのが賢明だと思います。 したがって、percentageはテキスト引数として16/17を受け取り、percentage関数はヘルパー関数を呼び出してテキストが数学であるかどうかを確認できます。 パーセンテージの場合、引数はあいまいではありません。 ここではCSS3宣言は無効です。 したがって、他のユーザー定義関数も同じように動作する可能性があります。有効な数学方程式の引数を評価することを選択します。 したがって、この場合、厳密な計算によって二重括弧が「強制」されるとは限りません。 これは、厳密な数学の考え方にいくらかの反発を引き起こし、必然的に、すべての場合において冗長でなければならないことを示唆していると思います。

--mathオプションは次のようになります。

• いつも
• 分割（デフォルト）
• 厳しい

したがって、-strict-math = trueを廃止し、-math = strictのエイリアスにすることができます。

ただし、それが理にかなっている場合は、関数がこのような引数を処理することを選択できるようにするのが賢明だと思います。

それらはすでに許可されています（ percentage(16 / 17)とpercentage((16 / 17))が--strict-math=onどのように機能するかをテストするだけです）。
どの関数も使用しませんが：

次に、パーセンテージ関数は、テキストが数学であるかどうかを確認するために、ヘルパー関数を呼び出すことができます。

この方法では、ほとんどの場合、独自の関数コードが1行（！）であるのに対し、各関数にはそのextra-helpers-conversion-arg-checking-smart-arg-handling-stuffの最大20行が必要になるためです。

各関数には20行余分に含める必要がありますか？ どのように理解しますか？

パーセンテージがすでに単一の括弧で厳密な計算で機能している場合、 @ calvinjuarezの問題を理解していません。 あなたはあなたの応答で、単一の括弧が達成できなかったことを暗示しているように見えました。

各関数には20行余分に含める必要がありますか？ どのように理解しますか？

これは典型的な誇張です：多分5、多分10、多分20 ...実コード/補助コードの比率-> 0場合、誰が正確な数値を気にするでしょう。 （実用的なアプローチを取ると、 NaN%を生成する代わりに（今のように）エラーをスローするだけでpercentage(16 / 17)停止し、変換を実行しようとはしません...この方法でもまだですが4行の余分なコード-まあ、多かれ少なかれ受け入れられると思います:)

私の最初の返答は、彼がこの16/17 -> (16/17)変換が（関数ではなく）コンパイラー自体によって暗黙的に実行されると想定していることを暗示していました。

オプションといえば。 完璧な世界では、これに対するオプションはまったくないことを夢見ています（つまり、これが唯一であり、残りは非推奨としてマークされ、最終的に削除される必要があります）...これらの追加オプションはすべてコードベースを非-保守可能..小さなワンライナーの修正/変更でも、予測する必要のあるエッジケースの数と、実行する必要のあるテストは指数関数的に増加します...（ほとんど理由はありません）。

私はそれが次のようなものになるだろうと思っていました：

percentage: function(...) {
  Helper.convertMath(arguments);  // a function that doesn't need it doesn't call it
  // ... the rest
} 

オプションといえば。 完璧な世界では、これにはまったく選択肢がないことを夢見ています

同意します。 しかし、短期的にはオプションが必要になります。 特に、厳密な数学やレガシーの振る舞いから逸脱している場合はなおさらです。 「よりスマートな数学」オプションを完成させれば、両方とも非推奨としてマークすることができます。

Helper.convertMath(arguments);

argumentsは楽観的すぎます。
せいぜい（ percentageだけでなく、とにかく役に立たないものを数えるだけ

some: function(a, b, c) { 
    a = convert2number(a, "Error message when fails"); 
    // b is not a number for example
    c = convert2number(c, "Error message when fails"); 
} 

しかし、それは私のポイントは、実際に、私が意味することは、おそらくのようなものではありませんでした。これは常にある間、/このようなコードを書くために、誰も気に可能であった...（数限定の例外を除いてのように）...

ええ、私はあなたを取得します。

percentage(16 / 17)エラーをスローするだけ

確かに改善になるでしょう。 （ NaN%が有用な出力になるとは思いもしません。）

どの関数が引数について賢くしようとするかについては、すべてを予測しようとする理由はありません。 @ matthew-deanが示唆するヘルパー関数は、特定の関数をよりスマートにするために機能要求が行われ、議論されるので、かなり簡単に実装できます。

実際、最初から、数学関数だけが引数について賢くなければならないと思います。

編集：実際には、数学関数に渡される引数は1つだけです。

これの状況はどうですか？ LESSが無効なCSSプロパティを数学として解析しようとしているという苦情が寄せられています。 例： lost-column: 1/3;ブレーク。

また、 http： //www.w3.org/TR/css-grid-1/#grid-template-rowcolはLESSでは機能しないようです。

誰かがこれにパッチを当てることができるので、誰かが明示的にLESSを使用してプロパティを除算し、それを括弧などでラップする必要がある場合はどうでしょうか。

@ corysimmons ＃2769でこれを聞いて、答えを得ませんでしたか？ o_O

これが最初に起こったときに私たちが議論しなかったことの1つ。 本当の数学の対立は除算だけのようです。 そして、CSSの「分離」文字を本質的に「転用」しているため、分割は本質的に問題です。

除算をさまざまな方法で「ラップ」したり、すべての数学をラップしたりするのではなく（この問題の最初の解決策として）、なぜ私たちが明白なことについて話さなかったのか疑問に思います。したがって、明らかにa）コードがあいまいになり、b）競合が発生します。

これを消化する時間ができた後、数学を括弧で囲みます。たとえそれが単なる除算であっても、数学がすでに括弧で囲まれている場合は、_still_によってあいまいさが生じます。 （これは、括弧が「数学ラッパー」の間違った選択であることも意味している可能性があります。）

では、除算演算子として/を廃止してみませんか？ これが一般的な除算記号であることは知っていますが、CSSを拡張するためにLessが行った構文上のトレードオフは他にもあります。 そして、基本的に、Lessによって最初に作成された問題を、単一のスラッシュを使用して回避しようとしていることは明らかです。 あいまいさを作成し、あいまいさを逆転させようとしています。

公平を期すために、他の数学記号はすべてCSSの他の部分で再利用されます。それは、数学でのそれらの使用があいまいさを引き起こさないということだけです。

私はいくつかのアイデアを提案するつもりでしたが、見よ、除算の標準的な代替文字がすでにあります。 キーボードにない÷除いて、私はこれを見つけました：

除算記号も数学的には比率記号と同等であり、通常はコロン（:)で示され、「isto」と読みます。 したがって、任意の実数xおよび任意の非ゼロ実数yに対して、この方程式は次のようになります。

x÷y = x：y

言い換えると：

lost-column: 1/3;   //  value
lost-column: 1:3;   // division 

数学でコロンを使用するには、パーサーを少し調整する必要があることはわかっていますが、数学的には正しいようです。 私はより良い代用品を作る他のシンボルを考えることができません。 たぶん|を2番目の選択肢として？ しかし、それはもっと恣意的でしょう。

考え？

_あるいは_、次のように、括弧や括弧内の除算記号をサポートすることもできます。

lost-column: 1/3;   //  value
lost-column: 1:3;   // division 
lost-column: (1/3);
lost-column: [1/3];

うん、そういうわけで私は最初に./から始めました（Matlabのvector-div演算子に触発され、それは2つの記号ですが、視覚的には軽量のドットのためにおそらく最も軽いですが、ドットの台無しが少ないという文脈ではそうではありません素晴らしいアイデア）。
: -これはデイジーをもう一度プッシュします。このシンボルはあまりにも多くのCSSコンテキストで使用されています。 実際、すでに矛盾する構文があります。

.foo(<strong i="9">@a</strong>: 1, <strong i="10">@b</strong>: 2) {
  result: <strong i="11">@a</strong> @b;  
}

bar {
    <strong i="12">@b</strong>: 4;
    .foo(<strong i="13">@b</strong>:3); // would mean both @second-parameter:3 and 4/3
}

@ Seven-phases-maxああ、はい、くそー。 キーボードだけが大きかった場合。 はい、除算の2文字のシーケンスは避けられないようです。 スレッド全体を読んでから久しぶりだったので、忘れてしまいました。 ./それは本当に悪くはありません。 あなたと@lukeapageの両方が

読み返して、この時点まで：

それはまた、前に空白が必要ですされてカウントされません. 、例えば16 ./17なく16./17

同意するかどうかわかりません。 はい、技術的には16.は有効な番号ですが、誰かがそのように書くのは奇妙なことです。 空白かどうかに関係なく、16を17で割る必要があると思います。

完璧なオプションはありませんが、a）デフォルトで除算に/を使用し、b）常に括弧を必要とするよりも優れていると思います。 （過去の私の立場にも関わらず、私もそうです。特に他の括弧内では、それは一種の迷惑です。特に、私の知る限り、除算のためにのみ必要なためです。はい？）

空白かどうかに関係なく、16を17で割る必要があると思います。

はい、確かに。
もっと考えてみると、 ./がパーサーに追加のトリックを加えることを期待しています（数値解析は./前に停止するために追加の注意が必要ですが、現在は常に.終わります）。

そして特に、私の知る限り、それは除算のためにのみ必要とされるからです。 はい？）

はい、正確に。 calc内のコードは数えませんが、これについては、 @ lukepageによって提案された解決策でうまくいくはずです。

（技術的には、将来、CSSカラー操作関数の構文を維持する場合、 +, -, *さらにあいまいになる可能性がありますが、値が* 20%形式であるため、これはそれほど劇的ではありません（したがって、それらは明らかに評価の低いexprとして検出できます）。現在(* 20%)ような値は解析エラーを引き起こすため、これらのすべての楽しみはとにかく解析の変更が必要になります）。

多分...私たちはこれについてすべて間違って行ってきました。 （私は「厳密な数学」機能の最初の熱心な支持者だったので、間違いなく私をその中に含めます。）

私たちは数学を普遍的に機能させようとしていますが、実際にはそうする必要はありません。 つまり、数学を実行してはならないことが明らかな場合に、数学を実行しようとしています。

calc(100% - 10px)例が最も明白な例です。 ユニットをキャストしない限り、実行できる/実行すべきLess計算はありません。これは、Lessがデフォルトで実行を停止することに同意します。 ¹

例として使用されているフォントの省略形プロパティを見てみましょう。

font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif;
font: italic bold 12px/30px Georgia, serif;

これに対する現在の回避策は、フォントプロパティのstrict-math: onを有効にすることです。 しかし...なぜLessはそもそも計算を行う必要があるのでしょうか。 確かに、 13px/150%は数学では有効なステートメントですが、Lessでは有効なものとして扱うのが妥当ですか？ 12px/30pxあなたは有効な数学ステートメントとして扱うことができますが、そうすべきですか？ ²

つまり、Lessでは、単位の数学演算は、単位ではなく_integers_と_floats_によって実行する必要があります。 私たちは、人々が実際にこのように数学を書いているかのように、これらを有効な数学ステートメントとして扱っています。 しかし、それがどのように真実であるかはわかりません。

つまり、誰かに13px/150%を13px/1.5と書くように要求するのは合理的です。 また、 12px/30pxが数学演算として意味をなさないという事実を無視しても、それが意味をなさないことを知る必要はなく、 fontをホワイトリストに登録する必要もありません。 。 少ない作者が数学演算をしている場合、彼らはそれを12px/30と合理的に書いているでしょう。 それが合理的であるだけでなく、_彼らがそもそもそれをどのように書いているか_である可能性が非常に高いです。

ミックスインを作成したり、1つのブロック内で次のようなものを使用したりすることはよくあることです。

width: <strong i="5">@size</strong> / 2;
height: <strong i="6">@size</strong> / 2;

なぜ私はそれをこのように書くのでしょうか？ _誰でも_このように書いていますか？

width: <strong i="10">@size</strong> / 2px;
height: <strong i="11">@size</strong> / 2px;

@sizeがpx単位である場合、操作_sort of_は意味がありますが、それにもかかわらず、LESS / CSSの領域では、除数が後者の場合に数学を実行しようとすることはあまり意味がありません。は単位付きの値です。 2つ目は数学のようには見えません。 CSS値のように見えます。

乗数や除数が単位の値であるときに、乗算や除算（あいまいさのために除算だけでなく、論理的な一貫性のためにも乗算）の数学演算をやめれば、この問題はほとんどなくなると思います。 対照的に、単位は足し算と引き算には論理的ですが、おそらく必要ではありません（これが現在の方法です）。

<strong i="18">@pad</strong>: 2px;
width: 10px + @pad; 

ただし、ある値と単位を別の値に加算/減算する場合、Lessはそれをそのままにしておく必要があります。

<strong i="22">@val1</strong>: 100%;
<strong i="23">@val2</strong>: 10px;
width: calc(<strong i="24">@val1</strong> - @val2);

// output
width: calc(100% - 10px);

加算/減算（または整数/浮動小数点数）に一致する単位を要求し、単位に対する数学演算で整数/浮動小数点数を要求する（単位を乗算/除算しない）と、99％のあいまいさが解決され、新しい記号がなくても有効な数学演算が可能になります。

たとえば、これらのルールに基づいて、背景の省略形は問題ありません。

background: no-repeat 10px 10px/80% url("../img/image.png");

%はCSSユニットです。 pxは別のCSSユニットです。 したがって、数学はありません。 特別な例外はゼロです。

background: no-repeat 0 0/80% url("../img/image.png");

誰かがゼロを別の数値で除算している、または数値をゼロで除算しているように見える場合は、そのまま安全に出力できると思います。

境界半径、同じこと：

border-radius: 30% / 20%;

少ないとパスになります。 誰かが数学をするつもりなら、それを書く適切な方法は次のようになります：

border-radius: 30% / 0.2;

border-radius例のように、有効なCSS値には両側に単位が必要になるため、これらの区別を行うことで、数学演算をCSS値にすることはできません。 重複/あいまいさはありません。

私が考えることができる1つのケースを超えてください、そして他のものがあるかもしれません：

font: 10px/1.5;

行の高さを単なる数値として表すことができます（通常はそうする必要があります）。 （しかし、おそらくフォントの省略形を使用するべきではありません。）しかし、それを1つのケースに減らした場合、それはかなり良いことです。 font （フォント値内の内部関数を除く）に対して厳密な計算をオンにすることは、問題のない解決策です。 （より良いものがあるかどうかはわかりませんが、機能します。）これらのフォントの省略形の値は通常、インポートされたUIスタイルライブラリ、CSSリセット、またはカスタムフォントスタイルシートに表示されるため、最も害の少ないソリューションです。

したがって、厳密な数学の使用はまだありますが、これらの変更により、それほどではなく、将来的にはオプションとして必要なくなる可能性があると思います。

ギャラリーの回答/コメントを歓迎します。

¹ _私は、@ コメントと、それへの@ Seven -phases-maxのリンクが、この方向に私が考えさせられたものであることを明確にする必要があることに気づきました。
² _例を見ながら理解したように、フォントに対してstrict-mathをオンにすることは避けられない解決策かもしれませんが、残りのロジックは当てはまると思います。_

いくつかの歴史的な文脈のために、Less.jsが最初にリリースされたときのユニットのキャストはそれほど問題ではなかったことに注意することが重要です。 calc()は実装されておらず、 backgroundとborder-radiusは有効な値としてスラッシュがありませんfontが物事をつまずかせた唯一の場所だったと思います（皮肉なことに、それはまだそうであるかもしれません）。

私の唯一の懸念は実装側です。たとえば、 calc(4px + 2rem + 20%) （実際の単位は関係ありません）の場合、最初の加算はもはや数値ではない結果になるため、2番目の加算ハンドラーはその入力をエラーをスローする必要があるnot-a-number + 20%ステートメント。 おそらく大きな問題ではありませんが（余分なタイプ/タイプフラグを追加することで解決できます）、それでも調査が必要です。

そして、他の懸念は、えーと、確かではない、「安定性」ですか？ つまり、明示的な数値の場合、結果は非常に明確に見えますが、変数の場合、結果は非常にあいまいに見え始めます。例： border-radius: 10px <strong i="8">@a</strong> / <strong i="9">@b</strong> 30px; - @aと@bが表示されるまで、これが何を意味するのかわかりません。

そして、はい、 fontまだ問題のままです（他の速記プロパティは両側でユニットを使用しているようですが、次に何が起こるかわかりません（＃2769のようなものも数えます）... A fontようないくつかのグッズがあり、再び壊れているように見えます）。

PSもう1つの問題（おそらくマイナーな回帰）次のような値があります：

border-radius: 10px / auto;
border-radius: 1px inherit / 2px;
background: ... center / 80% ...;
// etc.

つまり、すべてが機能するためには、現在のincompatible-div-operand-errorsを無効にして、 foo/bar 、 1x/bar 、およびfoo/1xがw / oaを通過できるようにする必要があります。エラー。

私の唯一の懸念は実装側です。例：calc（4px + 2rem + 20％）の場合（実際の単位は関係ありません）

これが私が言っていることです。 実際の単位が重要です。 関係なく、それをそのままにしておくべきではありません。 4px + 2remはブラウザでは意味がありますが、Lessでは意味がありません。 それが意味をなさないときにそれを追加しようとする理由はなく、これらのアドオンの問題を引き起こします。

例： border-radius: 10px <strong i="10">@a</strong> / <strong i="11">@b</strong> 30px ; - @aと@b定義が表示されるまで、これが何を意味するのかわかりません。

これは、スタイル作成者を自分自身から保存できない場合です（最初の例と同じですが、誰かが実際に何らかの理由でピクセルにレムを追加しようとした場合）。 誰かが自分のLESSコードを記述して、従うのが混乱する可能性のある、あらゆる種類の既存の例があると確信しています。 それはどこにでも存在します。

私が提案しているこれらの数学のルールで、考慮してください：
calc(4px + 2rem - 2px)

それをcalc(2px + 2rem)として計算することはできません。これは実際には完全に問題なく、実際には正しい値の出力です。 現在、Lessはそれをcalc(4px)として計算しますが、これは正解でも有用な答えでもありません。 （はい、ユニットを削除する場合は現在正しいですが、ユニットは無意味ではなく、いくつかの場合を除いて、相互運用性はありません。）Lessは2px + 100%を102pxとして計算します。その結果、誰もそれを結果として望んでいない可能性がある場合。

すべてが機能するためには、現在のincompatible-div-operand-errorsを無効にして、foo / bar、1x / bar、およびfoo / 1xがw / oaエラーを通過できるようにする必要があります。

私はそれが実際にそれを扱う最も正直な方法だと思います。 関数と同様に、Lessの結果がない場合は、通過する必要があります。 /は複数のプロパティの値の有効な区切り文字であるため、特定のプロパティのホワイトリストに記載された値を追加しない限り、Lessはそれが有効でないことを知ることができません。 （いいえ。）その時点で、結果は悲劇的ではありません。 パススルー値がブラウザで無効である場合、それは視覚的に明らかです。 値が有効な場合は、Lessがわからないためにエラーをスローするよりも、値をブラウザに渡そうとする方がよいようです。

calc（2px + 2rem）として計算できる/計算する可能性が少ない

これには、やり過ぎになる新しい最適化式ハンドラーが必要になるため、決してそうなることはありません（基本的に、 4px + 2rem - 2pxは(4px + 2rem) - 2pxとしてツリーに格納されるため、 2px + 2remを取得します） 4px + 2rem - 2pxをそのままにしておくことは問題ありません（後4px - 2px + 2remを実行すると、すべて最適化されます）。

しかし、私がその発言で実際に意味したのは、次のようなものです。

foo / bar、1x / bar、foo / 1xがw / oaエラーを通過できるようにします。

つまり、expr.evaluatorの(4px + 2rem) - 2pxはfoo + 2pxに似ているので、機能するためには、そのようなものでもエラーが発生することはありません。
実際、私はfoo/bar, 1x/bar, foo/1xをテストし、エラーなしですでに合格しています（奇妙なことに、スローすると思っていました）が、他の演算子はあらゆる種類の奇妙な結果をもたらします（ただし、実際には重要なことは何もありません。それぞれのケースを修正するだけです。一つずつ）。

これには、やり過ぎになる新しい最適化式ハンドラーが必要になるため、決してそうなることはありません（基本的に、4px + 2rem-2pxはツリーに（4px + 2rem）-2pxとして格納されるため、2px + 2remを取得するにはすべての有効なシャッフルを試行するための並べ替えエンジンになること（この特定のケースでは簡単ですが、オペランド/演算子が増えると非常に複雑になります）。

なぜシャッフルするのですか？ 同じ優先順位レベルで演算子をフラット化し（したがって、ツリーはSum(4px, 2rem, -2px) ）、互換性のある単位で用語を収集し（おそらく、事前に単位を正規化することによって）、各部分を単純化します。 これは記号代数であり、単位は独立変数として扱われます。

私はそれを自分で書きたいのですが、おそらくよりよくテストされ、完成する可能性が高いライブラリが

ポイントは、これを解決するのは簡単な問題ではありませんが、より一般的な問題はすでにかなりうまく解決されており、そのようなサブシステムは他の方法でLess.jsに役立つ可能性があります。

同じ優先順位レベルで演算子をフラット化します（したがって、ツリーはSum（4px、2rem、-2px））、

そして、ある式ツリーが実際にフラット化可能であると考えるコードを正確に作成するのは何ですか？ （つまり、私の「苦しみ」は、特定の控除アルゴリズムについてではなく、「フラット化」を含む「すべてを試す」ためのショートカットです）。

しかし、おそらくよりよくテストされ、完成する可能性が高いライブラリがたくさんあります。

あなたが本気かどうかはわかりません。 したがって、Lessツリーを外部ライブラリツリーに変換して元に戻す（これらのJSライブラリのいずれもCSSユニットを処理できないことを除いて）すべてのコードは、実際に最適化する特定の4px + 2rem - 2pケースの価値があると思いますか？ うーん...

だから、まったく問題ありません（私はそれが決して価値がないというだけで不可能だとは言いませんでした）-試してみて、PRは大歓迎です。
（また、おそらく重要な場合に備えて、部分式の最適化は、このチケットの目標でさえなく、上位3つでもないことに注意してください）。

そして、ある式ツリーが実際にフラット化可能であると考えるコードを正確に作成するのは何ですか？ （つまり、私の「苦しみ」は、特定の控除アルゴリズムについてではなく、「フラット化」を含む「すべてを試す」ためのショートカットです）。

パーサーは、コンテキストが「長さ」などであるかどうか、およびサブツリーを「長さ」として解釈できるかどうかを判別します。

あなたが本気かどうかはわかりません。 したがって、Lessツリーを外部libツリーに変換して元に戻すためのすべてのコード

構文ツリーに解析する必要があります。 そこから、代数式を表す文字列を出力するのは比較的簡単です。 戻るのは難しいかもしれません。文字列から再度解析する必要があるかもしれません。あるいは、そうです、外部ライブラリのツリーを取得する必要があるかもしれません。 難易度は、選択したライブラリによって異なります。

（これらのJSライブラリのどれもCSSユニットを処理できないことを数えません）

単位を代数変数に変換するだけです。 式が記号形式の場合でも、置換（ mm -> px ）を実行できます。

最適化する特定の4px + 2rem-2pケースの価値は実際にありますか？

私は式の最適化のための代替案を作成しています。これは（Less自身のコードが解決しなければならないアルゴリズムの問​​題として）それほど難しくなく、あなたが言ったことよりも一般的に有用です。

代数の単純化は、括弧で囲まれた部分式を使用して問題を解決し、Lessがより多くのマシーな機能を追加できるようにします。

試してみて、PRは大歓迎です。

試してみます。 私は今日Lessを調べ始めたばかりで、プロジェクトを完了するのに問題があるので、おそらくPRが出ないことを認めます。

また、念のために、部分式の最適化はこのチケットの目標でさえなく、上位3つでもないことに注意することがおそらく重要です。

知っている。 私はその理由の1つでここにいました。 なぜそのようなかみ傷？

なぜそのようなかみ傷？

ええと、多分.​​..もしそうなら-私の謝罪（私は努力と時間にショックを受けすぎて、誰かがほとんど存在しないcalc(4px + 2rem - 2px)問題を解決するために専念する準備ができているようです。おそらく私たちは非常に異なる概念を持っています軽量性の）。

そして、Lessがより多くのマシー機能を追加できるようにします。

いくつか挙げていただけますか？

ほとんど存在しないcalc(4px + 2rem - 2px)問題を解決する

は？ 少ない人はそれをまったく処理できません。 [対処されている内容を誤解したため、残りは削除されました]

提案を単純化/言い換えるには-数学の変更は次のようになります

1. 足し算と引き算は、同じような単位でのみ計算されます。 例： 1px + 2px = 3px 、 1px + 1vh = 1px + 1vh
2. 除算と乗算は、単位のない除数/乗算器でのみ計算されます。 例： 10px/2 = 5px 、 10px/5px = 10px/5px
3. 単位のない値の比率は、＃2と同様に扱われます。例： 1/3 = 1/3
4. 簡単にするために、部分的に無効な部分式を含む式は、無効な数式として扱い、そのまま出力することができます。 例： 1px + 2vh / 2 = 1px + 2vh / 2

この提案は、（このスレッドから）以下を解決します。

• font: 10px/5pxおよび同様の（比率）構文（計算なし）
• calc(100vh - 30px) （計算なし）
• lost-column: 1/3および同様のカスタム比率構文（計算なし）

同時に、これらの変更により、通常の数学の使用量の99％が維持されます。 同様に、既存のunit()およびconvert()関数を使用すると、ユーザーは数学の互換性のある単位に値をキャストできます。

少ない人はそれをまったく処理できません。

あなたは私と@leewzが上で話していることを読んでいませんcalc(100vh - 30px)とは何の関係もありませんcalc算術式を最適化すること」だけに行きます。

@ seven-phases-maxああそうだね。 ごめん。 いいえ、最適化する必要はありません。 いつ計算するかを考えてください。

この問題は、最近のアクティビティがないため、自動的に古いものとしてマークされています。 それ以上のアクティビティが発生しない場合は閉じられます。 貢献していただきありがとうございます。

問題は依然として重要であり、CSSが進化するにつれて悪化するだけなので、スレートラベルを削除します。

@ matthew-dean
ここで悪魔の代弁者を演じるつもりです...

12px/30pxあなたは有効な数学ステートメントとして扱うことができますが、そうすべきですか？

はい; あなたがすべき。 両方のサイズの比率を表すスカラー値を計算します。これは、em単位に変換するときに非常に役立ちます。

既知の基本フォントサイズが16pxで、既知の見出しサイズが24pxで、どちらも変数に隠れているとします。次に、特定のフレーバーの見出しを正しいフォントサイズで、ただしem単位で割り当てたいとします。

@fontsize-body    : 16px;
@fontsize-heading : 24px;

// ( ... and then somewhere else ... )

.heading {
  font-size : unit(@fontsize-body/@fontsize-heading, em);

  // Or if dividing compatible unit values is produces a unit-less scalar
  // value ( as it really _should_ -- mind you... ),  you could prefer:
  font-size : @fontsize-body/@fontsize-heading * 1em;
}

また、互換性のある単位の除算を数式としてサポートする必要がある場合は、ケースの各半分をカバーするために、リテラルCSSを少ない数式から明確にする方法を引き続きサポートする必要があります。

当然のことながら、これには、括弧を使用して数式を強制し、デフォルトでCSSリテラルを使用することが含まれる可能性があります。 しかし、それは間違っており、エラーが発生しやすいようです。 border-radiusやfont速記など、事前に作成された多くの特殊なケースが必要であり、Lessはこれらを継続的に最新の状態に保つ必要があります。 （除算記号で同じ問題が発生する新しいグリッドプロパティのいくつかで示されているように。）

そう...

推論を裏返してみませんか？ 何かが数式のように見え、互換性のある単位がある場合、デフォルトでは数式として扱われます。 そして、あなたがそれを起こしたくないのなら...まあ; 次に、 ~"..."エスケープハッチを使用します。 結局のところ、それはまさにそれがそこにあるものです...

提案の私の現在のビジョン：

• 治療の停止/除算などどこにも関わらず、任意のuntisのと関係なく、任意のオプションの（場合を除き-それは-sm =上と同じように冗長括弧で囲まれています-必要に応じて）
  したがって、 1anything./3whateverと（オプションで） (1anything/3whatever)のみがLessによって評価されます。
• + 、 - 、 *は変更されません
• calcサブイシューは、 arithmを評価しないことで解決されます。 calc(...)内の式（ただし、繰り返しになりますが、冗長な括弧も効果がある場合があります）。

@ seven-phases-max

それに関する問題は、 /が除算演算子として信じられないほど根付いていることです。 他の記号を使用することは、ユーザーにとって難しい販売になります。 あなたは一般的なユースケースを取り上げて、ほとんど誰も使用しない例外的なユースケース（CSSの省略形では/ ）のためにそれを捨てています。

@rjgotten

それに関する問題は/除算演算子として信じられないほど根付いています。

CSSにはありません。

誰もがほとんど使用しない例外的なユースケース（/ CSSの省略形）。

今では/すでに使用されている多くのことを、と比較して、それが少ないのdiv opが完全にはるかに異例CSSよりもあるのです/それはどこCSSほんの数年前とは違って（これらの日/は、ほとんどの場合fontのみ見つかります）。

@ seven-phases-maxその上を維持していただきありがとうございます。 問題を管理するためにStaleボットを追加し、Staleをマークするためにかなりの時間を与えました。 また、「bug」と「up-for-grabs」の2つのラベルも免除しました。 ホワイトリストに登録する他のラベルなど、それに関する提案は大歓迎です。 ファイルはここにあります： https ：

問題のスレッドに戻ります...

@rjgotten
ユースケースは任意の問題を引き起こします。 議論はそれが有用であるということです。 ただし、変数をそのように構造化すると、構文で回避できる問題が発生します。つまり、@ Seven-phases-maxが指摘しているように、あいまいです。

CSSをLessの原則のガイドとして、額面通りに受け取ったとしても、計算では、12pxを30pxで割ることはできません。 Lessでこれを行うと、あいまいさの問題が発生するだけでなく、正当な理由（履歴以外）でモデルから外れます。 おそらく、Lessに欠けているものの1つは、単位値の数値を抽出する方法にすぎないため、Lessは除算のためにこの数学の魔法を実行する必要がありません。

したがって、簡単な答えは、あなたの例は次のようになるということです。

font-size : @fontsize-body/number(@fontsize-heading) * 1em

しかし、@ seven-phases-maxの提案でも大丈夫です。 calc()で_vars_を評価することはできますが、数学で

Lessの数学のテーマにはいくつかの異なる好みがあることは知っていますが、副作用が最も少なく、大規模なメンテナンスを行わずに最も簡単に推論できるものについてコンセンサスを得ることができれば、本当に素晴らしいと思います。または開発負担。

Lessの数学に対する現在の（デフォルトの）アプローチが破られているのは、私たち全員が同じページにいると思います。 そして、私たちは括弧というフィードバックを受け取りました-デフォルトとしてのすべては推論するのが簡単でしたが、面倒です。 だから私は私たちがすぐにデフォルトとして入れることができるいくつかの良い中間点を望んでいます（おそらく4.0で？）

おそらく、Lessに欠けているものの1つは、単位値の数値を抽出する方法にすぎません。

unit関数は、2番目のパラメーターを指定しない場合、実際にそれを実行します。 しかし、これは、スカラーが現在、単位が定義されていないDimensionノードタイプで実装されているという事実の副作用です。

承諾する; それは大いに役立ちますが、互換性のある単位を持つディメンションを分割することを_本当に_避けたい場合は、単位を切り離すとうまくいきます。

また、この特定のコンテキストでは、「互換性のあるユニット」の当て推量（ a/b分割のままにし、 b/cを分割しないようにするなど）に強く反対していることも付け加えておきます。
単純に〜だから：

• 例外的な処理はすべての悪の根源です（例：＃3047-以下を参照、http：//stackoverflow.com/questions/19705791-実際に無数の行すべてをステップスルーするまで、SOの問題の理由を見つけることができなかったことを思い出しますデバッガーに含まれるLessコードの）。
• そして最も重要なのは、将来性がないということです。つまり、大きな重大な変更が避けられない場合は、一度（理想的には永久に）変更することをお勧めします...そして、 a/b含む新しいCSS機能を追加するのは好きではありません。

したがって、私にとって「互換性のあるユニット」のものは、完全に無関係で直交するもののようなものです（ -su有無にかかわらず、結果のユニットについていくつかの議論があるかもしれませんが、それは別の話です）。

（オフトピック：）
そしてところで、上記の例について言えば：
あなたが持っているなら@rjgotten ：

@fontsize-body/@fontsize-heading * 1em; 

コードのどこかにあり、2つの変数のいずれかがpx 、実際にバグを使用しています:)
適切なコードは次のとおりです。

1em * @fontsize-body/@fontsize-heading;

これにより、常にhttp://lesscss.org/features/#features -overview-feature-operationsごとに明確に定義された単位が生成されます（修正される＃3047を数えますが、このバグは、あまりにも多くの人によって正確に生成されたバグの例です。コードベースの「互換性のあるユニット」に関する推測コード）。 --su 、 number 、 unit bla-bla ...の実際の必要性はありません。現在の-su動作は、「互換性のないユニットが表示された場合はエラーをスローするだけです」などです。 、つまり単純な検証は、（私にとっては）問題ありません。 1px/2px->.5と1px*2px->2px^2マンボジャンボのオーバーエンジニアリングの必要性はわかりません。 しかし、これもまた別の無関係な話です）。

@ seven-phases-max

実際にバグを使用している

うーん..ええ; もちろん、あなたは正しいです。 幸いなことに、私は実際にそのコードを本番環境のどこにも持っていません。 これは、要点を説明するためにまとめた簡単な例にすぎません。

また、この特定のコンテキストでは、「互換性のあるユニット」の当て推量（a / bを分割のままにし、b / cを分割しないようにするなど）に強く反対していることも付け加えておきます。

裸の除数が欲しい人へのオリーブの枝として、私はそれ以上に乗り込んだと思います。 しかし、あなたのコメント[ここ]は最も実行可能な提案だと思います。 あいまいさを排除することは、「厳密な数学」の本来の意図でした。 懸念は、ミックスイン内の操作と、括弧内のあらゆる種類の括弧につながる関数呼び出しになったと思います。 しかし、一般的に、Lessで数学を簡単にするための努力も、皮肉なことに、あいまいさが増しているため、非常に困難になっていると思います。

また、後でfont: 10px/3が有効な省略形であることに気付きました。 したがって、そこで役立つアルゴリズムソリューションは実際にはありません。

質問に戻るには、@ rjgotten ...

推論を裏返してみませんか？ 何かが数式のように見え、互換性のある単位がある場合、デフォルトでは数式として扱われます。 そして、あなたがそれを起こしたくないのなら...まあ; 次に、〜 "..."エスケープハッチを使用します。 結局のところ、それはまさにそれがそこにあるものです...

LessとCSSの考え方/関係は、TypeScriptとJavaScriptに似ています。 つまり、有効な.css名前を.lessと、Less機能の追加を開始できます。 .js名前を.ts 、TypeScript機能の追加を開始する方法と同様です。 言語は基本言語のスーパーセットであるため、何も追加しない場合は、同じ有効なLess / JavaScriptを出力する必要があります。

ただし、これらの比率またはCSSの他の/除数の場合、デフォルトでは、Lessはゲートのすぐ外ですでに失敗しています。 通常のCSSは、何も変更していなくても、任意に数学式が少なくなり、結果が異なります。 それは言語の契約に違反します。 開始した元のCSSを元に戻すために、 .lessをまったく異なるLess式に変更できると、要点を見逃してしまいます。 その作業は決して必要とされるべきではありません。 Lessは、最初に持っていた有効なCSSを取り戻すために、有効なCSSを互換性のあるLess式に変更する必要はありません。 それは壊れたモデルです。

同じ理由がcalc()当てはまります。 はい、式を文字列エスケープすることはできますが、そうする必要はありません。 .css名前を.lessすると、同じ効果的なCSSが生成されます。 これは、元のスタイルシートを妨害/上書き/過剰解釈しないようにするためのプロジェクトの基本目標である必要があります。 そもそもパーサー/言語を使用する以外に、他の何かが問題を開発者に押し付けようとしています。

はい、式を文字列エスケープすることはできますが、そうする必要はありません。 .cssの名前を.lessに変更すると、同じ効果的なCSSが生成されます。 これは、元のスタイルシートを妨害/上書き/過剰解釈しないようにするためのプロジェクトの基本目標である必要があります。 そもそもパーサー/言語を使用する以外に、他の何かが問題を開発者に押し付けようとしています。

それか。

LESSは、 /が許可されている場所と、css内にない場所を認識しています。 とにかく表示されないが表示される場合は、数学が実行されることを前提としています。 また、数学が丸括弧で囲まれている場合、cssで丸括弧が許可されていない場合は、LESSで解釈する必要があります。

言い換えれば、LESSは、有効なcssに到達するために、可能な限り少ない数学を解釈しようとする必要があります。 出力が有効になったらすぐに、それ以上の計算の実行を停止します。

@thany

コンパイラーが知っていることについての仮定が多すぎます（そしてそれらのいくつかは単に間違っています）。
いずれにせよ、「丸括弧」モードは--sm=onとほぼ同じなので、それを使用してこのスレッドを忘れてください（おそらく、プロジェクトでcalc以外の数学を使用していないだけです（いくつか導入されました）。 Lessが設計されてから数年後）、余分な括弧がどのように煩わしいのかわかりませんが、他の人はそうします。）

残りについては、 https： //github.com/less/less.js/issues/1880#issuecomment-345194431を参照して

@ Seven-phases-max /は、 backgroundとborder-radius省略形、およびおそらく私が今考えていない他の省略形でも意味があることを忘れないでください。 LESSは、それらを除算として喜んで扱います。 厳密な数学モードの有無にかかわらず、LESSは独自の小さな数学を行うことを「いつ停止するかを知っている」必要があります。

@thany
LESSは、独自の小さな計算を行うことで「いつ停止するかを知る」必要があります。

いいえ、すべきではありません。 除算スラッシュを使用した将来のCSS省略形がどこに表示されるかを知る方法はありません。 Lessコンパイラにそれを「知って」もらうことは、根本的に欠陥のあるアプローチであり、この議論が解決策を見つけようとしていることそのものです。

これまでのところ、除算演算子としての/には、正気で予測可能な2つの選択肢があります。

• 常にそのように扱い、他の用途のために明示的にエスケープする必要があります。
  これにより、Less構文がCSS構文の厳密なスーパーセットである動作が中断されます。
• 除算演算子として扱わないでください。__unless__既知の数学コンテキスト内にあります。
  現在の--strict-math=on動作のように、既知の数学コンテキストを決定できる/決定する可能性がある場合。

_{（また、Lessの名前がす​​べて大文字で綴られなくなったことに注意してください。）}

/は、背景と境界半径の省略形でも意味があることを忘れないでください。

これは基本的にこのスレッドが始まるものです。
また、 https： //github.com/less/less.js/issues/1880#issuecomment -345194431で提案された変更の概要を参照して

いいえ、すべきではありません。 除算スラッシュを使用した将来のCSS省略形がどこに表示されるかを知る方法はありません。 Lessコンパイラにそれを「知って」もらうことは、根本的に欠陥のあるアプローチであり、この議論が解決策を見つけようとしていることそのものです。

私はこれに完全に同意します。 @thanyあなたは私が書いたものについてあなたが引用したことで私に同意しましたが、あなたは私がするのとは異なる結論に到達しています。 少ない人は、いつ「数学をやめる」べきかわからないはずです。 私が言いたいのは、最初に、Lessは数学を始めること（アメリカ/カナダ主義を使用すること）についてより保守的であるということです。

@rjgotten

既知の数学のコンテキスト内にない限り、除算演算子として扱わないでください。
現在の--strict-math = onの動作のように、既知の数学コンテキストを決定できる/決定する可能性がある場合。

明確にするために、この部分（私は同意します）：

既知の数学のコンテキスト内にない限り、除算演算子として扱わないでください。

実際には4つの可能な解決策があります。これはあなたが知っていることですが、スレッドを要約すると次のようになります。

1. すべての計算は括弧内でのみ行ってください。 これはコモンズによって明らかに拒否されました。これは問題ありませんが、オプションのトグル（ strictMath ）として引き続き使用できます。
2. どこでもすべての数学を行いますが、括弧内でのみ除算します。
3. どこでもすべての数学を行いますが、括弧内でのみ除算します。 除算演算子が./として出力されない限り
4. どこでもすべての計算を行いますが、 12px/4pxが除算にならないように計算を修正します。 （単位のない値でのみ乗算と除算。）言い換えると、どこでも除算しますが、はるかに保守的なルールを使用します。 それが問題を解決しない場合は、逃げることに頼ってください。 したがって、完全な解決策ではありませんが、それでも現在の状況に対する（議論の余地のある）改善です。

使いやすさの観点から、私は#4ように数学を「よりスマート」にするのが好きです。 エンジニアリングとメンテナンスの観点から、そして将来のCSSの変更から保護するために、私は#3が最も堅牢なソリューションとして気に入っています。

ただし、実際には、 calc()を修正するには、 #3と#4両方を実行する必要があると思います。 今のところ、数学を行うときにすべての単位を無視することは本当に混乱しています。 100vh - 12pxは、Less（かっこであるかどうかに関係なく）が触れないようにする必要があります。 しかし、IMOは12px/4px （括弧かどうか）もすべきではありませんが、私はその少数派にいる可能性があります。

ですから、私はこれを「CSS構文と競合する数学」の問題としてはあまり見ていません。そもそも数学の方程式を時期尚早に解くことであまり積極的ではありません。

単位のない値でのみ乗算と除算。

次のようなものがあるので、それはトリックをするつもりはありません：

font: small-caps bold 24px/3 ...;
lost-column: 1/3;
// etc.

そしてそれらはdivではありません。

ただし、実際には、 calc()を修正するには、 #3と#4両方を実行する必要があると思います。

calc()は苦痛です。 皮肉なことに、それは実際のLess関数として実装することで_おそらく_最もよく解決されます。これは、理想的には、解析された式ツリーを取得して、式を単純化しようとします。 つまり、 4px + 12px （または@aピクセル値があることがわかっている場合は4px + @aなどの互換性のあるコンポーネントを事前に計算して組み合わせる必要がありますが、互換性のないコンポーネント（たとえば、互換性のないユニットだけで。

例えば

<strong i="17">@a</strong> : 4px;
<strong i="18">@b</strong> : 2;
width : calc(100%/<strong i="19">@b</strong> - 10px + @a);

最終的にレンダリングする必要があります

width : calc(50% - 6px);

（https://github.com/less/less.js/issues/1880#issuecomment-345345735から繰り返します）
また、 calc内の式を最適化するために、コンパイラーを大幅に過剰に使用するメリットはありません。 あなたがcalcを書いているなら、あなたはそこにあるどんな長い表現でも仕事をするためにブラウザで大丈夫です。 すでに上で述べたように、私は「 calc内の何にも触れないでください」（=本当に必要なものよりも賢くしようとしないでください）、ブラウザ（またはcss-minifier以降）に残します、私が正しく思い出せば、それらのいくつかはすでにcalc部分式の最適化でかなり良い仕事をしています）。

「スマートユニットの振る舞いmamabo-jambo」は、 min/maxモンスター（保守不可能で使用されたことのないコードの肥大化したスタック）を思い出させます-当時「unitsmambo」に対して悲鳴を上げ

PS calcが、算術評価されていない式を受け取る関数になるとすぐに（とにかくそうする必要があります）、プラグインを作成して、必要な最適化でオーバーライドできるようになります。

@rjgotten
Lessコンパイラにそれを「知って」もらうことは根本的に欠陥のあるアプローチです

それは根本的に正しいアプローチだと思います。 LESSはCSSのコンパイラーであるため、LESSがコンパイル対象について知っていることは世界中で理にかなっています。

@ matthew-dean
少ない人は、いつ「数学をやめる」べきかわからないはずです。 私が言いたいのは、最初に、Lessは数学を始めること（アメリカ/カナダ主義を使用すること）についてより保守的であるということです。

興味深いことに、いわば反対側から考えてみてください。 これが私が提案しているものです：

background: url(...) no-repeat 50% 50% / 40px + 10px 40px;

ここでLESSがすべきことは、私には明らかです。

background: url(...) no-repeat 50% 50% / (40px + 10px) 40px;

その結果：

background: url(...) no-repeat 50% 50% / 50px 40px;

これで50% / 50px部分を計算するべきではありません。これは、（1）互換性のない単位のために計算できないはずであり、（2）これはbackground値に対してすでに十分であるためです。 。 つまり、これが「数学をやめる」場所です。

それが、私が「いつ停止するかを知る」ことを意味していました。

これは次のような別のプロパティでしたか？

padding-left: 50% / 10px + 5px;

エラーで壊れます（互換性のないユニット）。 考えられる出力の1つは、このプロパティでは無効な50% / 15pxです。 もう1つの結果は、現在実行される5%ある可能性がありますが、これはすべての方向で間違っています。
と：

padding-left: 50px / 10px + 5px;

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

padding-left: 10px;

予想通り。 したがって、この場合には、 /無効ですpadding-leftとLESSに取り込まれており、その数学ブツを行います。

@ matthew-dean
実際には4つの可能な解決策があります。これはあなたが知っていることですが、スレッドを要約すると次のようになります。

もう1つ：
5）LESSの除算には\演算子を使用し、 /を使用して非推奨にします。 MATLABにはこのようなものがあり、BASICの特定のフレーバーはそれを使用して整数除算を強制しました。 したがって、バックスラッシュを使用することは完全に前例のないことではありません。

/編集
キーボードに÷キーを含めるようロビー活動を行い、それを除算演算子として使用することもできます。 それは私が小学校で学んだものです:)

あなたが提案することは、以前に何度も議論されました（ここで参照されているスレッドを参照することを躊躇しないでください）。 だからここにほんの小さな怠惰なコメントがあります：

LESSの除算には\演算子を使用し、 /を使用して非推奨にします。

https://github.com/less/less.js/issues/1872#issuecomment -35245890

backgroundは十分です... padding-leftは無効です

「みんな、私のブラウザ/ポリフィル/ fnordプロパティのサポートを追加/更新/拡張したものは何でも、新しいLessバージョンをリリースしてくれませんか？」をご覧ください。 問題。
font問題を満たします。
などなど。
さて、 @ rjgottenは、なぜその種の「知識」がどこへの道でもないのかについて、すでに上でコメントしています。

@ seven-phases-max
バックスラッシュは単なる提案でした。 除算には?を使用することをお勧めします。 それは本当に重要ではありません。 私が提案しているのは、非常に異なったあいまいな意味を持つ1つの文字（ / ）を使用しないことです。

「みんな、私のブラウザ/ポリフィル/ fnordプロパティのサポートを追加/更新/拡張したものは何でも、新しいLessバージョンをリリースしてくれませんか？」をご覧ください。 問題。

CSSは明確に定義された標準です。 標準以外のものをサポートするべきではありません。 それがあなたの問題だと思います。 fnordプロパティは標準の一部ではないため、サポートしないでください。 この新しい指定されていないプロパティが発生すると、LESSはデフォルトの動作にフォールバックする可能性があります。これは、現在の動作、括弧が必要な動作、またはあいまいでない限り他の動作である可能性があります。

フォントの問題に対応します。

フォントの問題は、LESSの絶対的な始まり以来/問題が存在していたことを証明しています。 backgroundがバックグラウンドサイズの値を含める機能を取得したとき、またはborder-radiusが発生したときだけではありません。 ちなみに、フォントの問題を述べることで、あなたは自分自身に対して最善の議論をしただけです:)

ちなみに、フォントの問題を述べることで、あなたは自分自身に対して最善の議論をしただけです:)

あなたは何かを誤解していると思います。 /をdiv演算子として完全に削除することを最初に提案したのは

CSSは明確に定義された標準です。

TRレベルで完全に成熟した仕様部品にこだわるなら、多分。
さもないと？ いいえ、ちがいます。 新しいCSSの「モジュール」の衛星仕様と既存のモジュールの改訂版があり、毎週ではないにしても毎月ポップアップ表示されます。

@ seven-phases-max

font：small-caps bold 24px / 3 ...のようなものがあるので、それはトリックをするつもりはありません。

いいえ、わかりました。 私のポイントはまさにそれでした：単位なしのdiv /乗算だけが問題を軽減しますが、問題を解決しません。

そして、一般的に、すべての部門に対する./提案は、依然として非常に論理的であるように思われます。

@thanyすべての具体的な例に

また、calc内の式を最適化するために、コンパイラーを大幅に過剰に使用するメリットはありません。 calcを作成している場合は、ブラウザを使用して、そこにある長い式が何であれ、その作業を実行できます。 すでに上で述べたように、私は「calc内の何にも触れないでください」（=本当に必要なものよりも賢くしようとしないでください）、ブラウザ（またはcss-minifier）に残します。正しく思い出せば、それらのいくつかはすでにcalc部分式の最適化でかなり良い仕事をしています）。

私はこれに完全に同意します。 calc()ホワイトリストに登録しただけで、数学関連の新しい問題の99％が削除されます。 Lessがcalc()問題を回避するために、より賢く数学を行うことができるいくつかの方法を提案しましたが（おそらくそうすべきです）、それがこの考えに対する議論として解釈された場合はお詫び申し上げます。 私もこれをサポートします。

（ここ/他の場所で説明されているように）唯一の注意点は、開発者は必然的にcalc()で変数を使用したいということです。したがって、変数を交換し続けるように注意する必要がありますが、そうしないでください。算数。 それがどれほど難しいかはわかりません。 それができれば、今日のcalc()処理の変更をサポートします。

@thany

フォントの問題は、LESSの絶対的な始まり以来/問題が存在していたことを証明しています。

これは真実であり、公正な点ですが、多くの適切な回避策があり、 fontプロパティの省略形を使用することは必ずしも標準的な方法ではありませんでした。 これは、Lessが開始された後に複数の背景とcalc()が到着したために、これがさらに問題になったためです。現在、CSSグリッド構文は、当初は日常の実用的な用語では存在しなかった多くの競合が存在することを意味します。

ちなみに、これはSassが問題を解決する方法であり、次の例で示されています。

p {
  font: 10px/8px;             // Plain CSS, no division
  $width: 1000px;
  width: $width/2;            // Uses a variable, does division
  width: round(1.5)/2;        // Uses a function, does division
  height: (500px/2);          // Uses parentheses, does division
  margin-left: 5px + 8px/2px; // Uses +, does division
  font: (italic bold 10px/8px); // In a list, parentheses don't count
}

Less関数の引数内で（現在）数学を実行でき、Less関数はピクセル値を返すことができるため（理論的にはLessはfont: print10px()/8px実行できますか？いいえ？）、

個人的には、魔法の表現の存在に基づいて数学がどのような場合に発生するかを開発者に思い出させようとするのは、一種のクレイジーな作りです（ +が前に付けられているようなものですか？）が、それぞれ独自のものです。

個人的には、魔法の表現の存在に基づいて数学がどのような場合に発生するかを開発者に思い出させようとするのは、一種のクレイジーなことだと思います。

+1

_{「解決策」がlessc --smがすでに行っていることを超えて、ここで説明されている問題のいずれも解決しないことを数えていません。 そして、 1/2と$var/2異なる結果は、驚くほど素晴らしいです...〜愚かさ〜「幸せなデバッグ、敗者！」}

@ matthew-dean
ちなみに、これはSassが問題を解決する方法であり、次の例で示されています。

これは、別のオペレーターに頼ることなく、優れたソリューションです。
式が有効なCSSである可能性がある場合は、そのままにしておきます。

個人的には、魔法の表現の存在に基づいて数学がどのような場合に発生するかを開発者に思い出させようとするのは、一種のクレイジーなことだと思います。

同意しない。 これは単純なルールのセットであり、覚えておく必要のある他の（クレイジーかどうかに関係なく）ルールのセットと何ら変わりはありません。

意味のない数学が発生するエッジケースがいくつかありますが、括弧を適用するだけで完了です。

「解決策」がlessc--smがすでに行っていることを超えて、ここで説明されている問題のどれも解決しないことを数えていません。 除算だけが必要なのに、なぜ（1/2）の代わりに0 + 1/2と書くのでしょうか？ そして、1/2と$ var / 2の異なる結果は、驚くほど素晴らしいです...愚かさ「ハッピーデバッグ、敗者！」 メッセージ。

ハ、はい、これ。

@thany

これは、別のオペレーターに頼ることなく、優れたソリューションです。
式が有効なCSSである可能性がある場合は、そのままにしておきます。

雑草に入らないようにしますが、構文上の理由と言語の一貫性のために、Lessでは機能しません。 Sassにとっては素晴らしいことかもしれませんが、それは議論の余地があると思いますが、私はデザインの観点からそのプロジェクトに個人的に関わっていないので、誰が言っているのでしょうか。 私が知っているのは、テーブルのオプションが開始するのに最適な場所であるということだけです。この問題に関連するメッセージスレッドのいくつかに多くの時間を費やし、言語に時間を費やした場合は、あなたが来ると確信しています。同じ結論に。

回避できない1つの観察結果：有効なバニラCSSをインポートする場合、その出力は機能的に同一である必要があります。 したがって、私が引き出すことができる唯一の結論は、LESSはすでに有効なCSSである可能性のある式に触れてはならないということです。 これがどのように行われるかは、私次第ではありません。 しかし、バニラCSSのインポートは信頼性が低いという事実が残っています。これは、主にLESSが分割を熱心に実行しすぎた結果です。

いくつかの簡単な構文規則に従って、SassにバニラCSSをインポートすると、ほぼ問題なく機能します。これは、前述のように、Sassがコンパイラーに実行を指示しない場合、 /演算子をそのままにしておくためです。 これらの構文規則は、有効なバニラCSSでは発生しない分割を強制する方法を説明しているため、優れています。

あなたはまだあなた自身の想像力と議論し、彼らがあなたに言うこととは議論しません。 簡単な質問に答えてください：「 0 + 1/2は(1/2)よりも優れている可能性がありますか？」 100％-CSS互換性だけが気になる場合は、素敵な-smを設定し、このスレッドを忘れてください。

回避できない1つの観察結果：有効なバニラCSSをインポートする場合、その出力は機能的に同一である必要があります。 したがって、私が引き出すことができる唯一の結論は、LESSはすでに有効なCSSである可能性のある式に触れてはならないということです。 これがどのように行われるかは、私次第ではありません。 しかし、バニラCSSのインポートは信頼性が低いという事実が残っています。これは、主にLESSが分割を熱心に実行しすぎた結果です。

この部分は私が本質的に同意します、そしてあなたはその点でこのスレッドで多くの同意を見つけるだろうと思います。 意見の不一致のほとんどは解決策に関するものであり、各解決策にはさまざまな副作用があります。

私はこれらの重大な変更を優先事項として採用します。

1. 裸の/代わりに./必要とする括弧の外の数学（そして、明らかに、追加の括弧のセットを必要とする関数の引数、たとえばmy-function(12px/10px, arg2, arg3)は12/10を分割しませんが、 my-function((12px/10px), arg2, arg3)は分割し、 my-function(12px./10px, arg2, arg3)は分割します） \/や\などの/特別なインジケーター。例： 12px\10px 。

@ seven-phases-max-バックスラッシュを再検討したいと思います。 これに関連して、 https： //github.com/less/less.js/issues/1872#issuecomment -35245890について言及されていることは知ってい

分割に単一の円記号を使用すると、実際の競合が発生することをもう少し詳しく調べることができますか？ 私の本能は、 \は、現在の/前後の状況よりも問題が少なく、 ./よりも開発に適しているということです。 調査を行ってそれが実行可能であることがわかった場合は、括弧内に/を許可するコンテキスト切り替えの代わりに、どこでも使用できるように画期的な変更を加えることができます。 そして、レガシースイッチで/をサポートできます。

1. （2番目の優先順位） calc()は特殊なケースであるため、変数の置換はできますが、数式は評価されません。

分割に単一の円記号を使用すると、実際の競合が発生することをもう少し詳しく調べることができますか？

さて、 \anycharacterが有効なCSSであり、独自の意味を持つという問題。 確かに、実際のプロジェクトではそのようなコードはほとんど見つかりません（つまり、 \9ようなハックを除く）が...そのライオンに餌を与えたいですか？ 同じものの別の「uh-oh」を導入することによって、1つの「uh-oh、私の100％有効なCSSがコンパイルされない」を修正するのは少し奇妙に聞こえます:)

calcについては、最初からコンセンサスがあったと思います。つまり、基本的にはボランティアが実装するのを待つだけです（クイックフィックスは、わずか5〜6行の新しいコードで実行されると推定しています）。これを行うのは本当に勇敢な人だけです-マイナーな実装の詳細は異なる場合がありますが、プロセスで決定するのは問題ないと思います）。

さて、\ anycharacterが有効なCSSであり、独自の意味を持つという問題。 確かに、実際のプロジェクトではそのようなコードはほとんど見つかりません（つまり、\ 9のようなハックを除く）が...そのライオンに餌を与えたいですか？ 同じものの別の「uh-oh」を導入することによって、1つの「uh-oh、私の100％有効なCSSがコンパイルされない」を修正するのは少し奇妙に聞こえます:)

聞きましたが、トレードオフの可能性があります。 そして、ええ、私は\anycharacterが有効なCSSであることを知っています。 私はそれがより良いトレードオフのセットであるかどうか疑問に思っていると思います。 12px./10pxを書いたとき、構文的に奇妙に感じただけです。 構文的には、競合を発生させずにCSSを可能な限り再利用しようとしているように感じます。

同様に、 ./は構文を明確にし、競合を完全に回避しますが、数学のためにどこでも括弧を強制するので、私はそれをサポートしましたが、反発があり、ここでそれについて心配しています。 では、 10px\10を開発者が\10から逃れる意図と間違える正当なケースはありますか？ 私はそれが難しい理論であることを知っています、そしてあなたのポイントはおそらく私たちが本当に知らないということでしょう.....それは複雑な質問です、そして私たちがすべてのCSSを知っているわけではないので特にLessでは新しい構文を追加することは常に厄介です野生のCSSも将来のCSSも。

calcに関しては、最初からコンセンサスがあったと思います-したがって、基本的にはボランティアがそれを実装するのを待つだけです（私は、5〜6行の新しいコードで迅速な修正が行われると見積もっています-したがって、実際にはこれを行う勇敢な人-マイナーな実装の詳細は異なる場合がありますが、プロセスで決定することは問題ないと思います）。

良い！ 可視性を高めるために個別に追跡する必要がありますか？

@ Seven-phases-max：

確かに、実際のプロジェクトではそのようなコードはほとんど見つかりません（おそらく\9ようなハックを除く）

右。 ああ、そのでこぼこの「西洋人」... :)

@ seven-phases-max
簡単な質問に答えてください。「0+ 1/2は（1/2）よりも優れている可能性がありますか？」

どこに行くのかわかりません。 (1/2)は、有効なCSSである可能性がないため、LESSで実行する必要があります。したがって、LESSとして意味する必要があります。 0 + 1/2は1/2になるはずです。ここで、LESSは0 + 1部分を実行します。これは、有効なCSSにはなり得ない部分だからです。 1/2部分は有効である

@thany
OK、 (1/2) LessとSassの両方で期待どおりに機能することを理解してください。
そして、 0 + 1/2 （および1 * 1/2など）は、上記でブリリアントと呼ぶソリューションの一部であり、「ブリリアントソリューション」の結果は0.5です。
ここで何が起こっているのかまだわかりませんか？
上記のすべて（最初の投稿から開始）をもう一度読み直して、「私が不満を言っているのは正確には何ですか？」と自分自身に答えてみてください。

@ seven-phases-max
そして、0 + 1/2（および1 * 1/2など）は、上記でブリリアントと呼ぶソリューションの一部であり、「ブリリアントソリューション」の結果は0.5です。

いいえ、解決策は0.5ではなく1/2なります。これは、 1/2が有効なCSSである可能性があるためです。 あなたはスラッシュが有効であるとき知ってLESSをしたいように見えるので、それは常にあるかもしれないと仮定しないでください。 したがって、 1/2が唯一の論理的な結果です。 同様に、 2 * 1/2は2/2になります。これは、 *がそれ以外の場合は無効なCSSになるためです。

ここで何が起こっているのかまだわかりませんか？

ここで何が起こっているのか完全にはっきりしています。 LESSは、数学の除算を熱心に実行し、盲目的に単位を無視します。

上記のすべて（最初の投稿から開始）をもう一度読み直して、「私が不満を言っているのは正確には何ですか？」と自分自身に答えてみてください。

個人的な攻撃の必要はありません。

LESSは、数学の除算を熱心に実行し、盲目的に単位を無視します。

だから、これはあなたが不平を言っていることですよね？

個人的な攻撃の必要はありません。

では、代わりに何をすべきでしょうか？ 元の2つの投稿を何度も（そして何度も）繰り返しますか？ それがあなたに明らかになるまで：
@コミュニティ：

-smオプションを使用する

@thany ：

その後、デフォルトでオンになっているはずです。

@ Seven-phases-max：

これはすぐに無数のプロジェクトを壊してしまうからではありません。 したがって、デフォルトの動作を問題として扱う場合は、文書化されたオプションを設定するだけで完了します。

それで、あなたは「それがすべきである」、「それがすべきである」、「それがすべきである」を何を期待して繰り返しているのですか？ 私たちにとって、あなたが提案したことがうまくいかない理由や一般的に意味がない理由を詳細に説明しようとして時間を無駄にするよりも、「いいえ、すべきではありません」と答える方が簡単だと思います（あなたがしたくない説明理解するか、単に理解できない）。

では、このスレッドは何についてですか？ それは、「 -smような動作のデフォルトを作成するという最終的な重大な変更は避けられないが、恐ろしいもの以外のより快適な算術演算のための機能を提供する必要があることを認識することです： margin: (1/2) (3/4) (5/6) (7/8);算術をたくさん使う」。
ここに投稿するのは、既存の-sm動作よりも優れている（またはまったく同じことをしている）ことを提案するか、最初から問題のないこと（そこにあるような）について議論することです。 言い換えれば、単なるランダムノイズです。

@ Seven -phases-max @ 下げましょう。 周りには強い意見があります。

ほとんどの人は、これらの両方の周りで同じページにいると思います。理想的には、Lessによって数式として解釈されていません。

font: 12px/10px;
width: calc(100% - 20px);

したがって、これらの点についてはほとんど合意があり、ほとんどの議論は可能な解決策に関するものです。 calc()問題は、前進するのに十分なコンセンサスがあるようです。 基本的に：calcには触れず、 calc()変数を文字列補間のように扱います。 これはSassのやり方とほぼ同じですが、 calc()の補間構文が必要ですが、これは必要ないと思います。

font部分の解決策は非常に複雑になり、主要な解決策は次のとおりです。

1. デフォルトですべてに括弧を要求する（最初の試み-ほぼ実装されていますが、コミュニティは拒否されました）
2. strictMathスイッチ（デフォルトにする代わりに追加されたもの、および@ Seven-phases-maxの提案）を切り替えてから、すべての計算を明示的に実行します。 技術的には、現在ほとんどの人にとって可能な解決策ですが、....質問は頻繁に出てきます。心理的には、システムに不慣れな人がデフォルトを保持している可能性が高いため、問題があります。 また、特にチームでは、すべての開発者がビルド設定を変更できるわけではありません。
3. 基本的に、Lessの除算演算子を変更します。 スレッドの主要な候補は./ 。これは機能しますが、見るのは少し奇妙です。 \は、調査なしでは現時点では不明です。 動作する可能性があり、エスケープとの未知の競合を引き起こす可能性があります。 これはよりクリーンな構文であり、（潜在的には不明ですが）リスクが高くなります。 誰かが時間をかけてこれが競合を引き起こさないことをデモする場合、つまり、パーサーが2つを明確に区別できるように、エスケープと数学が混在する例を提供する場合でも、それは可能性です。 だからそれはただ仕事をします。 @thany 、あなたや他の誰かがこれのファンなら、これは必要な作業です。 最後に必要なのは、休憩を別の場所に移動することです。

このスレッドを単純化するために、ここからは#3に焦点を当てる必要があると思います。 私は主に好奇心としてSassの例を投稿しましたが、これらの解決策が問題を適切に解決したり完全に解決したりすることはないと思います。また、概念的にはLessと互換性がありません。 0 + 1/2を要求することの妥当性について議論することは、私たちをどこにも連れて行かないでしょう。

したがって、 calc()優れた解決策があれば、ほとんどの投稿された問題の50％が得られるので、短期的にはこの質問にのみ焦点を当てることをお勧めします。

少ない除算演算子を変更する必要がある場合、何に変更する必要がありますか？

• ./ -これは私が感じるほど厄介ですか、それとも人々はそれでいいと思いますか？
• \ -調査と証明、およびパーサーが従うための擬似コードがなければ、これは前進しません。 それが安全であると証明できれば、私は個人的にそれを好むでしょう。
• 他の代替品？

正直なところ、 calc()を変更して/を変更すると、Lessで数学の周りのノイズの99％を静めることができると思います。

こんにちは、 calc()を修正しました-https：//github.com/less/less.js/pull/3162

多くのアドオンコードなしで機能するソリューションを思いついたとき、私はちょっと驚いた。 基本的に、 strictMathスイッチのコードはすでにあり、式をチェックインして、括弧の外にある場合は数学を評価しないようにしました。そのため、 calc()評価中に数学をオフにするために、呼び出しにスイッチを追加しました。

https://github.com/less/less.js/pull/3162/files#diff-a94aaffd78b1d3c5eda7a42d5be1ca0dおよびhttps://github.com/less/less.js/pull/3162/files#diff-4e696271823c96903a91fff84983bab6を確認してください

テストは十分ですか？

@ matthew-dean：coffee：

テストは十分ですか？

PRのコメントごとに、次のようなテストを追加してください。

foo: 1 + 2 calc(3 + 4) 5 + 6; // expected result: 3 calc(3 + 4) 11;

そしてマイナーな注意：この修正は明らかに＃1627と同じ問題をもたらします、すなわち

<strong i="13">@a</strong>: floor(1.1);
<strong i="14">@b</strong>: floor(1 + .1);

div {
    foo: calc(<strong i="15">@a</strong> + 20%); // ok
    bar: calc(<strong i="16">@b</strong> + 20%); // error: invalid floor arguments
    baz: @b;             // ok
}

しかし、 calc場合は問題ないと思います（結局のところ、遅延評価の概念を大幅にやり直すことなく、これを修正する簡単な方法ません）。 したがって、 calc内の変数を使用する場合は、遅延評価を念頭に置いてドキュメントに通知を入れるだけでよいと思います。

そしてマイナーな注意：この修正は明らかに＃1627と同じ問題をもたらします

いいキャッチ！

PRでのコメントと同様に、呼び出しごとにコンテキストmathOnプロパティを切り替えると、これが解決されます。 合格したfloat(1 + .1)テストを追加しました！

PRでのコメントと同様に、呼び出しごとにコンテキストmathOnプロパティを切り替えると、これが解決されます。 >合格するfloat（1 + .1）のテストを追加しました！

:)いいえ、 -sm: off場合、「フロア」エラーが発生する必要があります。 PRの私の新しいコメントを参照してください。
復元は1 + 2 calc(3 + 4) 5 + 6ようなものだけを処理します。

:)いいえ、-sm：offの場合、「floor」エラーが発生する必要があります。

どうして？ calc()内の関数はすべてLess関数である必要があります。 そうでない場合でも、calc（）内には、生の数式を使用できるCSSネイティブ関数はありません。 期待される結果は、vars関数とLess関数を評価することですが、生の関数はcalc()内に残しておきます。

補足：Lessの除算演算子として/を\に切り替えるブランチ実験を行いました。 エスケープするためのテストはすでにたくさんあり（アドレス番号3160に追加しました）、それらはすべて正常に機能し、演算子を切り替えても数学は正常に機能します。 固有の競合は見られませんでした。 ブランチは私のフォークにあります： https ：

Re：入れ子関数

このため：

div {
    bar: calc(floor(1 + .1) + 20%);
}

開発者として、期待される結果は次のようになります。

div {
    bar: calc(1 + 20%);
}

それがまさに今起こっていることです（これらの変更で）。 エラーはスローされません。

@ matthew-dean
いいえ、あなたがそれを書いた方法、これ：

foo: unit(1/2, px);

-sm:onを使用すると、次のようにコンパイルされます。

foo: .5px;

^-間違っています。
入れ子関数についても同じです。 さらに、ほとんどの関数が通常、引数として算術式をとることができないという事実は、 -sm: onに違反する理由ではありません。
したがって、 -sm: on下で

foo: floor(1 + .1);
bar: calc(floor(1 + .1) + 20%);`

エラーをスローする必要があります（これがコミットで壊れます）。

あなたは何について話していますか？

unit(1/2, px)と-sm:on ：

ERROR: error evaluating function `unit`: the first argument to unit must be a number. Have you forgotten parenthesis?

calc(floor(1 + .1) + 20%)と-sm:on

ERROR: error evaluating function `floor`: argument must be a number

ブランチをチェックしてください。 やってみて。

コードを確認する際に役立つ可能性のあることの1つは、何かが誤った出力を生成するかどうかわからない場合は、それを確認することです。 または、特定の入力を試して、期待どおりに機能することを確認するように依頼してください。 または、それがどのように/なぜ機能するのかわからない場合は質問してください。 それが役に立たないかどうかを知らずにそれを間違って呼ぶことは役に立ちません。

私の謝罪。 私はこの部分の間接的な制御を逃したと思います。

ブランチをチェックしてください。 やってみて

できません、ごめんなさい。

私の謝罪。 私はこの部分の間接的な制御を逃したと思います。

心配ない。 これに対処すると、期待どおりに機能しているように見えますか？

これに対処すると、期待どおりに機能しているように見えますか？

はい、これまでのところ、他に疑わしいことは想像できません。

@ matthew-dean
基本的に、Lessの除算演算子を変更します。 スレッドの主要な候補は./でした。これは機能しますが、見るのは少し奇妙です。 \は調査なしでは現時点では不明です[...] @ thany 、あなたや他の誰かがこれのファンなら、これは必要な作業です。 最後に必要なのは、休憩を別の場所に移動することです。

実際にはまったくありません。 \演算子を通過しなかった後の最後の手段として、LESSに独自の計算のみを実行させようと提案しました。 新しい除算演算子が必要な場合は...まあ、 calc()は加算、減算、乗算も実行できます。 それらのための新しいオペレーター？ 実用的ではないと思います。 新しい除算演算子は、フォント、背景、境界線半径などのソリューションになる可能性がありますが、CSS数学のソリューションではありません。

私はまだ本当の解決策は、LESSがコンテキストについて知ることだと思います。 calc()はCSS関数であり、CSSでは実行できない数学のみを評価する必要があることを知っておく必要があります（はい、ここで「すべき」をもう一度使用します。他にどの単語を使用する必要がありますか？...） 。 しかし、 floor()はCSSに存在しないため、無効なCSSを吐き出さないように（完全に）評価する必要があります。 これは前に別の言い方で述べたと思います。

私はまだ本当の解決策は、LESSがコンテキストについて知ることだと思います。 calc（）はCSS関数であり、CSSが実行できない数学のみを評価する必要があることを知っておく必要があります（はい、ここで「should」をもう一度使用します。他にどの単語を使用する必要がありますか？...）。 ただし、floor（）はCSSに存在しないため、無効なCSSを吐き出さないように（完全に）評価する必要があります。 これは前に別の言い方で述べたと思います。

十分に公平です： \ですが、コンテキストに関しては、他の投稿に基づいて、あなたが思っているよりもはるかに複雑な問題であることを保証できます。 あなたは本当にそれを次のように煮詰める必要があります：

12px/10px  // Is this division, or not?
10px/1.5 // is this division, or not? 

/を除算演算子として確実に残し、 calc()を模倣し、あいまいにならないようにする場合は、 /が含まれていることを絶対に確認する必要があります。括弧（ calc()例外を除く）。 それは予測可能なコンテキストを提供します。

このスレッドの冒頭でのその提案もまだ可能性があり、いくつかの強力なサポートがありました。 基本的に、デフォルト設定では、除算を除いてすべての数学が括弧の外でサポートされます（ calc()を除いて、3.0以降の場合も同様です）。 多分それは行く方法です。 それは可能になります：

font: 10px/1.5;   // not division
font: (10px/10);  // division, result is 1px
font: 10px+15px/1.5;   // addition but not division, result is 25px/1.5
font: (10px+15px/1.5);  // result is 20px

つまり、 10px+15px/1.5の結果は、かっこで囲まれていない限り、「半分評価された」ように見える式で、開発者が理解するのはまだ難しいかもしれません。 もし私たちが先に進んで、デフォルトで厳密な計算をオンにしていたなら、それはおそらく大丈夫だっただろう。 あいまいさはさらに少なくなります。 [肩をすくめる]いずれにせよ、ある種のコンテキストで数学をラップすることは、あいまいさを排除する方法であり、除算演算子を変更する以外の除算の唯一の方法です。

コミュニティは本質的に方向性を決定する必要があります。 このスレッドには実行可能なオプションがあります。 それぞれに欠点があります。 それぞれに問題点があります。 完全なコンセンサスを持つものはありません。 しかし、IMOはそれらのいずれも現在のシナリオよりも優れています。 その錠剤を飲み込まなければならない。

決定の最後の呼びかけ

ですから、不可能を乗り越えるために、これを提案したいと思います（3年前のコメントを参照してください）。

--strict-math 3の設定を与える

1. オフ
2. 分割
3. 厳密（バックコンパットの場合は別名on ）

議論を解決するには、 --strict-math=divisionスイッチが次のことを実行できるようにします。

1. 括弧の外に/文字だけで除算を実行しないでください。 例： border-radius: 55px / 25px; ->数学なし（はい、それは有効なCSSです）
2. 2つの異なる方法で除算を許可します。
   a。 .プレフィックス- border-radius: 55px ./ 25px;
   b。 括弧- border-radius: (55px / 25px);
3. どちらの形式も括弧内で有効です-たとえば、 border-radius: (55px ./ 25px);は有効です

したがって、開発者として、一方のバージョンが好みではないと感じた場合は、もう一方のバージョンを使用できます。 括弧を使用したくない場合もあります。 修正された除算演算子を使用したくない場合もあります。 みんなのために何か。 そして、 /がfont 、 background 、 border-radiusで使用されているCSSで現在普及している構文を使用して、Lessを初めて使用する人にとって不快な驚きはもうありません。 @mediaクエリ、CSSグリッドプロパティ、そしておそらく将来的にはもっと。

次のステップ

これをオプションとしてPRに入れてから、説明したように、将来のメジャーバージョンのデフォルトとして切り替えることをお勧めします

@ matthew-dean

つまり、ピリオドはエスケープシーケンスの逆のように機能しますか？
悪い考えではありません、本当に...

そして、考えられるすべてのことは、_おそらく_可能な限り最もクリーンなソリューションの1つです。

@rjgottenここから始めましょう： https ：

テストの1つで、ディメンションノードの1つが操作ノードに変わったように見える（操作ノードで操作を実行できないためにエラーがスローされる）という奇妙なエラーがまだ発生しています。 strictMath: division実行されていない別のテストが正常に機能するため、解析の問題のようです。チェックして、役立つかどうかを確認してください。

私がやりたいのは、この問題を閉じて、残りの数学の質問を処理する新しい問題を作成することです。 具体的には：

1. 除算の処理、およびstrictMath: 'division'機能。
2. 混合単位の数学の処理。 参照： https ：