Less.js: Bedingter CSS-Code

gehen Sie zu http://www.lesscss.org/ und suchen Sie nach guards.

Um zu vermeiden, Mixins verwenden zu müssen, sehen Sie sich die Feature-Anfrage an, um Guards auf jedem CSS zuzulassen.

Ja, das weiß ich, aber wenn wir viel LESS schreiben, müssen wir Hunderte von .mixins schreiben und verwalten
Ich glaube nicht, dass Mixin dieses Problem löst. Sogar Mixins bekommen mit dieser Funktion viel Power.
Weniger CSS haben fast alle Funktionen, die einige Programmiersprachen haben, warum dann nicht diese?

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

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

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

Ich würde ein großes +1 für diese Funktion hinzufügen, die ich wirklich vermisse. Wachen mit einer großen Codebasis zu unterhalten, ist wirklich ein Albtraum. Das würde die Sache wirklich viel einfacher machen...

Wir können sogar eine Switch-Anweisung hinzufügen.

@lukeapage können Sie dieses Problem bitte erneut öffnen. Ich denke, wir sollten dieses Problem/Feature diskutieren

LESS ist keine Skriptsprache. Die Syntax / der Stil ähnelt CSS.

LESS soll deklarativ sein, was bedeutet, dass es nicht in der Lage sein sollte, komplexe Situationen mit Verzweigungslogik, Schleifen usw.

@pierresforge haben Sie Beispiele, bei denen die Wachen unzureichend sind?

und wo es nicht gelöst werden würde, indem man Wachen an jedem Selektor haben könnte?

Die Diskussion ist offen. Wenn Sie mich (oder ein anderes Mitglied des Kernteams) davon überzeugen können, dass sie notwendig sind, werde ich das Thema erneut eröffnen. Aber das Gespräch wurde schon einmal geführt und es wurde viel Zeit darauf verwendet .

Der Satz von http://lesscss.org/
"LESS erweitert CSS um dynamisches Verhalten wie Variablen, Mixins, Operationen und Funktionen."

Ja, LESS ist keine Skriptsprache, hat aber dennoch Features wie Variablen, Funktionen und Operationen.
Was fehlt, ist bedingte Logik.

Ich denke, CSS Media Query ist nichts anderes als die bedingte Logik.

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

Wenn CSS bedingte Logik wie Wächter haben kann. also was ist der unterschied. Wachen erweitern es nur auf Mixins.
Guards erlaubt nur Bedingungen außerhalb des CSS-Codeblocks und nicht innerhalb des Codeblocks.
Bitte siehe https://github.com/cloudhead/less.js/issues/1293#issuecomment -16929701 für ein Beispiel, Wachen können bei einer solchen Anforderung nicht helfen.

Sogar HTML hat bedingte Logik, ja, und es ist eine Auszeichnungssprache, keine Skriptsprache.

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

@lukeapage danke..

Wachen sind analog zu dem, was Medienabfragen tun. Beachten Sie, dass Sie in gewöhnlichem CSS Medienabfragen nicht in Selektoren verschachteln können. Sie können sie nur im Stammverzeichnis des Dokuments ablegen.

Nein, ich habe kein Beispiel, wo Wachen nicht ausreichen. Es gibt jedoch viele Stellen, an denen Schutzvorrichtungen für die Wartbarkeit nicht wirklich am besten geeignet sind.

Ein Beispiel:

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

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

ist in meinem Sinne prägnanter und selbsterklärender (meistens in den Fällen, in denen es keinen Sinn macht, den Code wiederverwendbar zu machen, da der Algorithmus von vielen Faktoren abhängt) als:

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

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

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

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

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

Ich stimme zu, dass dies Gegenstand von Diskussionen ist, aber dies wäre eine ziemlich nette Ergänzung, wenn es nicht viele Kernänderungen beinhaltet. Es ermöglicht, die meisten Regeln für ein einzelnes Element zusammenzufassen, ohne dass Mixins hinzugefügt werden müssen.

Für diese Art von Situation habe ich die Kontrastfunktion geschrieben - sie fungiert als eine Art bedingte Operation, die sonst nicht verfügbar ist, und sie ist viel ordentlicher als die Verwendung von Wächtern, wie Sie sagen. Ich denke, wir könnten eine Art generische Funktion implementieren, die als eine Art Selektor fungiert, anstatt so weit zu gehen, Syntax für Bedingungen hinzuzufügen.

