Less.js: Umgang mit Mathematik

Ich glaube nicht, dass wir die Dinge massiv ändern oder zurück ans Reißbrett gehen wollen

Ja, ich habe vorgeschlagen, damit zu beginnen, nur weil _wenn_ wir in 3.0 eine "standardmäßige" strenge Mathematik wollen, müssen wir etwas weniger Schweres als das aktuelle erfinden (und eine Möglichkeit, alle Probleme zu beheben, ohne neue --alt-strict-math einzuführen --alt-strict-math scheint ziemlich unwirklich zu sein, da sich hinter der font -ähnlichen Hardcoding-Lösung versteckte Probleme verbergen...).

Ich hatte nicht gemerkt, dass es wächst

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

:(

Ich denke im Moment bin ich dafür, strictMaths zunächst zu be auszubauen

• aus
• Teilung
• Auf

und dann für 2.0.0 die Standardeinstellung auf Division setzen

So..

Medienabfragen – wenn deaktiviert, wechseln Sie zur Unterteilung für Unterknoten
Schriftart - wenn aus, auf Division für Unterknoten wechseln
calc( - wenn aus oder Division, für Unterknoten auf on schalten

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

Ja, ich denke, sie sind dazu da, "Kurzschriftwerte" (dh x/y ) in _jeder_ "Shorhand-Eigenschaft" zuzulassen ...

verwandt: https://github.com/less/less.js/issues/1480

Eine weitere Option.. Calc-Aufrufe verarbeiten, aber nur dort, wo die Einheiten dies ermöglichen, z
kalk( 1% + 2%) => 3%
calc(100% - 10 px) => unverändert

Dies wird calc beheben, aber nicht #1627 und ähnliches.
Ich meine ja, calc(100% - 10 px) => unchanged könnte eine Lösung für calc aber das macht eine less-heavy-than-parens-everywhere Lösung nicht überflüssig.

Wenn strenge Mathematik noch einmal überdacht wird, möchte ich vorschlagen, dass Less-Funktionen wie percentage() keine zusätzlichen Klammern benötigen. Bei strenger Mathematik müssen Sie das Argument doppelt umbrechen. Dies würde die Möglichkeit von Verwirrung und schwer zu findenden Fehlern erheblich reduzieren, da sowohl percentage(16 / 17) als auch percentage((16 / 17)) gültig wären.

@calvinjuarez V2 bietet ein Plugin-Subsystem, in dem ein Plugin eine beliebige Anzahl von Funktionen zur Umgebung hinzufügen kann und in diesem Sinne kann der Kern nicht entscheiden, ob eine solche eingebaute Funktion einen einzelnen Wert oder einen Ausdruck erwartet, dh es ist erlaubt, 16/17 zu akzeptieren und dann 16/17 auszuwerten, _bevor_ es an eine Funktion übergeben wird, wäre falsch (naja, grob gesagt - intern ist es etwas komplizierter).

In diesem Zusammenhang scheint die Änderung von ./ mein Favorit zu sein, obwohl ich verstehe, dass dies eine sehr dramatische Änderung wäre (im Vergleich zu (/) , ohne sie zu zählen, ist auch ein Leerzeichen vor . erforderlich , zB 16 ./17 und nicht 16./17 , hmm).

Eine andere Sache, bei der weniger derzeit gültiges CSS bricht, ist die Hintergrundkürzel:

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

Ich denke im Moment bin ich dafür, strictMaths zunächst zu be auszubauen

aus
Teilung
Auf
und dann für 2.0.0 die Standardeinstellung auf Division setzen

Entschuldigung, dass ich nicht darauf geantwortet habe, bevor 2.0 veröffentlicht wurde. Ich denke, das ist ein guter Instinkt. Nackte Divisionsoperatoren kollidieren einfach mit zu viel CSS und werden immer mehr Konflikte verursachen, wenn die Leute mehr CSS3-Funktionen verwenden. Und ich verstehe den Widerstand der Leute, keine Eltern für alle Mathematik zu benötigen, da dies in vielen Fällen nicht erforderlich ist.

@sieben-phasen-max

es ist erlaubt, 16/17 zu akzeptieren, und dann 16/17 auszuwerten, bevor es an eine Funktion übergeben wird, wäre falsch

Genau genommen ist das absolut richtig. Dies sollte nicht ausgewertet werden, BEVOR es die Funktion erreicht, insbesondere bei einer benutzerdefinierten. Ich halte es jedoch für klug, Funktionen die Möglichkeit zu geben, Argumente wie diese zu verarbeiten, wenn dies sinnvoll ist. Prozent würde also 16/17 als Textargument erhalten, und dann könnte die Prozentfunktion eine Hilfsfunktion aufrufen, um zu sehen, ob der Text mathematisch ist. Bei Prozentangaben ist das Argument nicht mehrdeutig. Eine CSS3-Deklaration ist hier nicht gültig. Andere benutzerdefinierte Funktionen könnten also genauso funktionieren: Entscheiden Sie sich dafür, Argumente für gültige mathematische Gleichungen auszuwerten. Daher ist es nicht unbedingt richtig, dass die strenge Mathematik in diesem Fall eine doppelte Klammer "erzwingt". Ich denke, dass dies zu einem gewissen Rückschlag gegen die Idee der strengen Mathematik führt, dass sie notwendigerweise in allen Fällen ausführlich sein muss.

Unsere --math-Optionen könnten eher wie folgt aussehen:

• Stets
• Division (Standard)
• Strikt

Also könnten wir --strict-math=true abwerten und es zu einem Alias ​​für --math=strict machen

Ich halte es jedoch für klug, Funktionen die Möglichkeit zu geben, Argumente wie diese zu verarbeiten, wenn dies sinnvoll ist.

Sie sind bereits erlaubt (testen Sie einfach, wie percentage(16 / 17) und percentage((16 / 17)) mit --strict-math=on funktionieren).
Obwohl keine der Funktionen Folgendes verwendet:

und dann könnte die Prozentfunktion eine Hilfsfunktion aufrufen, um zu sehen, ob der Text mathematisch ist.

einfach, weil auf diese Weise jede Funktion diese ~20 zusätzlichen Zeilen dieses Extra-Helfer-Umwandlungs-Arg-Checking-Smart-Arg-Handling-Zeugs haben müsste, während der eigene Funktionscode in den meisten Fällen nur eine(!) Zeile ist.

Jede Funktion muss 20 zusätzliche Zeilen haben? Wie kommst du darauf?

Wenn der Prozentsatz bereits bei strikter Mathematik in einzelnen Klammern funktioniert, verstehe ich das Problem von

Jede Funktion muss 20 zusätzliche Zeilen haben? Wie kommst du darauf?

Das ist nur eine typische Übertreibung von: vielleicht 5, vielleicht 10, vielleicht 20... Wer würde sich schon um genaue Zahlen kümmern, wenn Real-Code/Aux-Code-Verhältnis -> 0 . (Pragmatisch würde ich bei percentage(16 / 17) aufhören, einfach einen Fehler werfen, anstatt NaN% (wie jetzt) ​​und nicht versuchen, eine Konvertierung durchzuführen ... Obwohl es selbst so ist, 4 zusätzliche Codezeilen - na ja, weniger oder mehr akzeptabel, denke ich :)

Meine erste Antwort deutete an, dass er davon ausgeht, dass diese Konvertierung von 16/17 -> (16/17) implizit vom Compiler selbst (und nicht von der Funktion) durchgeführt wird.

Apropos Optionen. In einer perfekten Welt würde ich davon träumen, dass es dafür überhaupt keine Optionen gibt (dh es sollte das einzige sein und der Rest als veraltet markiert und schließlich entfernt werden) ... All diese zusätzlichen Optionen machen die Codebasis nicht -wartungsfähig.. selbst für eine winzige einzeilige Korrektur/Änderung wächst die Anzahl der Edge-Cases, die Sie vorhersagen müssen, und der Tests, die Sie durchführen müssen, exponentiell... (fast ohne Grund).

Ich dachte nur, es wäre ungefähr so:

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

Apropos Optionen. In einer perfekten Welt würde ich träumen, dass es dafür überhaupt keine Optionen gibt

Ich stimme zu. Aber wir werden die Optionen kurzfristig brauchen. Vor allem, wenn wir von strikter Mathematik und Legacy-Verhalten abweichen. Sie können beide als veraltet markiert werden, wenn wir eine "intelligentere Mathematik"-Option perfektionieren.

Helper.convertMath(arguments);

arguments ist zu optimistisch.
Bestenfalls (nicht nur percentage zählend - was sowieso irgendwie nutzlos ist , sondern jede andere Funktion, die ein numerisches Argument erwartet) wäre eine minimale Anforderung:

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"); 
} 

Aber das war nicht wirklich mein Punkt, was ich meinte, ist wahrscheinlich so etwas wie: während dies immer möglich ist / war, macht sich niemand die Mühe, solchen Code zu schreiben... (mit ein paar begrenzten Ausnahmen wie )...

Ja, ich verstehe dich.

percentage(16 / 17) wirft nur einen Fehler

wäre sicher eine verbesserung. (Ich kann mir nicht vorstellen, dass NaN% eine nützliche Ausgabe wäre.)

Was die Funktionen anbelangt, die versuchen würden, ihre Argumente schlau zu machen, gibt es keinen Grund, alles vorwegzunehmen. Eine Hilfsfunktion, wie @matthew-dean vorschlägt, könnte ziemlich einfach implementiert werden, wenn Funktionsanfragen gestellt und diskutiert werden, um bestimmte Funktionen intelligenter zu machen.

Tatsächlich würde ich von Anfang an sagen, dass nur die mathematischen Funktionen mit ihren Argumenten klug umgehen sollten.

Bearbeiten: Eigentlich immer wenn einer mathematischen Funktion nur ein Argument übergeben wird.

Wie ist der Stand dazu? Wir erhalten Beschwerden, dass LESS versucht, ungültige CSS-Eigenschaften als Mathematik zu analysieren. zB lost-column: 1/3; Pausen.

Es scheint auch, dass http://www.w3.org/TR/css-grid-1/#grid -template-rowcol nicht mit LESS funktioniert.

Kann jemand dies so patchen, dass jemand explizit LESS verwenden möchte, um eine Division für eine Eigenschaft durchzuführen, dass er sie in Klammern oder so einpacken muss?

@corysimmons Hast du das nicht gerade auf #2769 gefragt und eine Antwort bekommen? o_O

Eine Sache, die wir beim ersten Mal nicht diskutiert haben. Es scheint, dass der einzige wirkliche mathematische Konflikt die Spaltung ist. Und Division ist im Wesentlichen ein Problem, weil wir im Wesentlichen ein CSS-"Trennungs"-Zeichen "umfunktionieren".

Anstatt zu versuchen, die Division auf verschiedene Weise zu "umhüllen" oder die gesamte Mathematik zu umhüllen (als unsere erste Lösung für dieses Problem), frage ich mich, warum wir nie über das Offensichtliche gesprochen haben: _einen bestehenden Operator gar nicht neu zu verwenden_, besonders wenn es a) macht Less Code mehrdeutig, b) verursacht Konflikte.

Nachdem wir Zeit hatten, dies zu verdauen, verursacht das Einschließen von Mathematik in Klammern, selbst wenn es nur eine Division ist, _still_ Mehrdeutigkeit für die Fälle, in denen die Mathematik bereits in Klammern steht. (Was auch bedeuten könnte, dass Klammern eine falsche Wahl von "math wrapper" waren.)

Warum also nicht / als Divisionsoperator ablehnen? Ich weiß, dass es ein gängiges Divisionssymbol ist, aber es gibt andere Syntax-Kompromisse, die Less unternommen hat, um CSS zu erweitern. Und mir ist jetzt klar, dass wir im Grunde versuchen, ein Problem zu umgehen, das von Less in erster Linie erzeugt wird, indem wir den einzelnen Schrägstrich verwenden. Wir schaffen Mehrdeutigkeit und versuchen dann, die Mehrdeutigkeit umzukehren.

Um fair zu sein, die anderen mathematischen Symbole werden in anderen Teilen von CSS alle umfunktioniert, es ist nur so, dass ihre Verwendung in der Mathematik keine Mehrdeutigkeit verursacht.

Ich wollte ein paar Ideen vorschlagen, aber siehe da, es gibt bereits Standard-Alternativen zur Division. Abgesehen von ÷ , das nicht auf der Tastatur ist, habe ich Folgendes gefunden:

