Less.js: Es kann kein elliptischer Randradius erstellt werden

Ich wollte ein ähnliches / verwandtes Problem hinzufügen, das mit der font-Eigenschaft beim Deklarieren einer Zeilenhöhe auftritt

.class {
    font: 13px/1.231 arial, helvetica, clean, sans-serif;
} 

es sollte unverändert bleiben, aber es wird:
.class {
Schriftart: 10.560519902518276px arial, helvetica, sauber, serifenlos;
}}

dotless hat auch dieses Problem (https://github.com/dotless/dotless/issues/16). Es wäre schön, eine Einigung darüber zu erzielen, wie in beiden Fällen vorgegangen werden soll.

Die einfachste Lösung, die heutzutage sofort funktioniert, besteht darin, sie in ein Zeichenfolgenliteral zu verpacken.

 font: ~"13px/1.231 arial, helvetica, clean, sans-serif";

oder auch

 font: ~"13px/1.231" arial, helvetica, clean, sans-serif;

Ich habe verstanden, dass eines der Ziele von weniger darin bestand, mit der normalen CSS-Syntax kompatibel zu sein. Die Umgehung verstößt gegen diese Regel.

Ich verstehe deine Frustration. Ich kann keine einfache Lösung zwischen der Arithmetik von Less und bestimmten CSS-Eigenschaften finden. Was ist zum Beispiel, wenn Sie tatsächlich angeben möchten, dass die Schriftart halb so groß ist, d. H.

 <strong i="6">@example</strong>: 24pt;
 .foo {
     font: normal @example/2 sans-serif;
 }

Etwas muss Kompromisse eingehen. Zugegeben, Sie können Less so ändern, dass alle Conversions verpackt werden.

 font: normal (@example/2) sans-serif;

Dies würde jedoch dazu führen, dass vorhandene Less-Stylesheets für alle Fälle ausführlicher und ausführlicher werden, nur um Fälle zu vermeiden, die für Kurzschriftdeklarationen für Schriftarten und Rahmenradien nicht so häufig sind. Eine weitere Option, wenn Sie sich Sorgen über vorhandenes CSS machen, können Sie jedes vorhandene CSS in Ihre Less-Datei importieren:

 <strong i="13">@import</strong> "legacy.css";

In diesem Fall ist der Import erfolgreich, das CSS wird jedoch nicht geändert oder konvertiert.

Wiederum verstehe ich Ihre Besorgnis voll und ganz, dass Less keine strikte Obermenge von CSS ist, aber mir fehlen offensichtlich bessere Ideen. Haben Sie mögliche Lösungen für dieses Syntaxproblem?

: +1: zu diesem Problem von mir, aber ich bin mir auch nicht sicher, wie ich es auf elegante Weise lösen kann, ohne dass gültiges CSS ausgeblendet werden muss oder Klammern erforderlich sind, um Berechnungen auszulösen.

@agatronic @cloudhead Ich arbeite an einer Lösung für dieses Meinung dazu einholen , wie dies Ihrer Meinung nach gehandhabt werden sollte, bevor ich weiter gehe. SASS und Stylus behandeln dies beide, indem sie nur die Unterteilung in Klammern zulassen. Alle anderen mathematischen Operationen können außerhalb von Parens ausgeführt werden. Diese Methode verhindert, dass zukünftige Implementierungen des Schrägstrichs durch W3C ebenfalls unterbrochen werden, und macht die Parser Ratio und Shorthand überflüssig. So war ich zuerst geneigt, das Problem zu beheben. Ist das eine vernünftige Lösung für Sie beide?

Beachten Sie, dass dieser Fehler auch die CSS3-Hintergrundkürzel unterbricht, bei der der Schrägstrich verwendet wird, um die Hintergrundposition (bei der es sich um Schlüsselwörter oder Dimensionen handeln kann) von der Hintergrundgröße zu trennen. Beispielsweise:

.foo {
    background: url(image.png) center / 1px 100px;
}

Pingen Sie auch @matthewdl @Synchro

Ein früherer Vorschlag war, dass '/' teilt und '/' ein Verhältnis ist. Es wäre gut, Eingaben von @cloudhead zu erhalten, denn obwohl es wirklich schön wäre, sortiert zu werden, ist es ziemlich beängstigend, wenn es das bestehende Verhalten bricht ...

@cloudhead antwortete via Twitter etwas minimal: "Die Paren-Lösung scheint anständig zu sein"

Das Problem mit der Leerzeichenlösung ist, dass immer noch perfekt gültiges CSS kaputt geht. Leider besteht die einzige Möglichkeit, dies effektiv zu beheben, ohne das vorhandene Verhalten zu beeinträchtigen, darin, weiterhin zuzulassen, dass einfaches altes CSS nicht ordnungsgemäß analysiert wird.

Wie wäre es mit einer "vorübergehenden" Option, damit die Menschen beide für eine Nachfrist genießen können?

oder

Wir sollten eine Version kurz vor dem Zusammenführen dieses Fixes erstellen und eine Hauptversionsnummer auf 1.4 erhöhen (und hoffentlich Variablen in Includes und Interpolation von Eigenschaftsnamen usw. hinzufügen).

Ich denke, dies wäre definitiv eine Lösung, die Teil einer größeren Version sein müsste, da dies das bestehende Verhalten beeinträchtigen würde. Ich bin mir nicht sicher, ob eine temporäre Lösung (wenn es sich um Leerzeichen handelt) überhaupt vernünftig ist, wenn man bedenkt, dass sie immer noch vorhandenen Code beschädigen kann und keinen sauberen Übergang in die permanente Lösung bietet. Dies scheint eine Situation zu sein, in der das Drücken des Auslösers bei einem Release die beste Option ist und Personen über das Änderungsprotokoll und die Dokumente gewarnt werden können.

Ich meinte Flagge, um bestehendes Verhalten beizubehalten. Aber ich stimme Ihnen zu.

Haben Sie Commit-Rechte? Auch wenn dies als Pull-Anfrage am besten sein könnte, so wir
kann mit Releases koordinieren (wir haben keine Pläne, die ich kenne)

Persönlich denke ich, wir sollten die Pille schlucken und anfangen, nicht in Klammern gesetzte mathematische Operationen als veraltetes Merkmal aufzulisten. Es gibt zu viele Fälle, in denen es zu Konflikten mit gültigem CSS kommt. @agatronic - Es ist eine Skype-Diskussion mit @cloudhead (oder anderswo) wert, und ich hasse es, die WENIGER-Bibliotheken von irgendjemandem zu ruinieren, aber WENIGER sollte nicht CSS herausreißen und brechen, das der Autor nicht beabsichtigt hatte. Dem WENIGER Parser sollten klare Signale gegeben werden, dass eine mathematische Operation erforderlich ist, und Klammern sind ein guter Weg, dies zu tun. In Klammern: DO MATH. Nicht in Klammern: LASSEN SIE ES ALLEIN.

Als Phase 1, um den Schlag zu verringern, könnten wir NUR in Fällen aufhören, in denen die Division mehrdeutig ist, z. B. an Stellen, an denen ein Schrägstrich "/" ein gültiges Zeichen für diesen Wert ist. Wenn also im Fall des Randradius WENIGER nicht sicher ist, lässt es ihn in Ruhe. Wenn der Autor sicher ist, dass er eine Aufteilung zwischen den beiden Zahlen wünscht, kann er das Standardverhalten durch Hinzufügen von Klammern überschreiben.

Derzeit ist LESS jedoch als "valid CSS = valid LESS" dokumentiert, und bei diesem Fehler ist dies nicht der Fall. Es wird fälschlicherweise gültiges CSS neu geschrieben, was es zu einem klaren Fehler macht. Das Problem ist, dass es AUCH eine klar dokumentierte mathematische Operation ist. Die beiden stehen in Konflikt, und es scheint mir klar zu sein, dass der zweite Fall geändert werden sollte, wobei CSS erhalten bleibt.

Ich sehe, dass @ttfkam und @ mlms13 fast dasselbe sagten. Ich denke, ihr Instinkt ist richtig, und ich würde nachdrücklich dafür stimmen, dass WENIGER eine langsame Migration in Klammern beginnt, was eine Voraussetzung für Operationen ist.

@matthewdl +1

@agatronic : Ich habe keine Commit-Rechte, stimme jedoch zu, dass dies sowieso durch eine PR erfolgen sollte, um den Code zu überprüfen und eine mögliche Release-Koordination zu erreichen.

@matthewdl : Für meine PR habe ich begonnen, nur die Unterteilung in Klammern zuzulassen. Betrachten Sie es als Stop-Gap-Maßnahme, um zu verhindern, dass WENIGER gültiges CSS beschädigt. Es ist nicht auf bestimmte Regeln beschränkt. Wenn also ein Schrägstrich auftritt und nicht in Parens eingeschlossen ist, wird er als wörtlicher Dilimiter ausgegeben. Sobald dies erledigt ist, werde ich etwas genauer untersuchen, wie alle Operationen so eingeschränkt werden können, dass sie nur innerhalb von Parens ausgeführt werden.

Okay, ich habe dies mit @cloudhead über Skype besprochen. Er ist einverstanden, also hier ist der Plan:

1) In der nächsten Version wird die Dokumentation aktualisiert, dass Mathematik außerhalb von Klammern veraltet ist. In der Dokumentation wird gezeigt, dass mathematische Operationen in Klammern stehen. Nicht-Teilungsmathematik außerhalb von Klammern sollte jedoch weiterhin kompiliert werden (für diese Version).