@Soviut Devil's Advocate - In LESS können Sie Ihre Medienabfrage tatsächlich in einem Selektor platzieren, was oft sehr nützlich ist.

Ich war gegen ifs, weil es die Komplexität Ihres Codes exponentiell erhöht, und LESS ist so konzipiert, dass es einfach und unkompliziert ist. In diesem Moment gibt es einen gewissen Druck, die Sprache zu stabilisieren, indem neue Funktionen hinzugefügt werden.

Allerdings ... noch einmal Advokat des Teufels, basierend auf der Logik, dass Medienabfragen jetzt in Selektoren erscheinen, könnten Wachen theoretisch dem gleichen Prinzip folgen.

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

  background-color: @coreBackgroundColor;

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

or

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

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

Deklarativer als ifs, Syntax näher am bestehenden LESS und wertet jede Anweisung unabhängig aus (wie LESS / CSS definiert ist).

Alternativ (oder zusätzlich) ähnlich, Anhängen der Bewertung eines Mixins an den Bewertungspunkt:

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

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

Wächter auf Statement-Ebene sind meiner Meinung nach nicht mehr/weniger komplex oder anders logisch als Wächter auf Mixin-Ebene. Wahrscheinlich sind die Beispiele 2 und 3 weniger expansiv für die Sprache. Ich dachte nur, ich würde das zum Nachdenken / zur Diskussion hineinwerfen.

Ich schätze, niemand hatte viel zu meinem Vorschlag als Deklarationswächter zu sagen. ;-)

Eigentlich nein, nicht viel zu sagen. Das wäre einfach eine tolle Sache, IMO :)

Ja, wenn sie bereits in Mixins enthalten sind und Medienabfragen in Elementen enthalten sein können, scheint die Logik für ihre Erweiterung vernünftig zu sein. Neugierig, was @lukeapage und @jonschlinkert und andere denken.

@Matthewdl :+1:

Ich glaube, ich habe sie bereits bei dem Thema unterstützt, über das sie diskutiert werden ... :)

@lukeapage Reden Sie von Ausgabe Nr. 748? Wenn ja, habe ich ein wenig zur Syntax hinzugefügt. ;-)

Ich möchte meinen Wunsch nach einer Form von if oder @when zum Ausdruck bringen.

Ich stimme nicht mit der Meinung überein, dass Wächter allgemein besser sind und weniger Code weniger komplex machen als die Verwendung von Bedingungen. Ich finde praktische Situationen, in denen Wächter meine LESS-Dateien tatsächlich hässlicher und schwerer lesbar machen, aber ein if / @when wäre tatsächlich außergewöhnlich lesbar. Guards und if / @when Bedingungen sind von Natur aus nur Werkzeuge, beide können verwendet werden, um Dinge schön oder hässlich zu machen, und sind besser für verschiedene Situationen geeignet. Verdammt, ich kann eine ~ 300b .less-Datei erstellen, die nur die grundlegendste Selektor-Erweiterungsfunktion von LESS verwendet, um über 1 GB RAM zu verbrauchen und die CPU minutenlang am Laufen zu halten.

In einem kürzlich durchgeführten Projekt, an dem ich mit der Absicht arbeitete, sowohl Desktop- als auch Mobilgeräte stark zu unterstützen, entschied ich schließlich, dass dies mit Inline-Medienabfragen nicht gut genug war. Das Bereitstellen von zusätzlichem CSS für beide Modi, die es nicht einmal verwenden würde, klang nicht gut, plus die ganzen Probleme mit dem Versuch, das doppelte Laden von Hintergrundbildern zu kaskadieren und das umgehen zu müssen, während immer noch kein Daten-URI ohne Zeitverschwendung eingebettet werden kann Bereitstellen eines ganzen Bildes, das ein Modus nicht verwenden würde. Und der Umgang damit durch den Versuch, zwei Stylesheets zu kaskadieren, würde mein Weniger nur zu einem größeren Durcheinander machen, da es jetzt zwei Orte geben würde, an denen die Stile für eine Klasse deklariert werden.