Das Divisionszeichen ist auch mathematisch äquivalent zum Verhältnissymbol, das üblicherweise durch einen Doppelpunkt (:) gekennzeichnet wird und "ist zu" lautet. Somit gilt für jede reelle Zahl x und jede reelle Zahl y ungleich Null diese Gleichung:

x ÷ y = x : y

Mit anderen Worten:

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

Ich weiß, dass es ein wenig Parser-Optimierung erfordern würde, einen Doppelpunkt in der Mathematik zu verwenden, aber anscheinend ist es mathematisch logisch. Ich kann mir keine anderen Symbole vorstellen, die einen besseren Ersatz darstellen würden. Vielleicht | als zweite Wahl? Es wäre jedoch willkürlicher.

Die Gedanken?

_Alternativ_ könnten wir immer noch das Divisionssymbol in Klammern und/oder Klammern unterstützen, wie in:

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

Yep, deshalb habe ich anfangs mit ./ angefangen (inspiriert vom Matlab-Vektor-div-Operator, es sind zwei Syms, aber optisch ist es wahrscheinlich das am wenigsten schwere wegen des leichten Punktes, obwohl es im Kontext von Weniger den Punkt nicht verdirbt eine geniale Idee).
: - Dies wird wieder Gänseblümchen drängen, dieses Symbol wird in zu vielen CSS-Kontexten verwendet. Tatsächlich gibt es bereits widersprüchliche Syntax:

.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 Ah, ja, verdammt. WENN NUR DIE TASTATUR GRÖSSER WÄREN. Ja, eine 2-Zeichen-Sequenz für die Division scheint unvermeidlich. Es ist lange her, dass ich den ganzen Thread durchgelesen habe, also habe ich das vergessen. ./ Es ist wirklich nicht schlimm. Wenn sowohl Sie als auch @lukeapage an Bord sind, wäre das kein schlechter Kompromiss. Vielleicht verschieben wir das in die Vorschlagsphase und sehen, ob es Einwände gibt?

Zurücklesen, bis hierhin:

nicht zu zählen ist auch ein Leerzeichen vor . erforderlich, zB 16 ./17 und nicht 16./17

Ich bin mir nicht sicher, ob ich zustimme. Ja, 16. ist technisch gesehen eine gültige Zahl, aber es wäre bizarr, wenn jemand sie so schreiben würde. Ich denke, egal wie Sie es schreiben würden, Leerzeichen oder nicht, es sollte 16 durch 17 teilen.

Es wird keine perfekte Option geben, aber ich denke, es ist besser, als a) standardmäßig / für die Division zu verwenden, b) immer Klammern zu erfordern. (Trotz meiner Positionen in der Vergangenheit bin ich auch dazu gekommen, ja, das ist irgendwie nervig, vor allem in anderen Klammern. Und vor allem, weil es meines Wissens nur wegen der Aufteilung erforderlich ist. Ja?)

Ich denke, egal wie Sie es schreiben würden, Leerzeichen oder nicht, es sollte 16 durch 17 teilen.

Ja, in der Tat.
Obwohl ich mehr darüber nachdenke, erwarte ich, dass ./ dem Parser einige zusätzliche Tricks hinzufügt (Zahlen-Parsing benötigt einen zusätzlichen Blick in die Zukunft, um vor ./ zu stoppen, während es derzeit immer am Ende . frisst ).

Und vor allem, weil es meines Wissens nur wegen der Teilung erforderlich ist. Ja?)

Ja genau. Ohne den Code in calc - aber für diesen sollte die von @lukepage vorgeschlagene Lösung den Zweck erfüllen .

(Technisch gesehen könnte es in Zukunft für +, -, * eine zusätzliche Mehrdeutigkeit geben, wenn sie bei der Syntax ihrer CSS- * 20% (also sie können eindeutig als nicht weniger bewerteter Ausdruck erkannt werden. Nach all diesen Spaßen werden sowieso einige Änderungen beim Parsen erforderlich, da derzeit Werte wie (* 20%) einen Parsing-Fehler verursachen).

Vielleicht... haben wir das alles falsch gemacht. (Ich schließe mich auf jeden Fall mit ein, da ich ein anfänglicher begeisterter Unterstützer der Funktion "strenge Mathematik" war.)

Wir versuchen, Mathematik universell zum Laufen zu bringen, aber .... das muss nicht wirklich. Das heißt, wir versuchen, Mathematik in Fällen durchzuführen, in denen es offensichtlich sein sollte, dass keine Mathematik durchgeführt werden sollte.

Das Beispiel calc(100% - 10px) ist das offensichtlichste. Es gibt keine Less-Berechnung, die durchgeführt werden kann/sollte, es sei denn, wir werfen Einheiten, was Less meiner Meinung nach standardmäßig aufhören sollte. ¹

Betrachten wir als Beispiel die Eigenschaft „Schriftartkürzel“.

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

Die aktuelle Problemumgehung hierfür besteht darin, strict-math: on für die Font-Eigenschaft zu aktivieren. Aber... warum sollte Less überhaupt Berechnungen anstellen? Sicher, 13px/150% ist eine gültige Aussage in der Mathematik, aber ist es vernünftig, sie in Less als gültig zu behandeln? 12px/30px Sie _könnten_ als gültige mathematische Aussage behandeln, aber sollten Sie das? ²

Das heißt: In Less sollten mathematische Operationen an Einheiten von _Ganzzahlen_ und _Floats_ ausgeführt werden, nicht von Einheiten. Wir behandeln diese als gültige mathematische Aussagen, als ob die Leute ihre Mathematik tatsächlich auf diese Weise schreiben würden. Aber ich sehe nicht, wie das wahr sein könnte.

Das heißt, es ist vernünftig zu verlangen, dass jemand 13px/150% als 13px/1.5 schreibt. Und selbst wenn wir die Tatsache ignorieren, dass 12px/30px als mathematische Operation keinen Sinn machen würde, müssen wir nicht wissen, dass dies nicht der Fall ist, und wir müssen font nicht auf die weiße Liste setzen . Wenn ein Less-Autor eine mathematische Operation durchführen würde, würde er sie vernünftigerweise 12px/30 schreiben. Das wäre nicht nur vernünftig, sondern es ist auch sehr wahrscheinlich, dass _so sie es überhaupt schreiben_.

Es ist für mich üblich, ein Mixin zu schreiben oder sogar so etwas in einem einzigen Block zu verwenden:

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

Warum sollte ich es so schreiben? Schreibt es _jemand_ so?

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

Die Operation _sort of_ ist sinnvoll, wenn @size eine px Einheit ist, aber unabhängig davon macht es im Bereich von LESS/CSS weniger Sinn, im letzteren Fall zu rechnen, wenn der Divisor ist ein Wert mit einer Einheit. Das zweite sieht nicht nach Mathematik aus. Es sieht aus wie ein CSS-Wert.

Wenn wir aufhören würden, mathematische Operationen für Multiplikation oder Division durchzuführen (nur Division für Mehrdeutigkeit erforderlich, aber Multiplikation auch für logische Konsistenz), wenn der Multiplikator oder Divisor ein Wert mit einer Einheit ist, würde dieses Problem meiner Meinung nach weitgehend verschwinden. Im Gegensatz dazu _sind_ Einheiten für Addition und Subtraktion logisch, müssen aber wahrscheinlich nicht benötigt werden (so ist es jetzt).

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

Wenn Sie jedoch einen Wert mit einer Einheit zu einem anderen mit einer anderen Einheit hinzufügen / subtrahieren, sollte Less es in Ruhe lassen.

<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);

Das Erfordern übereinstimmender Einheiten für die Addition / Subtraktion (oder Integer / Float) und das Erfordernis von Integern / Floats in mathematischen Operationen gegen Einheiten (keine Einheiten multipliziert / dividiert durch Einheiten) würde 99% der Mehrdeutigkeiten lösen und dennoch gültige mathematische Operationen ohne neue Symbole ermöglichen .

Basierend auf diesen Regeln wäre beispielsweise die Hintergrundkürzel in Ordnung:

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

% ist eine CSS-Einheit. px ist eine andere CSS-Einheit. Daher keine Mathematik. Die besondere Ausnahme wäre eine Null.

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

Wenn jemand Null durch eine andere Zahl dividiert oder eine Zahl durch Null dividiert, können wir meiner Meinung nach einfach so ausgeben, wie es ist.

Grenzradius, dasselbe:

border-radius: 30% / 20%;

Weniger würde es durchgehen. Wenn jemand Mathe machen wollte, wäre die richtige Schreibweise:

border-radius: 30% / 0.2;

Das Schöne daran ist, dass durch diese Unterscheidungen offensichtlich ist, dass eine mathematische Operation _kein_ CSS-Wert sein kann, da ein gültiger CSS-Wert wie im Beispiel border-radius Einheiten auf beiden Seiten erfordern würde. Es würde keine Überschneidungen / Mehrdeutigkeiten geben.

Außer einem Fall fällt mir ein, und vielleicht gibt es noch andere:

font: 10px/1.5;

Sie können (und sollten normalerweise) die Zeilenhöhe nur als Zahl darstellen. (Aber sollte wahrscheinlich auch keine Schriftart-Kurzschrift verwenden.) Aber wenn wir es auf einen Fall reduziert haben, ist das ziemlich gut. Das Aktivieren der strengen Mathematik für font (außer für interne Funktionen innerhalb des Fontwerts) ist eine gute Lösung. (Ich bin mir nicht sicher, ob es keinen besseren gibt, aber er funktioniert.) Und es ist immer noch die Lösung mit dem geringsten Schaden, da diese Schriftart-Kurzschriftwerte normalerweise in importierten UI-Stilbibliotheken, CSS-Resets oder benutzerdefinierten Schriftart-Stylesheets erscheinen.

Es gibt also immer noch eine Verwendung für strenge Mathematik, aber ich denke, mit diesen Änderungen ist dies weniger der Fall und wird möglicherweise in Zukunft nicht mehr als Option benötigt.

Ich freue mich über die Antworten / Kommentare der Galerie.

¹ _Mir wurde klar, dass ich klarstellen sollte, dass die Kommentare von @lukeapage und der Link von @seven-phases-max dazu veranlasst haben, in diese Richtung zu denken, um noch einen Schritt weiter zu gehen._
² _Wie ich beim Betrachten von Beispielen festgestellt habe, kann es eine unvermeidliche Lösung sein, strikte Mathematik für Schriftarten zu aktivieren, aber ich denke, der Rest der Logik trifft zu._

Nur für einen historischen Kontext ist es wichtig zu beachten, dass das Casten von Einheiten bei der ersten Veröffentlichung von Less.js kein so großes Problem war. calc() wurde nicht implementiert und background und border-radius hatten keine Schrägstriche als gültige Werte. Ich denke, font war der einzige Ort, an dem die Dinge zum Stolpern gebracht wurden (was ironischerweise immer noch der Fall sein kann).

Meine einzige Sorge ist die Implementierungsseite, zB: für calc(4px + 2rem + 20%) (die tatsächlichen Einheiten spielen keine Rolle) führt die erste Addition zu einem nicht mehr numerischen Ergebnis, daher kann der zweite Additionshandler seine Eingabe nicht von unterscheiden was auch immer not-a-number + 20% Anweisung, bei der ein Fehler ausgegeben werden soll. Wahrscheinlich kein großes Problem (lösbar durch das Setzen zusätzlicher Typ-/Typ-Flags), bedarf aber noch einiger Untersuchung.

Und die andere Sorge ist, ähm, nicht sicher, "Reparierbarkeit"? Dh während das Ergebnis für explizite Zahlen kristallklar aussieht, sieht es bei Variablen ziemlich zweideutig aus, zB: border-radius: 10px <strong i="8">@a</strong> / <strong i="9">@b</strong> 30px; - man weiß nie was das bedeuten soll, bis man @a und @b sieht