2) Bei der nachfolgenden Version nach Schritt 1 erfordern ALLE mathematischen Operationen Klammern. Die Dokumentation ändert sich von "veraltet" zu "nicht unterstützt" (oder so ähnlich - wie wir kommunizieren, kann verfeinert werden).

Klingt gut? Dies bedeutet, dass wir mit der Planung der Meilensteine ​​für die nächsten beiden Versionen beginnen sollten, aber das liegt hier außerhalb des Rahmens dieses Threads.

Zur Verdeutlichung kann die Dokumentation JETZT aktualisiert werden, um zu sagen, dass Mathematik außerhalb von Klammern veraltet ist, da Mathematik IN Klammern einwandfrei funktioniert. Das ist also wirklich Schritt 0: Wir aktualisieren jetzt die Dokumente, um den Leuten mitzuteilen, dass a) Mathematik in Klammern stehen sollte und dass dies in Zukunft möglicherweise nicht mehr funktioniert. B) Demonstrieren Sie alle Mathematik in Klammern.

Funktioniert bei mir! : +1:

Vermutlich sollte @dmcass also eine Pull-Anfrage dagegen stellen
https://github.com/cloudhead/lesscss.org

und dann sollten wir @cloudhead belästigen , um uns zu verpflichten oder uns Verpflichtungsrechte für dieses Projekt zu geben?