Meine Entscheidung war, eine Seite davon zu nehmen, wie MediaWiki mit RTL umgeht, indem ich zwei Stylesheets von einem bereitstelle. MediaWiki tut dies, indem es Stylesheets in LTR schreibt und dann das Stylesheet umdreht, um ein zweites RTL-Stylesheet zu erstellen. Es ist nicht erforderlich, alles zu überschreiben, was für LTR angegeben ist, um RTL zu handhaben. Ebenso habe ich beschlossen, meine primären Stile in eine main.less zu schreiben (und möglicherweise Dateien, auf die davon verwiesen wird, um die Stile zu trennen), diese Datei würde nicht direkt kompiliert. Stattdessen hätte ich zwei Stylesheets, ein desktop.less und ein mobile.less, beide würden Dinge wie <strong i="14">@mobile</strong>: true/false; , <strong i="16">@desktop</strong>: true/false; setzen und auch einige weniger Variablen wie die Größen von Dingen überschreiben. Auf diese Weise wird meine main.less sowohl in eine desktop.css als auch in eine mobile.css umgewandelt, und ich kann die Medienabfrage/den Test durchführen, um zu bestimmen, welche an anderer Stelle geladen werden soll (wenn ich WIRKLICH wollte, könnte ich sogar bestimmen, welche geladen werden soll). auf einem Gerät, das nicht einmal Medienabfragen unterstützt).

Das einzige Problem sind jedoch bedingte Blöcke. Es gibt Teile des Codes, von denen ich entscheide, dass „für Mobilgeräte diese Stile nicht erforderlich sind“ oder „für Desktops diese Stile nicht erforderlich sind“. Derzeit ist die einzige Möglichkeit, dies in weniger zu tun, mit:
((Ok, technisch gesehen sind diese Stile hypothetisch, da ich keine Akkordeon-Navigation verwende, aber sie halten sich an das, was ich tue))

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

In dieser Situation wäre es viel verständlicher, etwas wie @when zu verwenden.

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

Ich habe tatsächlich darüber nachgedacht, meine Less-Dateien vorzuverarbeiten, um so etwas wie eine @when -Syntax in einen Hack zu verwandeln, bei dem ein dynamisch generiertes Mixin+Guard erstellt und dann direkt danach eingefügt wird.
Es versteht sich von selbst, dass, wenn die Idee der Vorverarbeitung durch einen Vorprozessor nach einer guten Idee klingt, die das Verständnis erleichtert, etwas mit dem aktuellen Vorprozessor nicht stimmt.

Und die Wahrheit ist, dass dies nicht nur für meine Desktop-/Mobiltechnik gilt. Dies könnte auch für Themenprogramme gelten. Schreiben Sie eine Hauptdatei weniger mit Ihrem Thema. Dann haben Sie ein paar weniger Dateien, in die Sie einfach diese weniger Datei einfügen, und dann einige weniger Variablen festlegen, um Dinge wie das Farbschema zu steuern. Farbanpassungen werden gut funktionieren, aber Sie werden sofort von einer Klippe rennen, sobald Sie feststellen, dass Sie wirklich etwas wie @use_horizontal_nav gebrauchen könnten.

@dantman ab 1.5.0 und Guards on CSS-Styles, die verlinkt sind, können Sie dies tun

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

das ist Zucker für Ihr Beispiel.

Der einzige Nachteil ist, dass es im Moment denkt, dass es sich um einen neuen Selektor handelt, und ihn daher nicht mit dem vorherigen Selektor zusammenführt. Ich denke jedoch, dass dies wahrscheinlich keine Probleme verursachen wird und etwas sein wird, das ich/wir in zukünftigen Versionen beheben werde/werden.

Ok danke, können wir das als Feature dokumentieren lassen?

Um ehrlich zu sein, bin ich mir auch nicht sicher, ob es im Vergleich zu @when sehr verständlich ist. Ich bin mir nicht sicher, ob ich es verstanden hätte, wenn ich & when(...) zuvor in einer .less-Datei gesehen hätte auf einen Blick gemacht. @when als Zucker für & when() könnte nett sein.

Ich stimme @matthew-dean zu, dass das Hinzufügen dieser Art von bedingten Strukturen die Wartung und Prüfung der LESS-Kerndateien wahrscheinlich erschwert. Und die .less-Dateien sind schwerer zu debuggen und so weiter.