Und ja, font bleibt immer noch ein Problem (wahrscheinlich scheinen andere Kürzel-Eigenschaften Einheiten auf beiden Seiten zu verwenden, aber wir wissen nie, was sie als nächstes bringen (auch wenn man Dinge wie #2769) zählt... A noch ein paar Leckereien wie font und es wird wieder kaputt aussehen).

PS Noch ein Problem (vielleicht eine kleine Regression). Es gibt Werte wie:

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

Dh damit das Ganze funktioniert, müssen wir alle aktuellen inkompatiblen-div-Operandenfehler deaktivieren, damit alle foo/bar , 1x/bar und foo/1x ohne weiteres passieren können Error.

Meine einzige Sorge ist die Implementierungsseite, zB: for calc(4px + 2rem + 20%) (tatsächliche Einheiten spielen keine Rolle)

Dies ist, was ich sage. Die tatsächlichen Einheiten sollten wichtig sein. Weniger sollte das in Ruhe lassen, egal. 4px + 2rem hat eine Bedeutung im Browser, ist aber in Less bedeutungslos. Es gibt keinen Grund, es hinzuzufügen, wenn es keinen Sinn macht und diese Add-On-Probleme verursacht.

zB: border-radius: 10px <strong i="10">@a</strong> / <strong i="11">@b</strong> 30px ; - Sie wissen nie, was das bedeuten soll, bis Sie die Definitionen @a und @b .

Dies ist ein Fall, in dem wir den Stilautor nicht vor sich selbst retten können (wie beim ersten Beispiel, wenn jemand aus irgendeinem Grund tatsächlich versucht hat, Pixel zu rems hinzuzufügen). Ich bin sicher, es gibt alle möglichen existierenden Beispiele, bei denen jemand seinen WENIGER-Code schreiben könnte, um verwirrend zu sein. Das gibt es überall.

Betrachten Sie mit diesen mathematischen Regeln, die ich vorschlage, Folgendes:
calc(4px + 2rem - 2px)

Weniger könnte/würde das als calc(2px + 2rem) berechnen, was eigentlich vollkommen in Ordnung ist und eigentlich eine korrekte Wertausgabe ist. Im Moment berechnet Less es als calc(4px) , was keine richtige oder nützliche Antwort ist. (Ja, es ist derzeit richtig, wenn wir Einheiten weglassen, aber Einheiten sind nicht bedeutungslos und bis auf wenige Fälle nicht interoperabel.) Less berechnet 2px + 100% als 102px , als ob es einen Wert in gäbe dieses Ergebnis, wenn niemand das möglicherweise als Ergebnis haben möchte.

Damit das Ganze funktioniert, müssen wir alle aktuellen inkompatiblen-div-Operand-Fehler deaktivieren, damit alle foo/bar, 1x/bar und foo/1x ohne Fehler passieren können.

Ich denke, das ist eigentlich die vernünftigste Art, es zu behandeln. Wie bei Funktionen sollte es passieren, wenn es kein Less-Ergebnis gibt. Da / ein gültiges Trennzeichen für mehr als einen Eigenschaftswert ist, kann Less nicht wissen, ob er _nicht_ gültig ist, es sei denn, wir fügen Werte auf der weißen Liste für bestimmte Eigenschaften hinzu. (Nein.) An diesem Punkt ist das Ergebnis nicht tragisch. Wenn ein Pass-Through-Wert im Browser ungültig ist, ist dies visuell erkennbar. Es scheint besser zu versuchen, den Wert an den Browser weiterzugeben, falls er gültig ist, als einen Fehler auszulösen, weil Less sich nicht sicher ist.

Weniger könnte/würde das als calc(2px + 2rem) berechnen

Ich fürchte, dies wird nie der Fall sein, da dies einen brandneuen optimierenden Ausdruckshandler erfordert, der übertrieben wäre (im Grunde wird 4px + 2rem - 2px im Baum als (4px + 2rem) - 2px gespeichert, um 2px + 2rem hat es eine Nachbestellung Motor sein , alle gültige schlurfenden (trivial in diesem speziellen Fall aber für mehr Operanden / Betreiber recht komplex zu werden) , um zu versuchen. aber egal, so dass 4px + 2rem - 2px als Service - Leistung ist in Ordnung (nach alles, wenn Sie 4px - 2px + 2rem tun, ist es optimiert).

Aber was ich mit dieser Bemerkung eigentlich meinte, ist etwas Ähnliches wie:

damit jedes foo/bar, 1x/bar und foo/1x ohne Fehler passieren kann.

Dh (4px + 2rem) - 2px für den expr.evaluator wäre ähnlich wie foo + 2px , also sollte er, um zu funktionieren, auch für diese Art von Dingen keine Fehler erzeugen.
Tatsächlich habe ich foo/bar, 1x/bar, foo/1x getestet und sie bestehen bereits ohne Fehler (seltsamerweise dachte ich, dass sie werfen), aber andere Operatoren führen zu allen möglichen seltsamen Dingen (allerdings nichts wirklich Kritisches, nur eine Frage der Behebung jedes Falles) Einer nach dem anderen).

Ich fürchte, dies wird nie der Fall sein, da dies einen brandneuen optimierenden Ausdruckshandler erfordert, der einen Overkill bedeuten würde (im Grunde 4px + 2rem - 2px wird im Baum als (4px + 2rem) gespeichert - 2px, um 2px + 2rem zu erhalten, hat es eine Neuordnungs-Engine zu sein, um alle gültigen Mischvorgänge zu versuchen (in diesem speziellen Fall trivial, aber für mehr Operanden/Operatoren ziemlich komplex).

Warum schlurfen? Sie reduzieren Operatoren auf derselben Prioritätsebene (der Baum ist also Sum(4px, 2rem, -2px) ), sammeln Terme mit kompatiblen Einheiten (möglicherweise durch vorheriges Normalisieren von Einheiten) und vereinfachen jeden Teil. Es ist symbolische Algebra, bei der die Einheiten als unabhängige Variablen behandelt werden.

Ich würde es gerne selbst schreiben, aber es gibt viele Bibliotheken, die wahrscheinlich besser getestet und wahrscheinlich vollständiger sind. Ich wette, einige Open-Source-Optimierungscompiler, die in Javascript geschrieben sind, haben solche Vereinfachungs-Subsysteme.

Der Punkt ist, dass das Problem zwar nicht einfach zu lösen ist, das allgemeinere Problem jedoch bereits ziemlich gut gelöst ist und ein solches Subsystem für Less.js auf andere Weise nützlich sein könnte.

Sie reduzieren Operatoren auf derselben Prioritätsebene (der Baum ist also Sum(4px, 2rem, -2px)),

Und was genau lässt den Code glauben, dass ein Ausdrucksbaum überhaupt abgeflacht werden kann? (Also mein "Sufflieren" dort geht es nicht um einen bestimmten Deduktionsalgorithmus, sondern um eine Abkürzung für "alle ausprobieren" einschließlich Ihres "Abflachens").

aber es gibt viele Bibliotheken da draußen, die wahrscheinlich besser getestet und mit größerer Wahrscheinlichkeit vollständig sind.

Ich bin mir nicht sicher, ob Sie es ernst meinen. Sie denken also, dass der ganze Code zum Konvertieren von Less-Tree in einen externen Lib-Tree und zurück (nicht mitgezählt, dass keine dieser JS-Libs CSS-Einheiten verarbeiten kann) tatsächlich diesen speziellen 4px + 2rem - 2p Fall wert ist, um optimiert zu werden? Hmm...

Also überhaupt kein Problem (ich habe nicht gesagt, dass es unmöglich ist, nur dass es sich nie lohnen wird) - Versuch und PR sind willkommen.
(Auch für den Fall, dass es wahrscheinlich wichtig ist zu beachten, dass die Sache mit der Optimierung von Unterausdrücken nicht einmal das Ziel dieses Tickets ist, nicht einmal in den Top 3).

Und was genau lässt den Code glauben, dass ein Ausdrucksbaum überhaupt abgeflacht werden kann? (Also mein "Sufflieren" dort geht es nicht um einen bestimmten Deduktionsalgorithmus, sondern um eine Abkürzung für "alle ausprobieren" einschließlich Ihres "Abflachens").

Der Parser bestimmt, ob der Kontext zB "Länge" ist und ob der Teilbaum als "Länge" interpretiert werden kann.

Ich bin mir nicht sicher, ob Sie es ernst meinen. Sie denken also, dass der ganze Code zum Konvertieren von Less-Tree in einen externen Lib-Tree und zurück

Es muss in einen Syntaxbaum geparst werden. Von dort aus wäre es relativ einfach, einen String auszugeben, der einen algebraischen Ausdruck darstellt. Zurückgehen könnte schwieriger sein: Es muss möglicherweise erneut aus einem String geparst werden, oder ja, es muss möglicherweise den Baum der externen Bibliothek nehmen. Der Schwierigkeitsgrad hängt davon ab, welche Bibliothek ausgewählt wird.

(Nicht mitgezählt, dass keine dieser JS-Bibliotheken mit CSS-Einheiten umgehen kann)

Sie würden einfach Einheiten in algebraische Variablen umwandeln. Ersetzungen (zB mm -> px ) können sogar vorgenommen werden, während der Ausdruck in symbolischer Form vorliegt.

lohnt es sich eigentlich, dass speziell 4px + 2rem - 2p fall optimiert werden?

Ich mache einen alternativen Vorschlag für die Ausdrucksoptimierung, der weniger schwierig ist (als ein Algorithmusproblem, das Less' eigener Code lösen muss) und allgemein nützlicher ist als das, was Sie für notwendig hielten.

Die algebraische Vereinfachung kann Dinge mit in Klammern gesetzten Unterausdrücken lösen und es Less ermöglichen, mehr mathematische Funktionen hinzuzufügen.

versuchen und PR ist willkommen.

Ich werde es versuchen. Ich habe erst heute angefangen, nach Less zu suchen, und ich habe Probleme, Projekte abzuschließen, also gebe ich zu, dass ich wahrscheinlich keine PR herausbringen werde.

Für alle Fälle ist es wahrscheinlich wichtig zu wissen, dass die Sache mit der Optimierung von Unterausdrücken nicht einmal das Ziel dieses Tickets ist, nicht einmal in den Top 3

Ich weiss. Ich war aus einem der Gründe hier. Warum so ein Biss?

Warum so ein Biss?

Nun, vielleicht... Wenn ja - Entschuldigung (wie es aussieht, bin ich einfach zu schockiert über die Bemühungen und die Zeit, die jemand bereit ist, sich der Lösung eines so gut wie nicht existierenden calc(4px + 2rem - 2px) Problems zu widmen. Wahrscheinlich haben wir einfach eine ganz andere Vorstellung der Leichtigkeit).

und erlauben Sie Less, mehr mathematische Funktionen hinzuzufügen.

Könnten Sie einige nennen?

so ziemlich nicht existierendes calc(4px + 2rem - 2px) Problem zu lösen

Hä? Weniger kann damit überhaupt nicht umgehen. [Rest gelöscht, da ich das, was angesprochen wurde, falsch verstanden habe]

Um den Vorschlag zu vereinfachen / neu zu formulieren - Mathe-Änderungen wären wie folgt

1. Addition und Subtraktion würden nur auf gleichen Einheiten berechnet. zB 1px + 2px = 3px , 1px + 1vh = 1px + 1vh
2. Division und Multiplikation würden nur mit einheitenlosen Divisoren/Multiplikatoren berechnet. zB 10px/2 = 5px , 10px/5px = 10px/5px
3. Wertverhältnisse ohne Einheiten würden ähnlich wie Nr. 2 behandelt. zB 1/3 = 1/3
4. Zur Vereinfachung können Ausdrücke mit teilweise ungültigen Unterausdrücken als ungültiger mathematischer Ausdruck behandelt und unverändert ausgegeben werden. zB 1px + 2vh / 2 = 1px + 2vh / 2

Dieser Vorschlag löst Folgendes (aus diesem Thread):

• font: 10px/5px und ähnliche (Verhältnis-)Syntax (keine Berechnung)
• calc(100vh - 30px) (keine Berechnung)
• lost-column: 1/3 und ähnliche benutzerdefinierte Verhältnissyntax (keine Berechnung)

Gleichzeitig würden diese Änderungen 99% der typischen weniger mathematischen Nutzung beibehalten. Außerdem ermöglichen die vorhandenen Funktionen unit() und convert() Benutzern, Werte in kompatible Einheiten für die Mathematik umzuwandeln.

Weniger kann damit überhaupt nicht umgehen.

Du hast einfach nicht gelesen, was ich und @leewz oben calc(100vh - 30px) zu tun. Und mein "ziemlich nicht vorhandenes Problem zu lösen" geht einzig und allein darauf, "arithmetische Ausdrücke in calc zu optimieren".

@seven-phases-max Ohhh richtig. Verzeihung. Nein, wir müssen nicht optimieren. Überleg dir einfach, wann du rechnen musst.

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität hatte. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Vielen Dank für Ihre Beiträge.

Das Entfernen des Slate-Labels ist immer noch wichtig und wird mit der Entwicklung von CSS nur noch schlimmer.

@matthew-dean
Ich werde hier für einen Moment den Advokaten des Teufels spielen...

12px/30px Sie _könnten_ als gültige mathematische Aussage behandeln, aber sollten Sie?

Ja; Du solltest. Es berechnet einen Skalarwert, der ein Verhältnis zwischen beiden Größen darstellt und der bei der Umrechnung in die em-Einheit sehr nützlich sein kann.

Nehmen wir an, ich habe eine bekannte Basisschriftgröße von 16px und eine bekannte Überschriftengröße von 24px, die beide in Variablen versteckt sind, und dann möchte ich eine bestimmte Überschrift mit der richtigen Schriftgröße zuweisen, aber in einer em-Einheit.

@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;
}

Und wenn Sie die Aufteilung kompatibler Einheiten als mathematischen Ausdruck unterstützen müssen, müssen Sie weiterhin eine Möglichkeit unterstützen, literales CSS von weniger mathematischen Ausdrücken zu unterscheiden, um jede Hälfte der Fälle abzudecken.

Zugegeben, dies könnte die Verwendung von Parens beinhalten, um einen mathematischen Ausdruck zu erzwingen und standardmäßig ein CSS-Literal zu verwenden. Aber das scheint falsch und fehleranfällig. Es erfordert viele vorgefertigte Sonderfälle wie in den Abkürzungen border-radius und font und erfordert, dass sich Less ständig über diese auf dem Laufenden hält. (Wie durch einige der neuen Gittereigenschaften gezeigt wurde, die das gleiche Problem mit dem Divisionszeichen entwickeln.)

So...

Warum drehst du deine Argumentation nicht um? Wenn etwas wie ein mathematischer Ausdruck aussieht und kompatible Einheiten hat, wird es standardmäßig als mathematischer Ausdruck behandelt. Und wenn Sie das nicht wollen ... na ja; Benutze dann die ~"..." Fluchtluke. Es ist schließlich genau das, wofür es da ist...

Meine aktuelle Vision des Vorschlags:

• Hören Sie auf, / überall als Division zu behandeln
  Somit werden nur 1anything./3whatever und (optional) (1anything/3whatever) von Less ausgewertet.
• + , - und * bleiben unverändert
• calc subissue wird gelöst , indem nicht-Auswertung jede arithm. Ausdrücke innerhalb von calc(...) (obwohl redundante Parens auch ihre Wirkung haben können).

@sieben-phasen-max

Das Problem dabei ist, dass / als Divisionsoperator unglaublich tief verwurzelt ist. Die Verwendung eines anderen Symbols dafür wäre für Benutzer ein schwieriger Verkauf. Sie nehmen den allgemeinen Anwendungsfall und werfen ihn für den außergewöhnlichen Anwendungsfall ( / in CSS-Kurzschrift) weg, den kaum jemand jemals verwendet.

@rjgotten

Das Problem dabei ist / ist unglaublich tief verwurzelt als Divisionsoperator.

Nicht in CSS.

für den außergewöhnlichen Anwendungsfall (/ in CSS-Kurzform), den kaum jemand jemals verwendet.

Inzwischen wird / bereits viel verwendet , und im Vergleich dazu ist die Less-Div-Operation heutzutage viel außergewöhnlicher als CSS / (anders als noch vor ein paar Jahren, wo CSS / konnte meistens nur innerhalb von font ).

@seven-phases-max Danke, dass Sie den Überblick behalten. Ich habe den Stale-Bot hinzugefügt, um uns bei der Verwaltung von Problemen zu helfen, und habe ziemlich viel Zeit zum Markieren von veraltet eingeräumt. Ich habe auch zwei Labels ausgenommen, "bug" und "up-for-grabs". Vorschläge dazu sind willkommen, z. B. andere Labels auf die Whitelist. Datei ist hier: https://github.com/less/less.js/blob/3.x/.github/stale.yml

Zurück zum Problemthread...

@rjgotten
Ihr Anwendungsfall erzeugt ein willkürliches Problem. Das Argument ist, dass es nützlich ist. Aber wenn Sie Ihre Variablen auf diese Weise strukturieren, entsteht ein Problem, das mit der Syntax vermeidbar ist, die, wie @seven-phases-max betonte, mehrdeutig ist.

Selbst für bare Münze genommen, mit CSS als Leitfaden für die Less-Prinzipien, können Sie in Calc 12px nicht durch 30px teilen. Dies führt in Less nicht nur zu einem Mehrdeutigkeitsproblem, sondern bricht auch ohne triftigen Grund (außer historisch) vom Modell ab. Wahrscheinlich fehlt bei Less nur eine Möglichkeit, den numerischen Wert eines Einheitswerts zu extrahieren, damit Less diese mathematische Magie für die Division nicht ausführen muss.

Die einfache Antwort lautet also, dass Ihr Beispiel in etwa so aussehen würde:

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

Aber ich bin auch mit dem Vorschlag von @seven-phases-max einverstanden. Wir könnten _vars_ immer noch in calc() auswerten, aber nicht in Mathematik. Und werten Sie die Division nicht außerhalb von Parents aus. Ich denke, es ist ein guter Kompromiss. Und wenn Sie möglicherweise die magische Divisionsmathematik beibehalten möchten, bei der eine Einheit durch eine Einheit geteilt wird, die Einheit jedoch beibehalten wird (was immer noch seltsam ist, aber das ist in Ordnung), könnte dies innerhalb von Parens passieren.

Ich weiß, dass es in Less ein paar unterschiedliche Vorlieben zum Thema Mathematik gibt, aber ich denke, es wäre wirklich großartig, wenn wir einen Konsens über etwas erreichen könnten, das die wenigsten Nebenwirkungen verursacht und am einfachsten zu argumentieren ist, ohne dass eine große Wartung verursacht wird oder Entwicklungslast.

Ich denke, wir sind uns alle einig, dass der aktuelle (Standard-)Ansatz für Mathematik in Less nicht funktioniert. Und wir hatten das Feedback erhalten, dass parens – alles als Standard war einfacher zu argumentieren, aber mühsam. Ich hoffe also auf einen guten Mittelweg, den wir bald als Standard einsetzen können (wahrscheinlich in 4.0?)

Wahrscheinlich fehlt in Less nur eine Möglichkeit, den numerischen Wert eines Einheitswerts zu extrahieren

Die Funktion unit tut dies tatsächlich, wenn Sie keinen zweiten Parameter angeben. Aber das ist eher ein Nebeneffekt der Tatsache, dass Skalare derzeit mit einem Dimension Knotentyp implementiert werden, für den keine Einheit definiert ist.

Gewährt; es geht den ganzen Weg, aber wenn Sie _wirklich_ vermeiden möchten, Dimensionen zu teilen, die kompatible Einheiten haben, dann würde das Abreißen der Einheit funktionieren.

Ich möchte auch hinzufügen, dass ich in diesem speziellen Kontext stark gegen alle Vermutungen über "kompatible Einheiten" bin (wie etwa a/b eine Division bleiben und b/c keine Division sein soll).
Einfach weil:

• außergewöhnliche Handhabung ist die Wurzel allen Übels (zB #3047 - siehe unten, http://stackoverflow.com/questions/19705791 - Ich erinnere mich, dass ich den Grund für das SO-Problem nicht finden konnte, bis ich tatsächlich jede der unzähligen Zeilen durchgegangen bin des beteiligten Less-Codes in einem Debugger).
• und am wichtigsten ist, dass es einfach nicht zukunftssicher ist, dh wenn eine größere Breaking-Änderung unvermeidlich ist, sollten wir besser sicherstellen, dass sie einmal (und idealerweise für immer) durchgeführt wird ... und nicht, dass sie ein neues CSS-Feature mit a/b hinzufügen.

Für mich ist "Kompatible Einheiten" also eher eine völlig unabhängige und orthogonale Sache (es könnte einige Diskussionen über resultierende Einheiten mit oder ohne -su , aber das ist eine andere Geschichte).

(offtopic:)
Und übrigens, wenn wir von obigen Beispielen sprechen:
@rjgotten, wenn Sie haben:

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

irgendwo in Ihrem Code und eine der beiden Variablen ist px Sie verwenden tatsächlich einen Fehler :)
Der richtige Code lautet:

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

Dies führt immer zu einer gut definierten Einheit gemäß http://lesscss.org/features/#features -overview-feature-operations (zählt #3047 zu beheben, ist der Fehler wieder ein Beispiel für einen Fehler, der genau durch zu viel erzeugt wird Vermutungscode um "kompatible Einheiten" in der Codebasis). Keine wirkliche Notwendigkeit für --su , number , unit bla-bla ... Aktuelles -su Verhalten wie "nur einen Fehler aus , wenn Sie inkompatible Einheiten siehe" , also eine einfache Validierung, ist mehr als in Ordnung (für mich). Ich sehe keine Notwendigkeit für 1px/2px->.5 und 1px*2px->2px^2 Mambo-Jambo Overengineering. Aber auch dies ist eine andere Geschichte, die nichts damit zu tun hat).

@sieben-phasen-max

tatsächlich einen Fehler verwenden

Ähm.. ja; du hast natürlich recht. Zum Glück habe ich diesen Code nirgendwo in der Produktion. Es war nur ein kurzes Beispiel, das zusammengeworfen wurde, um den Punkt zu veranschaulichen.

Ich möchte auch hinzufügen, dass ich in diesem speziellen Kontext stark gegen alle Vermutungen über "kompatible Einheiten" bin (wie a / b eine Division bleiben und b / c nicht sein soll).

Ich glaube, ich war damit eher als Ölzweig für diejenigen an Bord, die nackte Teiler wollen. Aber ich denke, dass Ihr Kommentar [ hier ] der praktikabelste Vorschlag ist. Es war die ursprüngliche Absicht von "strenger Mathematik", Mehrdeutigkeiten zu beseitigen. Ich denke, das Problem wurden Operationen innerhalb von Mixin- und Funktionsaufrufen, die zu allen Arten von Parens innerhalb von Parens führten. Aber im Allgemeinen stimme ich Ihnen zu, dass die Bemühungen, die Mathematik in Less leicht zu machen, es ironischerweise aufgrund der erhöhten Mehrdeutigkeit auch sehr schwierig gemacht haben.

Außerdem habe ich später festgestellt, dass font: 10px/3 eine gültige Kurzschrift ist. Es gibt also wirklich keine algorithmische Lösung, die hier helfen kann.

Um auf deine Frage zurückzukommen, @rjgotten...

Warum drehst du deine Argumentation nicht um? Wenn etwas wie ein mathematischer Ausdruck aussieht und kompatible Einheiten hat, wird es standardmäßig als mathematischer Ausdruck behandelt. Und wenn Sie das nicht wollen ... na ja; dann benutze die ~"..." Fluchtluke. Es ist schließlich genau das, wofür es da ist...

Die Idee/Beziehung von Less zu CSS ist ähnlich wie TypeScript zu JavaScript. Das heißt, benennen Sie Ihr gültiges .css in .less und Sie können mit dem Hinzufügen von Less-Funktionen beginnen. Ähnlich wie Sie .js in .ts umbenennen und TypeScript-Funktionen hinzufügen können. Wenn Sie nichts hinzufügen, sollten Sie das gleiche gültige Less / JavaScript ausgegeben bekommen, da die Sprachen Obermengen der Basissprache sind.

Bei diesen Verhältnissen oder anderen / Teilern in CSS scheitert Less jedoch standardmäßig bereits auf Anhieb. Ihr reguläres CSS wird willkürlich zu einem weniger mathematischen Ausdruck mit einem anderen Ergebnis, obwohl Sie nichts geändert haben. Das verstößt gegen den Vertrag der Sprache. In der Lage zu sein, .less in einen völlig anderen Less-Ausdruck zu ändern, um das ursprüngliche CSS, mit dem Sie begonnen haben, zurückzubekommen, verfehlt den Punkt. Diese Arbeit sollte niemals erforderlich sein. Less sollte nicht erfordern, dass Sie Ihr gültiges CSS in kompatible Less-Ausdrücke ändern, um das gültige CSS zurückzubekommen, das Sie ursprünglich hatten. Das ist nur ein kaputtes Modell.

Die gleiche Argumentation gilt für calc() . Ja, Sie können Ihre Ausdrücke mit String-Escapes versehen, müssen dies aber nicht. .css umbenannt in .less sollte das gleiche effektive CSS erzeugen. Dies sollte das grundlegende Ziel des Projekts sein, das ursprüngliche Stylesheet nicht zu stören / zu überschreiben / zu überinterpretieren. Alles andere versucht, das Problem auf den Entwickler zu übertragen, nur weil er den Parser/die Sprache verwendet.

Ja, Sie können Ihre Ausdrücke mit String-Escapes versehen, müssen dies aber nicht. .css umbenannt in .less sollte das gleiche effektive CSS erzeugen. Dies sollte das grundlegende Ziel des Projekts sein, das ursprüngliche Stylesheet nicht zu stören / zu überschreiben / zu überinterpretieren. Alles andere versucht, das Problem auf den Entwickler zu übertragen, nur weil er den Parser/die Sprache verwendet.

Dass.

LESS weiß, wo / erlaubt ist und wo nicht in CSS. Wo es nicht ist, aber trotzdem erscheint, sollte davon ausgegangen werden, dass Mathematik gemacht wird. Auch wenn Mathematik von runden Klammern umgeben ist, wo runden Klammern in CSS nicht erlaubt sind, sollte von LESS interpretiert werden.

Mit anderen Worten, LESS sollte versuchen, so wenig Mathematik wie möglich zu interpretieren, um zu einem gültigen CSS zu gelangen. Sobald die Ausgabe gültig ist, beenden Sie die Ausführung weiterer Mathematik.

@thany

Zu viele Annahmen über das, was der Compiler weiß (und einige davon sind einfach falsch).
So oder so ist der Modus "die runden Klammern" fast das, was --sm=on tut, also verwenden Sie das und vergessen Sie diesen Thread (höchstwahrscheinlich verwenden Sie in Ihren Projekten nur keine Mathematik außer calc (ein paar eingeführt) Jahre nach der Entwicklung von Less), sodass Sie nicht sehen können, wie nervig die zusätzlichen Eltern sind. Aber andere tun es.)

Für den Rest siehe https://github.com/less/less.js/issues/1880#issuecomment -345194431.

@seven-phases-max Vergiss nicht, dass das / auch in den Abkürzungen background und border-radius eine Bedeutung hat und möglicherweise auch andere, an die ich gerade nicht denke. LESS wird diese gerne als Abteilung behandeln. Mit oder ohne strengen Mathematikmodus sollte LESS "wissen, wann es aufhören muss", seine eigenen kleinen Mathematikaufgaben zu machen.

@thany
LESS sollte "wissen, wann man aufhören muss", seine eigenen kleinen Berechnungen zu machen.

Nein, sollte es nicht. Es gibt keine Möglichkeit zu wissen, wo zukünftige CSS-Shorthands mit dem Divisionsslash erscheinen werden. Dass der Less-Compiler darüber „wissen“ muss, ist ein grundsätzlich fehlerhafter Ansatz und genau das, wofür diese Diskussion versucht, eine Lösung zu finden.

Bisher gibt es zwei vernünftige und vorhersehbare Möglichkeiten für / als Divisionsoperator:

• Behandeln Sie es immer als solches und verlangen Sie eine explizite Escape-Funktion für andere Zwecke.
  Dadurch wird das Verhalten unterbrochen, bei dem die Less-Syntax eine strikte Obermenge der CSS-Syntax ist.
• Behandeln Sie ihn niemals als Divisionsoperator, __ es sei denn__, er befindet sich in einem bekannten mathematischen Kontext.
  Wo bekannter mathematischer Kontext wie im aktuellen --strict-math=on Verhalten entschieden werden könnte/würde.

_{(Außerdem; beachten Sie bitte, dass der Name Less nicht mehr in Großbuchstaben geschrieben wird.)}

Vergessen Sie nicht, dass das / auch in Hintergrund- und Randradius-Kurzzeichen eine Bedeutung hat.

Damit beginnt dieser Thread im Grunde.
Und sehen Sie sich die Zusammenfassung der vorgeschlagenen Änderungen unter https://github.com/less/less.js/issues/1880#issuecomment -345194431 an (ohne Annahmen darüber, was der Compiler wissen sollte oder nicht).

Nein, sollte es nicht. Es gibt keine Möglichkeit zu wissen, wo zukünftige CSS-Shorthands mit dem Divisionsslash erscheinen werden. Dass der Less-Compiler darüber „wissen“ muss, ist ein grundsätzlich fehlerhafter Ansatz und genau das, wofür diese Diskussion versucht, eine Lösung zu finden.

Dem stimme ich voll und ganz zu. @thany Während Sie mir in dem, was Sie zitiert haben, zustimmen, kommen Sie zu einem anderen Schluss als ich. Weniger sollte und kann nicht wissen, wann sie "mit Mathe aufhören" sollen. Was ich sagen würde, ist, dass die entscheidende Änderung darin bestehen sollte, dass Less in erster Linie konservativer ist, wenn es darum geht, mit Mathematik zu beginnen (um das Amerikanisch / Kanadische zu verwenden).

@rjgotten

Behandeln Sie es niemals als Divisionsoperator, es sei denn, es liegt in einem bekannten mathematischen Kontext.
Wo bekannter mathematischer Kontext wie im aktuellen --strict-math=on Verhalten entschieden werden könnte/würde.

Nur um es klarzustellen, dieser Teil (dem ich zustimme):

Behandeln Sie es niemals als Divisionsoperator, es sei denn, es liegt in einem bekannten mathematischen Kontext.

Hat eigentlich 4 mögliche Lösungen, von denen ich weiß, dass Sie sie kennen, aber nur für den Thread zusammenfassend:

1. Machen Sie alle Mathematik nur in Klammern . Dies wurde anscheinend von den Commons abgelehnt, was in Ordnung ist, obwohl es immer noch als optionaler Schalter verfügbar ist ( strictMath ).
2. Rechnen Sie überall, aber teilen Sie nur in Klammern.
3. Rechnen Sie überall, aber teilen Sie nur in Klammern. Es sei denn, der Divisionsoperator wird als ./
4. Mache überall Mathe, aber repariere die Mathematik so, dass 12px/4px nicht zur Division führt. (Multiplikation und Division nur mit einheitenlosen Werten.) Mit anderen Worten, Division überall, aber mit viel konservativeren Regeln. In den Fällen, in denen es die Dinge nicht löst, greifen Sie auf die Flucht zurück. Also keine Komplettlösung, aber immer noch eine (umstrittene) Verbesserung gegenüber der aktuellen Situation.

Aus der Sicht der Benutzerfreundlichkeit mag ich es, Mathematik "intelligenter" zu machen, wie in #4 . Aus technischer und wartungstechnischer Sicht und zum Schutz vor zukünftigen CSS-Änderungen mag ich #3 als die robusteste Lösung.

Ich denke jedoch, dass wir in Wirklichkeit sowohl #3 #4 tun müssten, um calc() zu reparieren. Im Moment ist es ein echtes Chaos, weniger alle Einheiten zu ignorieren, wenn man Mathe macht. 100vh - 12px sollte niemals von Less berührt werden (Klammern oder nicht). Aber IMO auch nicht 12px/4px (Klammern oder nicht), aber ich könnte in dieser Hinsicht in der Minderheit sein.

Ich sehe dies also nicht so sehr als ein "Mathe-Konflikt mit der CSS-Syntax"-Problem, sondern als viel zu aggressiv bei der vorzeitigen Lösung mathematischer Gleichungen.

Multiplikation und Division nur mit einheitenlosen Werten.

Es wird nicht den Zweck erfüllen, da es Dinge gibt wie:

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

und sie sind keine div.

Ich denke jedoch, dass wir in Wirklichkeit sowohl #3 #4 tun müssten, um calc() zu reparieren

calc() ist ein Schmerz. Ironischerweise wird es _wahrscheinlich_ am besten gelöst, indem es als tatsächliche Less-Funktion implementiert wird, die idealerweise ihren geparsten Ausdrucksbaum nehmen und versuchen würde, den Ausdruck zu vereinfachen. Das heißt: es sollte kompatible Komponenten wie 4px + 12px (oder 4px + @a wenn @a bekanntermaßen einen Pixelwert hat) im Voraus berechnen und kombinieren, aber inkompatible Komponenten lassen, z mit inkompatiblen Einheiten, allein.

Z.B

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

sollte irgendwann rendern

width : calc(50% - 6px);

(ich wiederhole mich von https://github.com/less/less.js/issues/1880#issuecomment-345345735)
Und ich sehe keinen Vorteil darin, den Compiler stark zu überarbeiten, um die Ausdrücke in calc zu optimieren. Wenn Sie calc schreiben, können Sie den Browser verwenden, um die Arbeit zu erledigen, egal welchen langen Ausdruck Sie dort haben. Wie bereits oben erwähnt, bin ich für "berühre nichts in calc " (= versuche nicht, schlauer zu sein, als es wirklich nötig ist) und belasse es für den Browser ( oder für einen CSS-Minifier da .) , wenn ich mich recht erinnere, leisten einige von ihnen bereits ziemlich gute Arbeit bei der Optimierung von calc-Unterausdrücken).

Das "intelligente Verhalten von Einheiten mamabo-jambo" erinnert mich an die min/max Monster (aufgeblähter Stapel von nicht wartbarem und nie benutztem Code) - wie sehr ich es bereue, dass ich damals nicht gegen die "Einheiten-Mambo" geschrien habe , oh (Also werde ich hier weiter jammern, bis die Idee der "unterschiedlichen Operator-Semantik je nach Operandeneinheiten" völlig vernichtet ist :P).

PS Sobald calc zu einer Funktion wird, die einen nicht-arithmierten Ausdruck erhält (es wird es sowieso tun müssen), kann man ein Plugin schreiben und es mit der gewünschten Optimierung überschreiben.

@rjgotten
Dass der Less-Compiler darüber „wissen“ muss, ist ein grundlegend fehlerhafter Ansatz

Meiner Meinung nach ein grundsätzlich richtiger Ansatz. LESS ist ein CSS-Compiler, daher macht es allen Sinn der Welt, dass LESS weiß, wozu es kompiliert.

@matthew-dean
Weniger sollte und kann nicht wissen, wann sie "mit Mathe aufhören" sollen. Was ich sagen würde, ist, dass die entscheidende Änderung darin bestehen sollte, dass Less in erster Linie konservativer ist, wenn es darum geht, mit Mathematik zu beginnen (um das Amerikanisch / Kanadische zu verwenden).

Interessant, dass man es sozusagen von der anderen Seite betrachtet. Folgendes schlage ich vor:

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

Was LESS hier tun soll, ist mir klar:

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

Ergebend:

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

Es sollte den 50% / 50px Anteil darin nicht berechnen, weil (1) es wegen inkompatibler Einheiten nicht in der Lage sein sollte und (2) weil dies bereits weit genug für einen background Wert ist . Hier wird es also "aufhören, Mathe zu machen".

Das meinte ich mit WENIGER "wissen, wann man aufhören muss".

Wäre es eine andere Eigenschaft wie diese:

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

Es sollte mit einem Fehler (inkompatible Einheiten) brechen. Eine mögliche Ausgabe wäre 50% / 15px die für diese Eigenschaft ungültig ist. Ein weiteres Ergebnis könnte 5% was es derzeit tun wird, was in jede Richtung einfach falsch ist.
Und:

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

Sollte folgendes ergeben:

padding-left: 10px;

Wie erwartet. Also in diesem Fall, die / ist ungültig für padding-left und wird in LESS genommen und tun ihre Mathe THINGY.

@matthew-dean
Hat eigentlich 4 mögliche Lösungen, von denen ich weiß, dass Sie sie kennen, aber nur für den Thread zusammenfassend:

Einer noch:
5) Verwenden Sie den Operator \ für Divisionen in LESS und verwenden Sie / . MATLAB hat so etwas, und bestimmte Varianten von BASIC haben es verwendet, um eine Ganzzahldivision zu erzwingen. Die Verwendung des Backslashs ist also nicht völlig unbekannt.

/bearbeiten
Wir können uns auch dafür einsetzen, eine ÷ Taste auf Tastaturen einzufügen und diese als Divisionsoperator zu verwenden. Das habe ich in der Grundschule gelernt :)