Oh, richtig. Ja, ich werde versuchen, mich daran zu erinnern, ihn heute darüber zu nerven.

Am 21.08.2012 um 05:19 Uhr schrieb Luke Page [email protected] :

Vermutlich sollte @dmcass https://github.com/dmcass eine Pull-Anfrage stellen
gegen
https://github.com/cloudhead/lesscss.org

und dann sollten wir @cloudhead https://github.com/cloudhead zu belästigen
Commit oder geben Sie uns Commit-Rechte für dieses Projekt?

- -
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie sich an
Gi tHubhttps: //github.com/cloudhead/less.js/issues/146#issuecomment -7899194.

Ich habe eine PR geöffnet, um die Dokumente unter cloudhead / lesscss.org # 29 zu aktualisieren

Auf Master für 1.4.0 behoben

So wird es in 1.4.0 sein

Schauen Sie sich das Alpha auf less2css.org an

Dieser Fehler tritt in 1.4.1 immer noch auf, wenn Sie das folgende CSS verwenden:
Randradius : 0 0 100% 100% / 0 0 24px 24px;

Es gibt aus:
Randradius: 0 0 100% Unendlichkeit% 0 24px 24px;

(Ich habe es auf http://less2css.org versucht)

@rubious hast du im Optionsmenü die strikte Mathematik

OK, das funktioniert, aber ich verwende LiveReload und diese Option scheint dort nicht aktiviert zu sein.

Tut mir leid, das ist die einzige Möglichkeit, das Problem zu beheben. Aktivieren Sie entweder die strikte Mathematik, sodass alle Berechnungen nur in Klammern ODER durchgeführt werden

border-radius:0 0 100% 100% ~"/" 0 0 24px 24px;