Was wir gerade haben, ist ein Kunstwerk, die Leute können die Grundlagen von LESS in buchstäblich weniger als 10 Minuten verstehen und lernen (ich spreche von Verschachtelung und Mischen), das Hinzufügen von bedingten Anweisungen macht die Dinge für andere Leute nur schwerer zu verstehen Designer und Enthusiasten. Der Versuch, Wächter zu verwenden, um IF-Anweisungen nachzuahmen oder zu simulieren, versucht nur, ein Problem zu verschlimmern, das nicht existiert und keiner Lösung bedarf.

Wenn ein Entwickler vor dem Kompilieren mehr Komplexität und Kontrolle über seine LESS-Dateien benötigt, hindert ihn nichts daran, Sprachen wie PHP zu verwenden, um weniger Dateien vorzuverarbeiten, um mehr Kontrolle, Flexibilität und Komplexität zu erreichen. Es gibt viele Möglichkeiten, dies zu tun Dies ist nur eine Frage der Vorstellungskraft, um dies auf die richtigste oder bequemste Weise zu tun.

Zum Beispiel, damit ich nicht sage, dass ich eine Datei namens "myfile.less.php" habe, die verrückten Code mit Bedingungen, Schaltern, Arrays und all dem ausgefallenen Zeug hat, das man in PHP sehen kann, und dann aus dieser ".less.php"-Datei eine andere Datei spucke "myfile.less" genannt, die den endgültigen LESS-Code haben, auf diese Weise kann ich alle Server-Variablen mit PHP abfragen, entscheiden, welche @importe meine neue .less-Datei einschließen oder ausschließen soll, keine Notwendigkeit mehr, eine große Menge dummer Vars zu übergeben den LESS-Compiler und keine Notwendigkeit, hässliche, schwer lesbare dumme Wächter zu schreiben, um IF- oder Switch-Strukturen zu simulieren.

Ein grundlegender Workflow könnte so aussehen

1- Überprüfen Sie, ob der Cache abgelaufen ist
1- Rufen Sie das Skript auf, um alle Dateien ".less.php" zu finden und vorzuverarbeiten
2- Skript aufrufen, um alle ".less"-Dateien zu kompilieren
3- Cache aktualisieren

@enav Ich stimme vehement nicht zu. Neben der Entwicklung weniger verwende ich es in Unternehmenslösungen, die auf Knotenpunkten basieren, wo wir nicht 2 Sprachen verwenden müssen, um ein Problem zu lösen.

@dantman , es gibt einige Dinge, die nicht dokumentiert sind, und ja, das müssen wir dokumentieren. bei less-docs wird versucht, die Dokumentation zu erweitern und die Website wesentlich besser zu machen. Ich werde dort ein Problem hinzufügen.

@lukeapage , ja das ist mir neulich aufgefallen. Ich habe das Änderungsprotokoll überflogen und Dinge wie svg-gradient und property merging with + bemerkt.

Genau genommen ist & when ... bereits dokumentiert, da es nur eine einfache Kombination aus zwei dokumentierten Features & und CSS Guards ist. Aber ein dediziertes Beispiel schadet natürlich nicht.

@seven-phases-max, diese Dokumentation war mir nicht bekannt. So wie es aussieht, handelt es sich um eine unvollständige neue Dokumentation, die die alte Site ersetzt, mit der Aufschrift „Dies wird bald in das Repo lesscss.org verschoben! Wir empfehlen, dass Sie diese Site nicht verlinken, bis alles live ist.“ Kommentar. Gut zu wissen, dass so etwas in Arbeit ist.

Ich bezog mich auf die aktuelle Dokumentation auf lesscss.org, die die einzigen Dokumente waren, die mir bekannt waren, und die derzeit nur Wächter als Mixin-Funktion dokumentiert, ohne darauf hinzuweisen, dass sie woanders verfügbar ist.