Was Sie vorschlagen, wurde schon oft diskutiert (zögern Sie nicht, sich die hier referenzierten Threads anzusehen). Also hier sind nur winzige faule Kommentare:

Verwenden Sie den Operator \ für Divisionen in LESS und verwenden Sie / .

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

genug für ein background ... ist ungültig für padding-left

Treffen Sie die "Leute, mein Browser/Polyfill/was auch immer gerade Unterstützung für eine fnord Eigenschaft hinzugefügt/aktualisiert/erweitert hat, würden Sie bitte eine neue Less-Version für mich veröffentlichen?" Ausgabe.
Lernen Sie das Thema font .
usw. usw.
Nun, @rjgotten hat oben bereits kommentiert, warum diese Art von "Wissen" der Weg ins Nirgendwo ist.

@sieben-phasen-max
Backslash war nur ein Vorschlag. Sie können auch ? für die Division verwenden. Es ist nicht wirklich wichtig. Ich schlage vor, nicht ein Zeichen ( / ) zu verwenden, das sehr unterschiedliche und mehrdeutige Bedeutungen hat.

Lernen Sie die "Leute, mein Browser/Polyfill/was auch immer gerade Unterstützung für eine fnord Eigenschaft hinzugefügt/aktualisiert/erweitert hat, werden Sie bitte eine neue Less-Version für mich veröffentlichen?" Ausgabe.

CSS ist ein wohldefinierter Standard. Sie sollten nichts außerhalb des Standards unterstützen. Das ist dein Problem, denke ich. Sie dürfen die Eigenschaft fnord nicht unterstützen, da sie in keinem Standard enthalten ist. Wenn diese neue nicht spezifizierte Eigenschaft auftritt, kann LESS auf sein Standardverhalten zurückgreifen, das die aktuelle sein kann oder Klammern erfordert oder was auch immer, solange es nicht mehrdeutig ist.

Lernen Sie das Problem mit der Schriftart kennen.

Das Problem mit den Schriftarten beweist, dass das / Problem seit den absoluten Anfängen von LESS existiert. Nicht nur, als background die Möglichkeit bekam, einen Wert für die Hintergrundgröße einzufügen, oder als border-radius entstand. Tbh, mit der Angabe des Schriftproblems hast du gerade das beste Argument gegen dich selbst geführt :)

Tbh, mit der Angabe des Schriftproblems hast du gerade das beste Argument gegen dich selbst geführt :)

Ich glaube, du verstehst etwas falsch. Ich war es / als div-Operator vollständig zu entfernen. Also für den Rest nehme ich an, dass es das gleiche Problem ist, dass Sie nicht darauf achten, was Ihnen geantwortet wird.