Wachen sind nicht so gut. :(

Dies ist eine erforderliche Funktion und auch in scass vorhanden.

+1 dafür

Da dieser Kommentar heute einige Jahre nach Eröffnung dieser Ausgabe auftauchte, möchte ich auf eine Sache hinweisen, die mir im Moment in den Sinn kommt.

Ein Teil des Widerstands gegen @when in der ursprünglichen Diskussion ist die zusätzliche at-Regel. Wenn ich jetzt darüber nachdenke, sollte es jedoch nicht benötigt werden.

Wenn man bedenkt, dass diese beiden Blöcke gleich sind:

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

Dann sollten diese beiden Anweisungen auch vom Parser als gleichwertig akzeptiert werden.

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

Allein schon deshalb, weil & when syntaktisch wirklich umständlich ist. Das Weglassen & , um immer noch einen Selektor-Join mit dem übergeordneten Selektor zu implizieren, hat die ganze Zeit existiert, daher scheint das Weglassen & , um einen Guard für den übergeordneten Selektor zu implizieren, kein Sprung zu sein. Außerdem werden Block-Root-Funktionen jetzt vom Parser für die Verwendung mit Plugins akzeptiert, sodass es nicht mehr so ​​seltsam aussieht wie 2013.

Ich sehe keinen Grund, dies erneut zu öffnen. Immerhin haben wir bereits #2072

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

Eine große Verwirrungsbox öffnen, nur um der Zwei-Zeichen-Sparsamkeit willen?

Wachen sind nicht so gut.

Ich dachte, es würde sich nicht einmal lohnen, einen zufälligen unvernünftigen Kommentar zu kommentieren. Jede Position sollte etwas dahinter haben (Sonst würde ich sagen, dass jeder bedingte Code lahm ist und if s dumm sind, nur weil ich weiß, wie man _alles_ ohne auch nur eine einzige Bedingung in fast jeder Sprache schreibt).

Ich sehe keinen Grund, dies erneut zu öffnen. Schließlich haben wir bereits when (1=1) { color: blue; }

Errr ... nein, tun wir nicht?

Aber es ist vernünftig, dass wir das tun sollten. Wir könnten es einfach zulassen und fertig.

Warten Sie, bis ich die Funktionsanfrage finde, auf die sie verlinken soll (sorry, ich habe versehentlich auf die Eingabetaste geklickt, bevor ich sie beendet habe)

Verschmelzen Sie dies also mit #2072.

@Sieben-Phasen-max

Dieses Problem heißt "Neudefinition von Variablen in bewachten selbstlaufenden Blöcken zulassen" und die tangentiale Diskussion am Ende dieses Problems enthielt analoge Anwendungsfälle zu einem select / case und einem vbscript iif([ifcond], [then], [else]) Funktion mehr als nur das nackte Wann, obwohl es vielleicht eine logischere Anregung für die Diskussion ist. Buuut ... wahrscheinlich sollte es nur als neues Thema mit der Frage when () vs. & when () aufgeworfen werden.

mit nur der when () vs & when () Frage.

Das kann doch nicht dein Ernst sein, oder? Wegen was genau? when wird nicht zu if (siehe #2072 für alle Gründe), wenn Sie & entfernen. Also so lassen wie es ist und fertig.

Hey, kannst du es etwas leiser machen? Wenn Sie sich darüber aufregen, nehmen Sie sich einen Moment Zeit und kommen Sie später wieder, um sich die Argumentation anzusehen, die ich in der neuen Ausgabe gepostet habe. Seit diesen ursprünglichen Diskussionen hat sich einiges entwickelt.

Ich wollte dich nicht beleidigen oder so.
Mein:

Also so lassen wie es ist und fertig.

war nur eine Antwort auf:

Wir könnten es einfach zulassen und fertig.

@seven-phases-max Okay, Ton geht im Text verloren. Jedenfalls war ich von dieser Idee nicht besonders angetan, und insgesamt ist der bestehende @when -Vorschlag sowieso besser / vielseitiger.

Ich denke, 'frech' ist besser als weniger. Es hat bereits if-else. Es ist wirklich schwer und viele Zeilen Codierung weniger. Wenn es funktioniert, aber den Bedarf nicht erfüllt. Außerdem können wir Schleifen in weniger machen, aber die Sprache sollte ihre eigene Funktion haben.

@aukgit Verwenden Sie das richtige Werkzeug für den Job. Wenn SCSS besser zu Ihnen passt, ist es besser, das zu verwenden. Sass und Less sind sehr unterschiedliche Projekte.

@matthew-dean, nachdem ich monatelang weniger gelernt und tonnenweise weniger geschrieben habe, wenn „weniger“ Community nicht besser sein will, dann ist das ein Verlust für uns beide. Ich denke, das ist der Grund, warum Bootstrap von weniger nach 'sass' (https://github.com/twbs/bootstrap/tree/v4-dev) verschoben wurde (ursprünglicher Grund war eine schnellere Kompilierung). Während die ursprüngliche Quelle in "weniger" war. Jetzt schreiben sie ihre ursprüngliche Quelle in 'sass' und konvertieren sie dann in less (während es umgekehrt war).

Etwas anderes :

"Das richtige Werkzeug für den richtigen Job"

sollte hier nicht gelten

Weniger | Scss | Stylus ähnliche Projekte. Begonnen mit einem damals beliebten , scheint es jetzt so, als ob die "weniger" Community sich nicht verbessern will.

Die Idee hinter dem „Weniger“ ist, weniger zu schreiben und mehr zu tun. Irgendwo reduziert es, aber irgendwo erfordert es mehr Schreiben.

Vielen Dank für Ihre Kommentare.

Fanboyhafte veraltete Propaganda. Es wäre Zeitverschwendung, all diese voreingenommenen oder einfach falschen Aussagen zu argumentieren.

Z.B:

Es gibt keine Möglichkeit, wirklich kompilierten Bedingungscode zu erstellen.

Ja, "Ich brauche ein Tool, um meinen Spaghetti-Code zu schreiben" - einfach so . Wenn Sie einen solchen Code schreiben, ist Less definitiv nicht Ihr Werkzeug.

Ich denke, "less" macht 'x' etwas ganz anderes als Sass und Stylus. Alle anderen machen ähnliche Dinge, während 'weniger' behauptet, es sei keine ähnliche Art. :)

@augit

Ich denke, "less" macht 'x' etwas ganz anderes als Sass und Stylus.

_Warum_ sollte es dasselbe tun? Siehe zum Beispiel [1] und [2] , um die wichtigsten Unterschiede zwischen den Designs zu finden. Vielleicht gefällt Ihnen das Konzept nicht, aber niemand zwingt Sie, ein Tool zu verwenden, das Sie nicht mögen.

Jetzt habe ich es verstanden. Danke schön. Es ist wirklich die am meisten missverstandene Sprache aller Zeiten. Sogar Javascript wird nicht so missverstanden, wie Douglas Crockford sagt.

Leute machen Fehler in js, aber es gibt viel Bewusstsein. Für „Weniger“ sollte es auf der ersten Seite (less.org) stehen und beschreiben, was weniger ist und was nicht.

Danke schön.

Habe einen Mix geschrieben:

Weniger:

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

    .x(@value);
}

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

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

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

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

CSS-Ausgabe:

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

wenn 'weniger' gemeinschaft nicht besser werden will, dann ist das verlust für uns beide

Ich denke, es ist ein Fehler anzunehmen, dass "X Feature, das ich will, wird nicht unterstützt" == "Weniger Community will nicht besser sein". Das bringt uns nicht weiter.

Es gibt mehrere Diskussionen auf Github, um an der Verbesserung der Kontrollflüsse zu arbeiten. Tatsächlich wurde dieser Thread nicht abgelehnt, er wurde zu #2072 zusammengeführt. Sie haben einen geschlossenen 3 Jahre alten Thread kommentiert. Ich hatte einige andere Ideen, von denen ich dachte, dass sie sich etwas von # 2072 unterschieden hätten, war aber im Wesentlichen vom Gegenteil überzeugt.

jetzt scheint es, als hätte es keine besseren Funktionen

Weniger hat nicht _mehr_ Funktionen, das stimmt. Dies ist beabsichtigt. Auf diese Weise können Sie Less an einem Tag lernen, und die Funktionen von Less decken 99 % der typischen Anwendungsfälle ab. Sass hat eine steilere Lernkurve. Sass hatte so viel Feature-Bloat, dass sie einen Low-Level-C-basierten Compiler bauen mussten, nur um ihn weiter kompilieren zu können. Was eine großartige Leistung ist. Aber kein gutes Zeugnis für etwas, das am Ende des Tages nur ein Stylesheet erstellt.

Jetzt schreiben sie ihre ursprüngliche Quelle in 'sass' und konvertieren sie dann in less (während es umgekehrt war).

Stimmt, aber das basiert auf mehreren Faktoren, und Sie können sie fragen, welche das wären. Ich persönlich halte es für einen Fehler, Less-Benutzer aufzugeben, da heute viele Leute Bootstrap in Less verwenden.

Am Ende des Tages sind Ihre Beschwerden über die Schleifen, die zum Schreiben von Bedingungen benötigt werden, _nicht falsch_. Die hier angebotenen Beispiele passen einfach nicht zur Sprache. Ich schlage vor, Sie lesen den Thread in #2072.

(Das ist eigentlich ein bisschen Offtopic, aber ich frage mich nur)

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

Und was wäre ein Nutzen dieser Variablen neben dem Aufruf .if-value-present-multi ?
(Und _wenn_ diese Variablen _für etwas anderes verwendet werden_) Wäre es nicht sinnvoll, stattdessen nur Eigenschaft/Wert-Paare zu verwenden, zB:

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

Außerdem, was könnte ein Zweck sein, .x {.if-value-present(content, 'new val')} zu schreiben, wenn Sie nur .x {content: 'new val'} brauchen? Und .x {.if-value-present(content)} schreiben, wenn es nichts bewirkt?

(Obwohl ich ehrlich gesagt [1] angeschaut habe - nun, ich habe nichts kommentiert, außer nur eine Sache: (_nur um Ihre Zeit zu sparen_) ziehen Sie in Betracht, alte Bibliotheken wie elements und lesshat wegzuwerfen - und Verwenden Sie stattdessen autoprefixer . Wir brauchen seit einiger Zeit keine Anbieter-Präfix-Bibliotheken für beide CSS-Präprozessoren).

So kommen normalerweise die meisten "Feature Requests" herein: "XY Problem" . (Andere gute Beispiele für ähnliche Fehler im verwandten Bereich: #1400 und #1894, es ist nicht so, dass die Funktionen völlig nutzlos wären (daher werden beide offen gehalten), aber wenn man anfängt, nach ihren tatsächlichen Anwendungsfällen zu fragen, zeigt sich das normalerweise es war einfach falsch Y beim Versuch, X zu lösen).

Nun, hier ist der Anwendungsfall:
Ich habe versucht, Mixn mit 3 Parametern zu erstellen, wenn der letzte nicht angegeben ist, sollte es sein Attribut innerhalb des Mixn erstellen, deshalb waren Bedingungen nützlich.

Hier https://github.com/aukgit/WeReviewProject/blob/master/WereViewApp/Content/Less/remixens/responsive/responsive-placements.less hatte ich versucht, immer wieder denselben Mixen zu implementieren, wo ich es hätte erreichen können mit Bedingungen sehr leicht.

Ich habe es jetzt .. Ich danke Ihnen allen.

@aukgit Sie sollten diese Mixins leicht zusammenklappen können.

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

Danke @matthew-dean, dass du dir die Zeit genommen und mir geholfen hast. :) Ich freue mich riesig auf dich.

:)