CSS ist ein wohldefinierter Standard.

Wenn Sie sich an die Spezifikationsteile halten, die auf TR-Ebene die volle Reife erreicht haben, vielleicht.
Ansonsten? Nein, ist es nicht. Es gibt Satellitenspezifikationen neuer CSS-"Module" und Überarbeitungen bestehender Module mit Neuzugängen, die monatlich, wenn nicht wöchentlich, erscheinen.

@sieben-phasen-max

Es wird nicht den Zweck erfüllen, da es Dinge gibt wie: Schriftart: Kapitälchen fett 24px/3 ...

Nein, das verstehe ich. Mein Punkt war genau das: Einheitslose nur div/multiplikation verringert das Problem, löst aber nicht das Problem.

Und ich denke, im Allgemeinen erscheint Ihr Vorschlag von ./ für alle Divisionen immer noch ziemlich logisch.

@thany Anstatt auf all die spezifischen Beispiele zu antworten, werde ich sagen, dass die Bemühungen, weniger Mathematik intelligenter zu machen, den Ball im Allgemeinen nur auf eine andere Yard-Linie schießen werden. Es sind immer noch die gleichen Probleme, nur an einer anderen Stelle. Wie @seven-phases-max gesagt hat, wurde nichts, was Sie vorgeschlagen haben, nicht diskutiert.

Und ich sehe keinen Vorteil darin, den Compiler stark zu überarbeiten, um die Ausdrücke in calc zu optimieren. Wenn Sie calc schreiben, können Sie den Browser verwenden, um die Arbeit zu erledigen, egal, welchen langen Ausdruck Sie dort haben. Wie bereits oben erwähnt, bin ich für "nichts in Calc anfassen" (= versuchen Sie nicht, schlauer zu sein, als es wirklich nötig ist) und belasse es für den Browser (oder für einen CSS-Minifier, wenn ich mich richtig erinnere , einige von ihnen leisten bereits gute Arbeit bei der Optimierung von calc-Unterausdrücken).

Dem stimme ich voll und ganz zu. Wir würden 99% der neuen mathematischen Probleme beseitigen, wenn wir nur calc() weiße Liste setzen würden. Obwohl ich einige Möglichkeiten vorgeschlagen habe, wie Less intelligenter rechnen könnte, um AUCH calc() Probleme zu vermeiden (was es vielleicht sollte), entschuldige ich mich, wenn dies als Argument gegen diese Idee interpretiert wurde. Dies unterstütze ich auch.

Der einzige Vorbehalt (wie hier/an anderer Stelle besprochen) ist, dass ein Entwickler unweigerlich Variablen in calc() möchte, also müssen wir darauf achten, dass wir weiterhin Variablen austauschen, aber tun Sie es einfach nicht Mathematik. Ich bin mir nicht sicher, wie anspruchsvoll das ist. Wenn uns das gelingen würde, würde ich heute eine Änderung der Handhabung von calc() .

@thany

Das Schriftproblem beweist, dass das /-Problem seit den absoluten Anfängen von LESS existiert.

Dies mag stimmen und ist ein angemessener Punkt, aber es gab viele geeignete Problemumgehungen, und es war zu dieser Zeit nicht unbedingt gängige Praxis, die Kurzform der Eigenschaft font . Es ist wirklich so, dass mehrere Hintergründe und calc() aufkamen, nachdem Less begonnen hatte, was dies zu einem größeren Problem machte, und jetzt bedeutet die CSS-Grid-Syntax, dass es jetzt eine Menge Konflikte gibt, wo anfangs in alltäglichen praktischen Begriffen keine existierten.

Übrigens, Sass löst das Problem so, illustriert an diesem Beispiel:

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
}

Es ist kein Eins-zu-Eins, da Sie (derzeit) innerhalb von Argumenten für Less-Funktionen rechnen können, UND Less-Funktionen können Pixelwerte zurückgeben (also könnte Less theoretisch font: print10px()/8px tun? Nein?), also ich Ich füge es nur zur Veranschaulichung ein, nicht als irgendeine Art von Vorschlag. Es ist nur interessant, wie sie das Problem angegangen sind.

Persönlich denke ich, dass es ziemlich verrückt ist, Entwickler dazu zu bringen, sich daran zu erinnern, in welchen Fällen Mathematik auf der Grundlage der Existenz von magischen Ausdrücken auftritt (als würde man ein + voranstellen?), aber jedem das Seine .

Persönlich denke ich, dass es ziemlich verrückt ist, Entwickler dazu zu bringen, sich daran zu erinnern, in welchen Fällen Mathematik auf der Grundlage der Existenz von magischen Ausdrücken auftritt

+1

_{Ganz zu schweigen davon, dass die "Lösung" keines der hier diskutierten Probleme über das hinaus löst, was lessc --sm bereits tut. Und unterschiedliche Ergebnisse für 1/2 und $var/2 sind einfach phänomenal brillant ... ~dummheit~ "Viel Spaß beim Debuggen, Verlierer!"}

@matthew-dean
Übrigens, Sass löst das Problem so, illustriert an diesem Beispiel:

Das ist eine brillante Lösung, ohne auf einen anderen Betreiber zurückgreifen zu müssen.
Wenn der Ausdruck möglicherweise gültiges CSS ist, belassen Sie ihn.

Persönlich denke ich, dass es ziemlich verrückt ist, Entwickler dazu zu bringen, sich daran zu erinnern, in welchen Fällen Mathematik auf der Grundlage der Existenz magischer Ausdrücke auftritt

Verschiedener Meinung sein. Es ist ein einfaches Regelwerk, das sich nicht von anderen Regelwerken (verrückt oder nicht) unterscheidet, an die Sie sich erinnern müssen.

Es gibt ein paar Grenzfälle, in denen Mathematik ohne Absicht vorkommt, aber dann fügen Sie einfach Klammern hinzu und Sie sind fertig.

Ganz zu schweigen davon, dass die "Lösung" keines der hier diskutierten Probleme über das hinaus löst, was lessc --sm bereits tut. Warum sollte ich 0 + 1/2 anstelle von (1/2) schreiben, wenn ich nur eine Division haben möchte? Und unterschiedliche Ergebnisse für 1/2 und $var/2 sind einfach eine phänomenal brillante ... Dummheit "Happy Debugging, Loser!" Botschaft.

Ha, ja, das.

@thany

Das ist eine brillante Lösung, ohne auf einen anderen Betreiber zurückgreifen zu müssen.
Wenn der Ausdruck möglicherweise gültiges CSS ist, belassen Sie ihn.

Um nicht ins Unkraut zu geraten, aber es wird für Less aus syntaktischen Gründen und auch aus sprachlicher Konsistenz nicht funktionieren. Es mag für Sass brillant sein, was ich als fragwürdig bezeichnen würde, aber ich bin aus gestalterischer Sicht nicht persönlich an diesem Projekt beteiligt, also wer soll das sagen. Ich weiß nur, dass die Optionen auf der Tabelle der beste Ausgangspunkt sind, und ich bin zuversichtlich, dass Sie kommen würden, wenn Sie so viel Zeit damit verbringen würden, einige der Nachrichten-Threads zu diesem Problem durchzugehen und sich mit der Sprache zu beschäftigen zum gleichen Schluss.

Eine Beobachtung, der wir uns nicht entziehen können: Wenn Sie gültiges Vanilla-CSS importieren, sollte seine Ausgabe funktional identisch sein. Die einzige Schlussfolgerung, die ich ziehen kann, ist, dass LESS keine Ausdrücke berühren sollte, die bereits möglicherweise gültiges CSS sind. Wie das geht, liegt nicht an mir. Tatsache ist jedoch, dass der Import von Vanilla-CSS unzuverlässig ist, hauptsächlich weil LESS Divisionen zu eifrig ausführt.

Das Importieren von Vanilla-CSS in Sass funktioniert praktisch einwandfrei, denn wie gesagt, Sass lässt den / Operator in Ruhe, wenn er dem Compiler nicht anweist, etwas zu tun, gemäß ein paar einfachen Syntaxregeln. Diese Syntaxregeln beschreiben Möglichkeiten, eine Division zu erzwingen, die in gültigem Vanilla-CSS nicht vorkommen kann, und deshalb ist es brillant.

Sie argumentieren immer noch mit Ihren eigenen Vorstellungen und nicht mit dem, was sie Ihnen sagen. Beantworten Sie die einfache Frage: "Wie kann 0 + 1/2 möglicherweise besser sein als (1/2) ?". Wenn 100%-CSS-Kompatibilität das einzige ist, was Sie interessiert, setzen Sie das schöne -sm und vergessen Sie diesen Thread.

Eine Beobachtung, der wir uns nicht entziehen können: Wenn Sie gültiges Vanilla-CSS importieren, sollte seine Ausgabe funktional identisch sein. Die einzige Schlussfolgerung, die ich ziehen kann, ist, dass LESS keine Ausdrücke berühren sollte, die bereits möglicherweise gültiges CSS sind. Wie das geht, liegt nicht an mir. Tatsache ist jedoch, dass der Import von Vanilla-CSS unzuverlässig ist, hauptsächlich weil LESS Divisionen zu eifrig ausführt.

Diesem Teil stimme ich im Wesentlichen zu, und ich denke, Sie werden in diesem Thread in diesem Punkt viel Zustimmung finden. Die meisten Meinungsverschiedenheiten betrafen Lösungen, wobei jede Lösung verschiedene Nebenwirkungen hatte.

Ich wäre an Bord, wenn es darum geht, diese bahnbrechenden Änderungen als Priorität vorzunehmen:

1. mathematische Klammern außerhalb von Klammern erfordern ./ anstelle eines nackten / . 12px./10px sieht immer noch ein bisschen komisch aus.

@seven-phases-max - Ich möchte den Backslash erneut aufrufen. In diesem Zusammenhang weiß ich, dass Sie https://github.com/less/less.js/issues/1872#issuecomment -35245890 erwähnt haben, aber ich sehe keinen direkten Konflikt, da dies nicht der Fall ist und ich denke, dass es nicht sein kann Teil mathematischer Ausdrücke. Oder liege ich falsch? Ich nehme an, es ist möglich, einen theoretischen Fall wie einen Funktionsnamen mit einem Escape-Zeichen als Teil des Namens zu finden, aber das scheint eher eine intellektuelle Übung als ein realer Fall zu sein. Escapte Selektoren, ja, diese werden aus verschiedenen Gründen häufig verwendet, aber bei Eigenschaftswerten scheint es einfach unwahrscheinlich oder in einem Grenzfall in Ordnung, die historische Problemumgehung (diesen Text einfach ausweichen) zu unterbrechen / zu umgehen.

Können wir ein bisschen mehr untersuchen, dass die Verwendung eines einzelnen Backslashs für die Division zu Konflikten in der realen Welt führen würde? Mein Instinkt ist, dass \ weniger problematisch ist als die aktuelle Situation um / , und es ist entwicklerfreundlicher als ./ . Wenn wir recherchiert und festgestellt haben, dass es machbar ist, könnten wir die entscheidende Änderung vornehmen, um es überall zu verwenden, anstatt den Kontext zu wechseln und / in Klammern zuzulassen. Und dann könnten wir / mit einem Legacy-Switch unterstützen.

1. (zweite Priorität) calc() wird in Sonderbuchstaben geschrieben, damit es Variablen ersetzen kann, aber keine mathematischen Ausdrücke auswertet

Können wir ein bisschen mehr untersuchen, dass die Verwendung eines einzelnen Backslashs für die Aufteilung reale Konflikte verursachen würde?

Nun, das Problem, dass \anycharacter gültiges CSS ist und seine eigene Bedeutung hat. Sicher, in echten Projekten findet man solchen Code kaum (außer vielleicht den \9 -ähnlichen Hacks), aber... wollen wir diesen Löwen füttern? Ein "uh-oh, mein 100% gültiges CSS kompiliert nicht" zu beheben, indem man ein weiteres "uh-oh" desselben einführt, klingt ein bisschen seltsam :)

Was calc betrifft, waren wir wohl von Anfang an einen Konsens - es wartet also im Grunde nur darauf, dass ein Freiwilliger es implementiert (ich schätze, dass die schnelle Lösung in nur 5-6 Zeilen neuen Codes erledigt werden kann - also es ist wirklich nur ein mutiger Mann, dies zu tun - kleinere Implementierungsdetails können variieren, aber ich denke, sie können im Laufe des Prozesses entschieden werden).

Nun, das Problem, dass \anycharacter gültiges CSS ist und seine eigene Bedeutung hat. Sicher, in echten Projekten findet man solchen Code kaum (außer vielleicht die zB \9-ähnlichen Hacks), aber... wollen wir diesen Löwen füttern? Ein "uh-oh, mein 100% gültiges CSS kompiliert nicht" zu beheben, indem man ein weiteres "uh-oh" desselben einführt, klingt ein bisschen seltsam :)

Ich höre Sie, es ist ein möglicher Kompromiss. Und ja, ich weiß, dass \anycharacter gültiges CSS ist. Ich denke, ich frage mich, ob es ein besserer Kompromiss ist. Es ist nur so, dass es sich syntaktisch komisch anfühlt, als ich 12px./10px schrieb. Ich habe das Gefühl, dass Less syntaktisch versucht hat, CSS so weit wie möglich wiederzuverwenden, ohne Konflikte zu erzeugen.

./ bietet Syntaxklarheit und vermeidet Konflikte vollständig, aber das Erzwingen von Klammern überall in der Mathematik, weshalb ich es unterstützt habe, aber es gab Gegenreaktionen, und darüber mache ich mir hier Sorgen. Gibt es also einen legitimen Fall, in dem wir 10px\10 mit der Absicht des Entwicklers verwechseln würden, \10 zu entkommen? Ich weiß, das ist eine harte Theorie, und Ihr Punkt wäre wahrscheinlich, dass wir es nicht wirklich wissen ..... Es ist eine komplizierte Frage, und das Hinzufügen neuer Syntax ist immer schwierig, insbesondere bei Less, da wir nicht alle CSS-Dateien kennen das wilde noch zukünftige CSS.

Was Calc angeht, hatten wir wohl von Anfang an einen Konsens - es wartet also im Grunde nur darauf, dass ein Freiwilliger es implementiert (ich schätze, dass die schnelle Lösung in nur 5-6 Zeilen neuen Codes erledigt werden muss - es geht also wirklich nur um ein mutiger Mann, dies zu tun - kleinere Implementierungsdetails können variieren, aber ich denke, sie können noch im Prozess entschieden werden).

Gut! Sollten wir es separat verfolgen, um die Sichtbarkeit zu erhöhen?

@sieben-phasen-max:

Sicher, in echten Projekten findet man solchen Code kaum (außer vielleicht den \9 -ähnlichen Hacks)

Richtig . Oh diese holprigen "Westerner"... :)

@sieben-phasen-max
Beantworten Sie die einfache Frage: "Wie kann 0 + 1/2 möglicherweise besser sein als (1/2)?"

Ich verstehe nicht, wohin du damit gehst. (1/2) sollte von LESS ausgeführt werden, da es unmöglich gültiges CSS sein kann, also muss es als LESS gemeint sein. 0 + 1/2 sollte zu 1/2 wobei LESS den 0 + 1 Teil ausführt, da dies der Teil ist, der kein gültiges CSS sein kann. Der Teil 1/2 könnte gültig sein, also berühren Sie ihn besser nicht.

@thany
OK, jetzt stellen Sie fest, dass (1/2) sowohl in Less als auch in Sass so funktioniert, wie Sie es erwarten.
Und 0 + 1/2 (sowie 1 * 1/2 usw.) ist der Teil der Lösung, den Sie oben als brillant bezeichnen, und das Ergebnis "die brillante Lösung" ist 0.5 .
Immer noch keine Ahnung, was hier passiert?
Lesen Sie alles (ausgehend von Ihrem ersten Post) oben noch einmal und versuchen Sie, sich selbst zu antworten: "Was genau beschwere ich mich?".

@sieben-phasen-max
Und 0 + 1/2 (sowie 1 * 1/2 usw.) ist der Teil der Lösung, den Sie oben als brillant bezeichnen, und das Ergebnis "die brillante Lösung" ist 0,5.

Nein, die Lösung wäre 1/2 nicht 0.5 , da 1/2 gültiges CSS sein könnte. Sie möchten nicht, dass LESS weiß, wann ein Schrägstrich gültig ist, also nehmen Sie an, dass dies immer der Fall sein könnte. Daher ist 1/2 das einzig logische Ergebnis. Auf die gleiche Weise würde 2 * 1/2 zu 2/2 , da * es ansonsten zu ungültigem CSS machen würde.

Immer noch keine Ahnung, was hier passiert?

Mir ist vollkommen klar, was hier passiert. LESS führt mathematische Divisionen eifrig aus und ignoriert Einheiten blind.

Lesen Sie alles (ausgehend von Ihrem ersten Post) oben noch einmal und versuchen Sie, sich selbst zu antworten: "Was genau beschwere ich mich?".

Persönliche Angriffe sind nicht nötig.

LESS führt mathematische Divisionen eifrig aus und ignoriert Einheiten blind.

Das ist es also, worüber Sie sich beschweren, oder?

Persönliche Angriffe sind nicht nötig.

Was soll ich also stattdessen tun? Wiederholen Sie die ursprünglichen beiden Posts immer wieder (und wieder)? Bis dir klar wird:
@community :

Verwenden Sie die Option -sm

@thany :

dann sollte es standardmäßig eingeschaltet sein.

@sieben-phasen-max:

Es kann nicht sein, weil dies sofort zig Millionen Projekte da draußen zerstören würde. Wenn Sie also das Standardverhalten als Problem behandeln, setzen Sie einfach die dokumentierte Option und fertig.

Sie wiederholen also "es sollte", "es sollte", "es sollte" und erwarten was? Denke für uns, es ist einfacher, einfach "Nein, sollte es nicht" zu beantworten, anstatt unsere Zeit damit zu verschwenden, detailliert zu erklären, warum das, was du vorschlägst, nicht funktioniert oder im Allgemeinen keinen Sinn macht (die Erklärungen, die du entweder nicht willst verstehen oder einfach nicht können).

Also, worum geht es in diesem Thread? Es geht darum, "zu erkennen, dass, während eine eventuelle grundlegende Änderung, ein " -sm -ähnliches Verhalten als Standard zu machen, unvermeidlich ist, wir Einrichtungen für komfortablere Arithmetik als die schrecklichen bereitstellen müssen: margin: (1/2) (3/4) (5/6) (7/8); für diejenigen, die benutze den Arithmus viel".
Ihre Posts hier schlagen entweder etwas vor, das nicht besser ist als (oder genau dasselbe wie) bereits vorhandenes -sm Verhalten oder argumentieren mit etwas, das von Anfang an nicht in Frage kommt (wie dort ). Mit anderen Worten, nur ein zufälliges Rauschen .

@seven-phases-max @thany Lassen Sie uns die Temperatur etwas senken. Es gibt überall starke Meinungen.

Ich denke, die meisten Leute sind auf der gleichen Seite, wenn es um beides geht, das idealerweise nicht von Less als mathematischer Ausdruck interpretiert wird:

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

In diesen Punkten herrscht also weitgehend Einigkeit, und die meisten Argumente drehen sich um mögliche Lösungen. Das calc() Problem scheint genügend Konsens zu haben, um voranzukommen. Grundsätzlich: Berühren Sie calc nicht und behandeln Sie Variablen in calc() wie eine String-Interpolation. So ungefähr macht Sass das, obwohl es die Interpolationssyntax in calc() erfordert, die wir meiner Meinung nach nicht brauchen.

Die Lösungen für den font Teil werden viel haariger und die führenden Lösungen waren:

1. Erfordert standardmäßig für alles Parents (erster Versuch - fast implementiert, aber von der Community abgelehnt)
2. Schalten Sie den Schalter strictMath um (der hinzugefügt wurde, anstatt ihn zum Standard zu machen, und den Vorschlag von @seven-phases-max) und führen Sie dann explizit alle Ihre Berechnungen durch. Es ist technisch gesehen eine mögliche Lösung für die meisten Leute derzeit, aber ... die Frage taucht so häufig auf und wir wissen psychologisch, dass jemand, der neu in einem System ist, wahrscheinlich alle Standardeinstellungen beibehält, also ist es problematisch. Und nicht jeder Entwickler kann seine Build-Einstellungen ändern, insbesondere in Teams.
3. Ändern Sie im Wesentlichen den Divisionsoperator in Less. Der führende Anwärter in dem Thread war ./ , was funktioniert, aber etwas seltsam anzuschauen ist. \ ist an dieser Stelle ohne Forschung unbekannt. Könnte funktionieren, könnte unbekannte Konflikte mit der Flucht verursachen. Es ist eine sauberere Syntax mit einem (möglicherweise, aber unbekannten) höheren Risiko. Wenn sich jemand die Zeit nehmen würde zu demonstrieren, dass dies KEINE Konflikte verursacht, dh Beispiele für Flucht und Mathematik so vermischt, dass der Parser die beiden klar unterscheiden kann, dann ist dies immer noch eine Möglichkeit. Es braucht also nur die Arbeit. @thany , wenn du oder jemand anderes ein Fan davon ist, dann ist dies die erforderliche Arbeit. Das Letzte, was wir wollen, ist, die Pausen einfach woanders hin zu verlegen.

Ich denke, um diesen Thread zu vereinfachen, sollten wir uns von hier aus NUR auf #3 . Ich habe das Sass-Beispiel hauptsächlich aus Neugier gepostet, aber ich glaube nicht, dass diese Lösungen gut sind oder das Problem vollständig lösen, und sie sind konzeptionell nicht mit Less kompatibel. Über die Gültigkeit der Forderung von 0 + 1/2 streiten, wird uns nicht weiterbringen.

Mit einer guten Lösung auf dem Tisch für calc() , die uns für die meisten geposteten Ausgaben 50% des Weges dorthin bringt, würde ich empfehlen, sich nur kurzfristig auf diese Frage zu konzentrieren:

Wenn der Divisionsoperator Less geändert werden sollte, in was sollte er geändert werden?

• ./ - ist das so unangenehm, wie ich es empfinde, oder finden die Leute es in Ordnung?
• \ - ohne Recherche und Beweise und Pseudo-Code für einen Parser wird dies nicht vorankommen. Ich persönlich würde es vorziehen, wenn es nachweislich sicher ist.
• Anderer Ersatz?

Ehrlich gesagt, wenn wir calc() ändern und / ändern, denke ich, dass wir 99% des Lärms um Mathematik in Less dämpfen würden.

Hallo zusammen, ich habe calc() repariert -