Ich denke, 'frech' ist besser als weniger. Es hat bereits if-else.

Beide Sprachen haben ihre eigenen Probleme.

Ihr Mangel an dynamischen Importen - und ihre Zurückhaltung bei der Implementierung - ist der Hauptgrund, warum ich von Sass zu Less wechseln möchte. Less hat diese Funktion seit Jahren!

Das Fehlen traditioneller Kontrollstrukturen (wie die FOR-Schleife oder IF-ELSE-Anweisungen) und die erschreckende Syntax hindern mich jedoch daran, diesen Schritt zu tun.

Ich fühle mich zwischen einem Felsen und einem harten Ort gefangen...

@jslegers Gleicher Kommentar wie in #249. Less hat seit v1.x verschiedene Formen (mehr und mehr in neueren Versionen) von bedingten Einschränkungen.

@Sieben-Phasen-max

Ich kenne geschützte Mixins als Alternative zu IF-Anweisungen und rekursive Mixings als Alternative zu Loops in Less. Aber das ist alles, was ich in der Dokumentation über Kontrollstrukturen in Less finden konnte. Und als jemand mit Programmiererfahrung in vielen Sprachen finde ich ihre Syntax verwirrend und - um ehrlich zu sein - ziemlich erschreckend.

Wenn es neben den erwähnenswerten Kontrollstrukturen noch andere Kontrollstrukturen gibt, habe ich diese in den Unterlagen nicht finden können.