Ich war ein bisschen erstaunt, als ich eine Lösung fand, die ohne viel Add-On-Code funktionierte. Im Grunde haben wir bereits Code in denen hatten strictMath Schalter und Kontrollen in Ausdrücken nicht Mathe bewerten , wenn es außerhalb Pars ist, so dass ich nur einen zusätzlichen Schalter auf dem Anruf hinzugefügt math auszuschalten , während der Auswertung calc() Argumente und dann weiter. Wir hatten bereits alle Teile, um die Mathematik in Ruhe zu lassen, aber immer noch Vars zu ersetzen. Hm.

Siehe https://github.com/less/less.js/pull/3162/files#diff -a94aaffd78b1d3c5eda7a42d5be1ca0d und https://github.com/less/less.js/pull/3162/files#diff -4e696271823c96903a91fff84983bab6

Sind die Tests ausreichend?

@matthew-dean :kaffee:

Sind die Tests ausreichend?

pro Kommentar in der PR bitte einen Test hinzufügen wie:

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

Und eine kleine Anmerkung: Dieser Fix führt offensichtlich das gleiche Problem wie in #1627 ein, dh

<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
}

Aber für calc es in Ordnung, denke ich (schließlich gibt es einfach keine anderen einfachen Möglichkeiten, es ohne größere Überarbeitung des Lazy-Eval-Konzepts zu beheben). Ich denke also, es ist nur eine Frage, einen Hinweis in die Dokumentation zu setzen, um Lazy-Eval im Auge zu behalten, wenn Vars innerhalb von calc .

Und eine kleine Anmerkung: Dieser Fix führt offensichtlich das gleiche Problem wie in #1627 ein

Guter Fang!

Das Wechseln der Kontext-Eigenschaft mathOn pro Aufruf löst dies, ähnlich wie in Ihrem Kommentar in der PR. Ich habe einen Test für float(1 + .1) hinzugefügt, der erfolgreich ist!

Das Umschalten der Kontexteigenschaft mathOn pro Aufruf löst dies, ähnlich wie in Ihrem Kommentar in der PR. Ich habe einen Test für float(1 + .1) hinzugefügt, der erfolgreich ist!

:) Nein, der Fehler "floor" muss vorhanden sein, wenn -sm: off . Siehe meinen neueren Kommentar in der PR.
Die Wiederherstellung kümmert sich nur um 1 + 2 calc(3 + 4) 5 + 6 -ähnliche Dinge.

:) Nein, der Fehler "floor" muss vorhanden sein, wenn -sm: off.

Wieso den? Alle Funktionen innerhalb eines calc() sollten Less-Funktionen sein. Selbst wenn dies nicht der Fall ist, gibt es in calc() keine CSS-nativen Funktionen, von denen ich weiß, dass sie rohe mathematische Ausdrücke annehmen können. Das erwartete Ergebnis wäre, vars- und Less-Funktionen auszuwerten, aber die Rohfunktionen in calc() allein zu lassen.

Randnotiz: Ich habe ein Verzweigungsexperiment durchgeführt, bei dem ich als Divisionsoperator in Less / auf \ umgestellt habe. Es gibt bereits viele Tests zum Entkommen (und ich habe noch mehr hinzugefügt, um die Adresse #3160 zu erreichen), und sie funktionieren alle immer noch gut, und die Mathematik funktioniert gut, wenn die Operatoren umgeschaltet sind. Ich habe keinen inhärenten Konflikt gesehen. Branch ist hier auf meiner Gabel: https://github.com/matthew-dean/less.js/commit/509d34fff7e234846afa150b099cd259755a39d0

Re: verschachtelte Funktionen

Dafür:

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

Als Entwickler sollte das erwartete Ergebnis sein:

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

Genau das passiert jetzt (mit diesen Änderungen). Es sollte keinen Fehler auslösen.

@matthew-dean
Nein, so wie du es geschrieben hast:

foo: unit(1/2, px);

mit -sm:on wird kompiliert zu:

foo: .5px;

^- falsch.
Gleiches gilt für verschachtelte Funktionen. Darüber hinaus ist die Tatsache, dass die meisten Funktionen normalerweise keine arithmetischen Ausdrücke als Argument verwenden können, kein Grund, -sm: on zu verletzen;
Also unter -sm: on beide Zeilen:

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

muss einen Fehler auslösen (und das wird beim Commit kaputt gemacht).

Worüber redest du?

unit(1/2, px) mit -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%) mit -sm:on

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

Schauen Sie in der Filiale vorbei. Versuch es.

Eine Sache, die bei der Überprüfung von Code möglicherweise hilfreicher ist, ist, dass Sie dies bitte überprüfen, wenn Sie nicht sicher sind, ob etwas eine falsche Ausgabe erzeugt. Oder bitten Sie mich, eine bestimmte Eingabe auszuprobieren, um zu überprüfen, ob sie wie erwartet funktioniert. Oder stellen Sie Fragen, wenn Sie sich nicht sicher sind, wie / warum es funktioniert. Es falsch zu nennen, ohne zu wissen, ob es so ist, ist nicht hilfreich.

Meine Entschuldigungen. Ich schätze, ich habe die indirekte Kontrolle dieses Teils übersehen.

Schauen Sie in der Filiale vorbei. Versuch es

Ich kann nicht, tut mir leid.

Meine Entschuldigungen. Ich glaube, ich habe die indirekte Kontrolle dieses Teils verpasst.

Keine Bange. Sieht es so aus, als ob es so funktioniert, wie Sie es erwarten würden?

Sieht es so aus, als ob es so funktioniert, wie Sie es erwarten würden?

Ja, da kann ich mir bisher keine weiteren Verdächtigen vorstellen.

@matthew-dean
Ändern Sie im Wesentlichen den Divisionsoperator in Less. Führender Anwärter im Thread war ./, was funktioniert, aber etwas seltsam anzuschauen ist. \ ist an dieser Stelle ohne Recherche ein Unbekannter [...] @thany , wenn du oder jemand anderes ein Fan davon ist, dann ist dies die erforderliche Arbeit. Das Letzte, was wir wollen, ist, die Pausen einfach woanders hin zu verlegen.

Eigentlich gar nicht. Ich schlug den Operator \ als letzten Ausweg vor, nachdem ich nicht durchgekommen war, und versuchte, WENIGER dazu zu bringen, nur seine eigenen Berechnungen durchzuführen. Wenn ein neuer Divisionsoperator erforderlich ist... Nun, calc() kann auch Addition, Subtraktion und Multiplikation ausführen. Neue Betreiber dafür? Ich denke, es ist unpraktisch. Ein neuer Divisionsoperator kann eine Lösung für Dinge wie Schriftart, Hintergrund und Rahmenradius sein, aber keine Lösung für CSS-Mathematik.

Ich denke immer noch, dass die wahre Lösung darin besteht, dass WENIGER über den Kontext Bescheid weiß. Es sollte (ja, hier komme ich noch einmal mit meinem "sollte", welches andere Wort muss ich verwenden?...) wissen, dass calc() eine CSS-Funktion ist und nur Mathematik auswerten sollte, die CSS nicht kann . Aber floor() existiert nicht in CSS, so dass man es (vollständig) auswerten müsste, um kein ungültiges CSS auszuspucken. Ich denke, dies wurde jedoch bereits in anderen Worten erwähnt.

Ich denke immer noch, dass die wahre Lösung darin besteht, dass WENIGER über den Kontext Bescheid weiß. Es sollte (ja, hier gehe ich noch einmal mit meinem "sollte", welches andere Wort muss ich verwenden?...) wissen, dass calc() eine CSS-Funktion ist und nur Mathematik auswerten sollte, die CSS nicht kann. Aber floor() existiert nicht in CSS, so dass man es (vollständig) auswerten müsste, um kein ungültiges CSS auszuspucken. Ich denke, dies wurde jedoch bereits in anderen Worten erwähnt.

Fair genug zu: \ , aber was den Kontext angeht, kann ich basierend auf Ihren anderen Beiträgen garantieren, dass es ein weitaus komplexeres Problem ist, als Sie denken. Du musst es wirklich reduzieren auf:

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

Wenn Sie / definitiv als Divisionsoperator belassen wollen, um calc() nachzuahmen und es nicht mehrdeutig zu machen, dann müssen Sie unbedingt sicherstellen, dass / ist Klammern (außer der Ausnahme calc() ). Das würde einen vorhersehbaren Kontext liefern.

Dieser Vorschlag am Anfang dieses Threads ist auch immer noch möglich und wurde stark unterstützt. Im Wesentlichen ist die Standardeinstellung, dass alle Mathematik außerhalb von Klammern außer der Division unterstützt wird (und wieder, außer calc() , ist dies jetzt ab 3.0+ der Fall). Vielleicht ist das der richtige Weg. Das würde erlauben:

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

Die Sache ist die, dass das Ergebnis für 10px+15px/1.5 für Entwickler immer noch schwer zu verstehen sein könnte, mit einem Ausdruck, der "halbausgewertet" zu werden scheint, es sei denn, er steht in Klammern. Wenn wir die strikte Mathematik standardmäßig aktiviert hätten, wäre es wahrscheinlich in Ordnung gewesen. Es ist noch weniger zweideutig. [Schulterzucken] Wie auch immer, Mathematik in einen Kontext zu packen, IST der Weg, Mehrdeutigkeiten zu beseitigen, und die einzige Möglichkeit für die Division, außer den Divisionsoperator zu ändern.

Die Richtung muss im Wesentlichen die Community bestimmen. Es gibt praktikable Optionen in diesem Thread. Jedes hat Nachteile. Jeder hat Schmerzpunkte. Keiner wird vollen Konsens haben. Aber IMO sind alle besser als das aktuelle Szenario. Ich muss nur die Pille schlucken.

Letzter Aufruf zur Entscheidung

In dem Bemühen, das Unmögliche zu schaffen, würde ich gerne vorschlagen, dies zu tun (unter Bezugnahme auf Kommentare von vor 3 Jahren).

Gib --strict-math 3 Einstellungen

1. aus
2. Teilung
3. strikt (Alias on für Back-Compat)

Um die Debatte beizulegen, erlauben Sie dem Schalter --strict-math=division , Folgendes zu tun:

1. Führen Sie keine Division mit nur / Zeichen außerhalb von Klammern durch. ZB border-radius: 55px / 25px; --> no-math (ja, das ist gültiges CSS)
2. Erlauben Sie die Division mit zwei verschiedenen Methoden:
   A. . Präfix - border-radius: 55px ./ 25px;
   B. Klammern - border-radius: (55px / 25px);
3. Beide Formen sind in Klammern gültig - zB border-radius: (55px ./ 25px); wäre gültig

Wenn Sie als Entwickler also der Meinung sind, dass eine Version nicht Ihre Präferenz ist, können Sie die andere verwenden. Einige mögen es vorziehen, keine Klammern zu verwenden; einige mögen es vorziehen, keinen modifizierten Divisionsoperator zu verwenden. Etwas für jeden. Und keine unangenehmen Überraschungen mehr für diejenigen, die mit Less neu sind und die mittlerweile weit verbreitete Syntax in CSS verwenden, wobei / in font , background , border-radius , @media Abfragen, CSS-Grid-Eigenschaften und in Zukunft wahrscheinlich noch mehr.

Nächste Schritte

Ich empfehle, dass dies als Option in eine PR geht und dann, wie besprochen, als Standard für eine zukünftige Hauptversion geändert wird

@matthew-dean

Dh der Punkt verhält sich wie die Umkehrung einer Escape-Sequenz?
Eigentlich keine schlechte Idee...

Und alles in allem _wahrscheinlich_ eine der saubersten Lösungen.

@rjgotten Habe hier einen Anfang: https://github.com/matthew-dean/less.js/tree/strict-math-division

Ich erhalte immer noch einen seltsamen Fehler bei einem der Tests, bei dem es scheint, dass einer der Dimensionsknoten in einen Operationsknoten umgewandelt wird (und dann einen Fehler auslöst, weil er keine Operation auf einem Operationsknoten ausführen kann. Es scheint kein Parsing-Problem zu sein, da ein anderer Test, der nicht unter strictMath: division funktioniert. Möchten Sie ihn überprüfen und sehen, ob Sie helfen können?

Ich möchte diese Ausgabe schließen und neue Ausgaben erstellen, die die verbleibenden mathematischen Fragen behandeln. Speziell:

1. Umgang mit Divisionen und die strictMath: 'division' Funktion.
2. Umgang mit Mathematik gemischter Einheiten. Siehe: https://github.com/less/less.js/issues/3047