Jedenfalls so etwas wie ...

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

... oder so ähnlich ...

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

... oder dieses...

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

... in Sass ist meiner Meinung nach viel besser lesbar und viel eleganter, als etwas Ähnliches mit geschützten Mixins oder rekursiven Mixins in Less schreiben zu müssen.

Das Fehlen solcher Anweisungen und die insgesamt weniger lesbare Syntax von Less (im Vergleich zu Sass) sind die beiden Hauptgründe, warum ich es vorziehe, bei Sass zu bleiben, und ich zögere, Less überhaupt für eines meiner Projekte in Betracht zu ziehen.

Und wenn man bedenkt, dass Sass weitaus beliebter geworden ist als Less, bin ich eindeutig nicht der Einzige, der so denkt.

@jslegers Für Ihre Beispiele - versuchen Sie zu erfahren, was bereits verfügbar ist, bevor Sie sie veröffentlichen.
Für den Rest (Beliebtheit und so) - es hat keinen Sinn, etwas so vereinfacht zu diskutieren (Stylus hat all das und na und?), außerdem wurde Less nie dazu erklärt, andere CSS-Präprozessoren zu ersetzen oder ihr Klon zu werden. Und schließlich ist der häufigste Fehler zu glauben, dass die Popularität von etwas das primäre und einzige Ziel der Autoren dieses Etwas ist.

versuchen Sie zu erfahren, was bereits verfügbar ist, bevor Sie sie veröffentlichen.

Versuchen Sie, besser zu dokumentieren oder die Leute direkt auf das zu verweisen, wonach sie suchen, wenn sie es nicht finden.

Für den Rest (Beliebtheit und so) - es hat keinen Sinn, etwas so vereinfacht zu diskutieren [...] Und schließlich ist der häufigste Fehler zu glauben, dass die Popularität von etwas das primäre und einzige Ziel von Autoren ist.

FYI, ich habe nie angedeutet, dass Popularität ein starker Indikator für Qualität oder Nützlichkeit ist. Tatsächlich ist es oft umgekehrt.

Wenn man sich jedoch ansieht, warum die Leute von Less zu Sass wechseln, ist es ziemlich einfach ...

Persönlich sehe ich dort nichts als das übliche "Ich will meine PHP-Spaghetti" (siehe Beiträge über falsches Tool oben), nicht einmal das Jahr 2012 mitgezählt (ich habe bereits angedeutet, dass die meisten dieser Beispiele in modernen Less ziemlich kompakt sind, aber es anscheinend willst du nicht aufwachen).
Aber egal, normalerweise behaupte ich nur eine klare Fehlinformation, Diskussionen über persönliche Meinungen, warum etwas passiert oder nicht passiert, sind völlig außerhalb meines Interesses.

Persönlich sehe ich dort nichts als das übliche "Ich will meine PHP-Spaghetti"

Es scheint mir, dass die Verwendung von Less anstelle von Sass Ihren Code unweigerlich wie "PHP-Spaghetti" aussehen lässt (wenn Sie denken, dass PHP der Inbegriff von Spaghetti-Code ist, haben Sie offensichtlich nie ABAP-Programmierung gemacht), sobald Sie etwas Komplexeres tun möchten als einfache Variablen und Mixins, aber ich bin bereit zu bedenken, dass ich hier falsch liege.

Ich habe bereits angedeutet, dass die meisten dieser Beispiele in modernem Less ziemlich kompakt sind, aber es scheint, dass Sie nicht aufwachen wollen

Warum sich dann nicht bemühen, mich aufzuwecken und mir ein oder zwei Quellen zu nennen, die mich von meiner Unwissenheit befreien könnten?

Es gibt wenig, was ich aufregender finde, als jemand, der mir das Gegenteil beweist. Meiner Erfahrung nach ist das der beste Weg, um zu wachsen ...