Less.js: :Mixins erweitern

Ich mag es, aber um es klar zu sagen.

.navbar,
.banner {
    // clearfix stuff
}

eher, als

.navbar {
    // clearfix stuff
}
.banner {
    // clearfix stuff
}

oder habe ich das falsch verstanden?

Ich hätte gerne beides, parametrische und normale Mixins, zu haben

.navbar,
.banner {
    // clearfix stuff
}
.....

oder

.clearfix,
.navbar,
.banner {
    // clearfix stuff
}
....

Wann immer Sie es brauchen, ich weiß, dass dies die gleiche Art und Weise ist, wie Mixins bereits funktionieren, daher hat die Frage hauptsächlich Flexibilität und Möglichkeiten zur besseren Handhabung der endgültigen CSS-Ausgabe in Bezug auf die Optimierung.

sicherlich

.clearfix,
.navbar,
.banner {
    // clearfix stuff
}

ist kürzer als

 .clearfix {
    // clearfix stuff
  }
 .navbar{
    // clearfix stuff
 }
.banner {
    // clearfix stuff
}

und für kompliziertere Beispiele, die kritisch sein könnten, und ich weiß, dass einige Leute nur wegen dieses Mangels zu SASS gewechselt sind

Reguläre Mixins konnten sich nicht ändern. Sie sind so ziemlich ein fester Bestandteil von Less. @agatronic , ja das sehe ich auch so. Es gibt jedoch Herausforderungen, wie könnten wir parametrische Mixins erweitern? Und wenn ja, wie würde das funktionieren? Angenommen, dies wurde unterstützt, nehmen wir an, Sie erweitern ein parametrisches Mixin zweimal, verwenden jedoch jedes Mal unterschiedliche Variablen, wie folgt:

.transition(@transition) {
  -webkit-transition: @transition;
     -moz-transition: @transition;
       -o-transition: @transition;
          transition: @transition;
}
.navbar {
    &:extend(.transition(opacity .2s linear));
}
.banner {
    &:extend(.transition(opacity .3s linear));
}

Ich kann mir vorstellen, dass es zwei Kopien des Mixins erstellen könnte, was nicht weniger Code ist und keinen Vorteil gegenüber normalen Mixins hat:

.navbar {
  -webkit-transition: opacity .2s linear;
     -moz-transition: opacity .2s linear;
       -o-transition: opacity .2s linear;
          transition: opacity .2s linear;
}
.banner {
  -webkit-transition: opacity .3s linear;
     -moz-transition: opacity .3s linear;
       -o-transition: opacity .3s linear;
          transition: opacity .3s linear;
}

Sie können dieses spezielle Mixin jedoch häufig verwenden. Wenn Sie das Mixin also erneut auf .dropdown mit denselben Variablen wie .banner , kann dies zu folgendem Ergebnis führen:

.navbar {
  -webkit-transition: opacity .2s linear;
     -moz-transition: opacity .2s linear;
       -o-transition: opacity .2s linear;
          transition: opacity .2s linear;
}
.banner,
.dropdown {
  -webkit-transition: opacity .3s linear;
     -moz-transition: opacity .3s linear;
       -o-transition: opacity .3s linear;
          transition: opacity .3s linear;
}

Und das macht es für mich interessant. Es wäre gut, auch Feedback von anderen zu hören

@jonschlinkert ja, das ist eine noch bessere Illustration, danke. wie gesagt beide Hände drauf! aber verstehen Sie, obwohl es eine weitere Ebene der Mittäterschaft hinzufügt und es mit Bedacht getan/nicht getan werden muss

Eine Erweiterung der Methode, auf die Sie verweisen, kann mit diesem Muster ziemlich einfach erreicht werden:

.transition(@transition) {
    -webkit-transition: @transition;
     -moz-transition: @transition;
       -o-transition: @transition;
          transition: @transition;
}

.quickOpacity1(){
    .transition(opacity .2s linear);
}

.quickOpacity2(){
    .transition(opacity .3s linear);
}

.navbar{
    .quickOpacity1();
}

.banner,
.dropdown{
    .quickOpacity2();
}

Das Obige injiziert halberweiterte Mixins in die 2 neuen Deklarationen.

Für das Clearfix ist es auch einfach, ein ähnliches Muster unten zu verwenden, das nicht nur das Clearfix als Klasse erstellt, sondern diese Clearfix-Stile in eine neue Deklaration einfügt.

.clearfix{
  //clearfix stuff
}
.navbar,
.banner {
    .clearfix;
}

@krismeister Ich denke, es könnte Verwirrung geben. Das von Ihnen beschriebene Muster ist wirklich nur verschachtelte Mixins oder ein Mixin-Vererbungsmuster. Verlängert die Arbeit umgekehrt.

@jonschlinkert Mixin-Erbe - ein toller Name. Es schien, dass in beiden obigen Beispielen versucht wurde, die Ausgabe vom übergeordneten Element zu erben - was ein Kernmerkmal der Erweiterung ist. Sie stimmen wahrscheinlich zu, dass die Ausgabe meines Beispiels Ihre erwartete Ausgabe war.

Ich verstehe jedoch, dass Sie Ihren ursprünglichen Kommentar erneut gelesen haben - Sie möchten, dass die Ausgabe in einer CSS-Regel zusammengeführt wird. Obwohl es ursprünglich als 2 geschrieben wurde.

Eigentlich ist :extend ziemlich großartig. Ich werde zum vollen Nerd, aber es kommt alles darauf an, "was wohin bewegt wird". Stellen Sie sich ein Mixin so vor, als ob Sie die Eigenschaften des Mixins auf den Selektor übertragen, der es verwendet hat. Und stellen Sie sich :extend als das Gegenteil vor, "beamen Sie den Selektor, der ihn verwendet hat, bis zum Mixin selbst". Nicht die Eigenschaften von _selector, nur der Selektor selbst. Also wenn du das gemacht hast:

.some-mixin() {
    padding-top: 100px;
    background: #f7f7f7;
}


// a selector that is extending the mixin
.alert:extend( .some-mixin() ) {
    border: 1px solid #e5e5e5;
}
// another selector extending the mixin
section:extend(.some-mixin()) {
    margin: 20px 0;
}

Es würde folgendes ergeben:

// The selectors that extended the mixin are now where the mixin used to be.
.alert,
section {
    padding-top: 100px;
    background: #f7f7f7;
}

// And the properties of the mixin did not get copied down below
// so we saved a line or two of code.
.alert {
    border: 1px solid #e5e5e5;
}
section {
    margin: 20px 0;
}

Hoffentlich macht das mehr Sinn. Ich helfe jederzeit gerne.

@agatronic , @matthewdl , @DesignByOnyx , nur ein Gedanke, ich weiß, dass dies ein ungewöhnlicher Ansatz ist, aber vorausgesetzt, es gibt keine technischen Herausforderungen und vorausgesetzt, wir erlauben eine durch Kommas getrennte Liste von Selektoren, könnte sich erweitern _sollte_ eher wie ein Array anfühlen . Was halten Sie davon, die Syntax zu ändern in: :extend[N] .

Ich denke, es ist auch für die Augen angenehmer, wenn Mixins erweitert werden:

section:extend[.some-mixin(), .another-mixin()] {
    margin: 20px 0;
}

Mir geht es so oder so gut, aber mit den eckigen Klammern fühlt sich etwas richtig an.

@jonschlinkert - [] bedeutet Attribut in CSS, nicht Array, während :extend() wegen seiner Verknüpfung zu Pseudo-Selektoren ausgewählt wurde, daher denke ich stark, dass normale Klammern bleiben sollten.

guter punkt, da stimme ich zu.

Ich stimme zu, dass die Klammern gut aussehen und sich gut lesen, aber ja, wir müssen bei der Syntax bleiben, die wir bereits gewählt haben.

Daumen hoch für die Syntax von extend(N), fühlt sich eher wie Natur-CSS an, der gleiche Grund wie bei @agatronic

Das Erweitern von Mixins ist keine schlechte Idee. Ich bin mir bei der Beispielsyntax nicht sicher, @jonschlinkert. Nicht, dass ich es nicht mag; Ich verstehe einfach nicht, was du geschrieben hast.

Ich denke, was Sie meinen, ist, dass Sie Klassen definieren möchten, die den gleichen Mixin-Inhalt "einziehen", aber nicht im resultierenden CSS wiederholen. Ich würde das nicht als Erweiterung von Mixins bezeichnen. Das heißt, Sie ändern nicht die Mixin-Definition (wie die Extend-Definition für Selektoren), sondern Sie ändern (erweitern) die resultierenden Klassen.

Korrigieren Sie mich also, wenn ich falsch liege, aber würde Ihr Navbar- / Banner- / Dropdown-Beispiel nicht unterstützt werden von:

.navbar {
  .transition(opacity .2s linear);
}
.banner {
  .transition(opacity .3s linear);
}
.dropdown:extend(.banner) { }

Das heißt, den Unterricht wie gewohnt verlängern? Ich versuche nur, mich mit Ihrem Verwendungsmuster auseinanderzusetzen, und die Verwendung von Extend für Mixins scheint im Widerspruch zu seiner Verwendung und Nomenklatur zum Erweitern von Selektoren zu stehen. Können Sie weitere Details dazu angeben, warum Sie das Mixin in einem Extend-Aufruf referenzieren müssen/möchten und keinen Selektor erweitern, der auf das Mixin verweist?

So verstehe ich es

GEWÜNSCHTE ENDGÜLTIGE CSS-AUSGABE

.sometingShared,
.anotherClass,
.anotherYetClass,
.yetClass {
    // amount of shared code here
}

.anotherClass,
.anotherYetClass {
    // did something dynamic with a
}

.yetClass {
    // did something dynamic with b
}

.anotherClass {
    // native another class code
}

.anotherYetClass {
    // native another yet class code
}

.yetClass {
    // native yet class code
}

DER WEG, DEN SIE MIT DER AKTUELLEN VERSION VON WENIGER GEHEN MÜSSEN, UM DIE GEWÜNSCHTE AUSGABE ZU ERHALTEN

.somethingShared,
.anotherClass,
.anotherYetClass,
.yetClass {
    // amount of shared code here
}

.someMixin(@val) {
    // do something dynamic with val
}

.anotherClass,
.anotherYetClass {
    .someMixin(a);
}

.yetClass {
    .someMixin(b);
}

.anotherClass {
    // native another class code
}

.anotherYetClass {
    // native another yet class code
}

.yetClass {
    // native yet class code
}

EMPFOHLENE WENIGER SYNTAX

.somethingShared {
    // amount of shared code here
}

.someMixin(@val) {
    // do something dynamic with val
}

.anotherClass:extend(.sometingShared, .someMixin(a)) {
    // native another class code
}

.anotherYetClass:extend(.sometingShared, .someMixin(a)) {
    // native another yet class code
}

.yetClass:extend(.sometingShared, .someMixin(b)) {
    // native yet class code
}

Während die Erweiterungen nur dann nützlich sein können, wenn Sie wirklich viel gemeinsam genutzten Code haben, werden in anderen Fällen gewöhnliche Mixins bevorzugt.

Und nur ein bisschen, Live-Dummy-Sample, das nur zum Spielen gedacht ist

http://jsbin.com/opekon/1/edit
http://jsbin.com/opekon/2/edit
http://jsbin.com/opekon/3/edit
http://jsbin.com/opekon/4/edit

wie gesagt, es könnte unter Umständen für faule Leute wie mich einen wirklichen Leistungsschub geben :) um WENIGER Code zu optimieren, nur weil er die weitere Flexibilität beeinträchtigt

Hier ist ein netter Blog-Beitrag über Extends, der verschiedene Dinge darüber behandelt, wie SASS mit Extended umgeht, und es ist wahrscheinlich ratsam, von anderen zu lernen, wie dies gemacht wurde. http://designshack.net/articles/css/semantic-grid-class-naming-with-placeholder-selectors-in-sass-3-2/

Insbesondere glaube ich, dass mein Vorschlag zur Erweiterung von Mixins im Wesentlichen das gleiche Endergebnis wie SASS-"Platzhalter" erzielen würde, jedoch ohne nutzlose, überflüssige Nur-Platzhalter-Klassen erstellen zu müssen.

EDIT: Ja, hier ist ein weiterer Beitrag, der Platzhalter gut zusammenfasst. Genau das schlage ich mit Erweiterungsmixins vor http://maximilianhoffmann.com/article/placeholder-selectors

Ich persönlich würde dies allen anderen Extend-bezogenen Funktionen vorziehen. Ohne Frage. Dies ist eine starke Aussage, aber ich denke, ich kann es nicht gut erklären, wenn andere nicht zustimmen. Das ist ziemlich starkes Zeug.

Ich fühle, dass SASS

 %tile {
  width: 200px;
  height: 200px;
  margin-right: 20px;
}

ist gleich dem parametrischen Mixin, der ausschließlich für Extended ausgelegt ist, was in Sachen Trennung von Belangen wohl nicht so schlecht ist. Aber ja, das ist CSS, und soll es nicht so einfach wie möglich sein?

@agatronic Wo wir gerade reden, was soll diese Erweiterung https://github.com/agatronic/less.js/blob/master/lib/less/tree/extend.js sein? bemerkt, dass es bereits im Hauptzweig weniger ist. Entschuldigung für die Noob-Frage.

@dmi3y Es ist die erste Version von Extend, die aus einem Pull-Request für 1.4.0 gezogen wurde - es repräsentiert den Extend-Knoten

danke @agatronic , jetzt sehe ich wie sehr ich es vermisst habe ;)

@dmi3y Bitte ergänzen. Versuchen wir, dieses Problem auf einem höheren Niveau zu halten, damit wir es zu einem Abschluss bringen können. Sie können mir auch gerne persönlich eine E-Mail schreiben, ich bespreche gerne mit Ihnen, wie Mixins und Extends funktionieren (meine Kontaktdaten finden Sie in meinem Profil). Auch ein kurzer Kommentar, um weitere Verwirrung in diesem Thread zu vermeiden. Ihr Beispiel:

%tile {
    width: 200px;
    height: 200px;
    margin-right: 20px;
}

Dies ist die Syntax für einen SCSS-"Platzhalter", der in der SCSS-Spezifikation implementiert wurde, um etwas Ähnliches zu erreichen, wie ich es mit dem Erweitern von Mixins vorschlage. Aber das hat nichts mit parametrisch zu tun. Parametrische Mixins sind einfach _Mixins, die Parameter akzeptieren_, was bedeutet, dass sich ihre Werte bei jeder Verwendung ändern können.

@matthewdl

Ich denke, was Sie meinen, ist, dass Sie Klassen definieren möchten, die den gleichen Mixin-Inhalt "einziehen", aber nicht im resultierenden CSS wiederholen

und

würde Ihr Navbar- / Banner- / Dropdown-Beispiel nicht unterstützt werden von ...

Nein, der operative Punkt wird verfehlt, es ist genau umgekehrt. Vielleicht wurde die Verwirrung dadurch verursacht, dass ich den Fehler gemacht habe, mich in meinem Beispiel auf parametrische Mixins zu konzentrieren.

Zuerst denke ich, dass es wichtig ist, klarzustellen, dass nicht alle Mixins parametrisch sind, viele werden so erstellt, dass sie _keine_ Parameter akzeptieren. Einige Mixins, wie Clearfix, werden immer wieder verwendet, ohne dass bei ihrer Verwendung Variablen geändert werden. Dies ist ein perfekter Anwendungsfall dafür, warum das Erweitern von Mixins von Vorteil wäre.

Parametrisch oder nicht, in all ihrer Pracht haben Mixins den Nachteil, dass jedes Mal, wenn eines verwendet wird, seine Eigenschaften dupliziert werden . Lassen Sie mich also versuchen zu erklären, wie das Erweitern von Mixins funktioniert, indem Sie nur "normale Mixins" verwenden, und fahren Sie mit dem oben verwendeten Beispiel fort.

In Ihrem Beispiel müssen zwei völlig unabhängige und nicht miteinander verbundene Punkte erwähnt werden:

1. die Banner-Klasse würde immer noch im kompilierten CSS auftauchen, egal ob sie erweitert wurde oder nicht, aber wenn die Banner-Klasse ein Mixin wäre, würde sie nur im resultierenden CSS auftauchen, wenn sie verwendet wurde (entweder erweitert oder eingemischt). Dies allein ist wertvoll. Und
2. Wenn Sie ein Mixin _erweitern_, anstatt die gleichen Eigenschaften immer wieder zu duplizieren, würden wir die tatsächlichen Selektoren selbst an die Stelle des Mixins kopieren.

Aber das ist nur ein Beispiel. Bedenken Sie, dass an einer Stelle in Twitter Bootstrap allein das .clearfix() Mixin mehr als 20-mal in anderen Selektoren verwendet wurde UND es auch in 4 oder 5 anderen strukturellen Mixins verschachtelt war, z. B. .container-fixed() , .make-row() und #grid > .core() . Das bedeutet, dass diese Mixins _auch_ die Eigenschaften des Clearfix-Mixins bei jeder

Ist das sinnvoller? Also anstatt die Eigenschaften des clearfix mixin mit dupliziert mehr als 20 Mal, würden wir Gruppenwähler, die die clearfix mixin an der Stelle des mixin selbst verwenden, und die Eigenschaften würden nur einmal deklariert werden. Und wieder, dies ist nur ein Mixin, stellen Sie sich den Nettonutzen vor, wenn Sie den Verlust von regulären Mixins verlängern, anstatt ihre Eigenschaften dupliziert zu haben. Wie ich oben erwähnt habe, müssen normale Mixins manchmal immer noch ohne Erweiterung verwendet werden, um Spezifität und Überschreibungen zu erzielen, aber das mindert nicht den Wert der Erweiterung derjenigen, die dies nicht tun. Tatsächlich würde ich persönlich zusätzliche Mixins erstellen, die speziell mit Extend verwendet werden, die ich sonst nicht verwenden würde.

Und mein zweites Beispiel oben konzentrierte sich darauf, wie Extend mit parametrischen Mixins funktionieren würde, also vervollständigt dies hoffentlich das Bild und macht jetzt mehr Sinn? Wenn nicht, sollten die Artikel, auf die ich oben verlinkt habe, jede Verwirrung beseitigen. Das Erweitern von Mixins ist äußerst mächtig und nützlich und würde es Ihnen ermöglichen, das gleiche Nettoergebnis wie das Erweitern verschachtelter Selektoren zu erzielen, jedoch mit Mixins speziell anstelle von verschachtelten Selektoren. Auf diese Weise können Sie Ihre Selektoren so organisieren, dass Sie mit hoher Wahrscheinlichkeit die gewünschten Ergebnisse erzielen und unbeabsichtigte Folgen vermeiden. @DesignByOnyx , @agatronic , @matthewdl , vermisse oder vergesse ich hier etwas? Können wir etwas tun, um die Verwirrung zu beseitigen?

Vielen Dank. Ich glaube, ich verstehe den Anwendungsfall, und ich denke, diese Zeile sagt es am besten:

die Bannerklasse war ein Mixin, sie würde nur im resultierenden CSS auftauchen, wenn sie verwendet würde (entweder erweitert oder eingemischt)

Das macht für mich Sinn. Was ich wahrscheinlich hängen bleibe, ist, dass die allgemeine :extend Syntax noch nicht endgültig ist. Aber Sie machen überzeugende Argumente.

Ich würde sagen, dass, sobald wir die Selektorblöcke abgeschlossen haben, das Verhalten von erweiternden Mixins mit dem Verhalten von erweiternden Selektoren übereinstimmt (mit dem Hauptunterschied, dass die Zeile, die Sie gerade gesagt haben, kein Selektor im CSS für eine erweiterte Ausgabe ausgegeben wird ES sei denn, es gibt eine erste Verwendung), dann ist das für mich intuitiv.

Das heißt, wenn ich auch so etwas tun könnte (oder eine äquivalente Syntax):

.facebook-button:extend( .button() all ) {
    border: 1px solid #e5e5e5;
}

...dann Daumen hoch von mir. Aber für mich hängt das alles davon ab, was/wie/ob wir :extend für Selektoren auflösen. Aber abgesehen von der Syntax, als Feature-Idee haben Sie Recht, es ist solide.

@jonschlinkert danke, schätze deine formulieren . Ich denke, es ist ziemlich aufregend zu hören, was bei der zukünftigen Entwicklung vor sich geht und ja, gehört zu werden. Ihr alle macht tolle Arbeit damit.

Ja, dieses Beispiel, ich musste mit meinem vorherigen Post explizit sein.

%tile {
   width: 200px;
   height: 200px;
   margin-right: 20px;
 }

stammt aus den SASS-Tutorials von Jon, und das Hauptziel davon ist zu vermeiden, dass die CSS-Ausgaben von Klassen, die nicht verwendet werden, in den Papierkorb geraten. In diesem speziellen Winkel könnte es also wie ein leeres parametrisches Mixin in LESS gesehen werden. Wenn Sie es verwenden möchten, aber nicht möchten, wurde es in das End-Stylesheet ausgegeben.

Ich springe in diese Diskussion ein und möchte mir zu folgendem Kommentar Klarheit verschaffen:

Wenn die Bannerklasse ein Mixin wäre, würde sie nur im resultierenden CSS angezeigt, wenn sie verwendet wurde (entweder erweitert oder eingemischt)

Also, um ein allgemeineres Clearfix-Beispiel zu verwenden, ist dies das WENIGER und resultierende CSS?:

.clearfix() {
    &:before,
    &:after { content: " "; display: table; }

    &:after { clear: both; }
}
.something:extend( .clearfix() ) { }

/*
.clearfix:before,
.clearfix:after,
.something:before,
.something:after {
    content: " ";
    display: table;
}
.clearfix:after,
.something:after {
    clear: both;
}
*/

Ich hatte ursprünglich erwartet, dass die Klasse .clearfix im kompilierten CSS weggelassen wird. Persönlich würde ich die Klasse im kompilierten CSS nicht _brauchen_, da ich sie nicht im Markup verwenden würde und es zusätzliche Bytes in meinem CSS sind. Ich habe keine wirklich starke Meinung, aber eine Klarstellung in diesem Punkt würde mir helfen, bessere Kommentare zu machen. Vielen Dank.

ist das das ... resultierende CSS?:

Ich freue mich, dass Sie fragen, aber nein , im resultierenden CSS würde nur die Klasse .something angezeigt. Sie lagen also mit Ihrer ursprünglichen Erwartung richtig.

Lesen Sie einfach den Platzhalter-Link und ja, ich denke, das Erweitern von Mixins ist ein besserer und weniger Weg, um Dinge zu tun und die gleiche Funktionalität zu erhalten.

Um deinen obigen Punkt zu verdeutlichen

.clearfix() {
    &:before,
    &:after { content: " "; display: table; }
    &:after { clear: both; }
}
.something:extend( .clearfix() ) { }

/*
.something:before,
.something:after {
    content: " ";
    display: table;
}
.something:after {
    clear: both;
}
*/

und wenn die .clearfix() { Definition vermutlich .clearfix { dann macht der Aufruf mit oder ohne Klammern innerhalb der Extend-Definition keinen Unterschied für die Ausgabe.

Die Verwendung der Pseudoklassensyntax für die Erweiterungsfunktion ist völlig FALSCH,
da "sth erweitern" NICHT gleich "passen mit sth" ist, bedeutet dies nichts über die DOM-Struktur, die ein Selektor haben sollte.

Ihr WENIGER Jungs habt viele schlechte Ideen "erfunden". Die bekannteste ist die "Wiederverwendung" von .xxx (Klassenauswahl) als Mixin-Notation. Zumindest erleichtert es die Migration von einfachem CSS zum Präprozessor. Aber die :extend-Syntax ist die schlechteste Idee, die ich je gehört habe.

Ich möchte diese Art von Gerede über unsere Themen nicht würdigen, aber dies ist nicht das erste Mal, dass ich diese Dinge höre, also lass uns über CSS reden und die Luft räumen.

Ihr WENIGER Jungs habt viele schlechte Ideen "erfunden". Die bekannteste ist die "Wiederverwendung" von .xxx (Klassenauswahl) als Mixin-Notation. ....: Syntax erweitern ist die schlechteste Idee, die ich je gehört habe.

.xxx wird als implizites Mixin bezeichnet. Es funktioniert, und es ist leicht zu verstehen. Tatsächlich ist diese Syntax für die CSS-Spezifikation nicht so "invasiv" wie beispielsweise die Verwendung von at-Regeln für das tatsächliche Styling. @keyframes kommt dem am nächsten, was man als Styling bezeichnen würde und könnte _vielleicht_ als Ausnahme von dem, was ich sage, angesehen werden, da Bezeichner verwendet werden, die der Bezeichnerproduktion in der CSS-Syntax entsprechen. Abgesehen von Keyframes sind CSS-at-Regeln im Allgemeinen hauptsächlich für die Konfiguration auf höherer Ebene und die Style- oder Stylesheet-Manipulation basierend auf "externen" Informationen reserviert, d. h. außerhalb der Styles selbst, wie der Zeichencodierung ( @charset ) oder auf gerätespezifische Bedingungen reagieren ( @media ).

Außerdem fallen mir noch schlimmere Ideen ein. So wie die Verwendung von at-Regeln für das Styling eine davon ist, ist die Verwendung von zwei at-Regeln für dasselbe Feature eine andere. Natürlich hängt alles von Ihren Zielen ab. Wenn Sie Stile programmatisch manipulieren möchten, ohne sie persönlich zu berühren, dann gibt es wahrscheinlich Vorteile, stumpfere und offensichtlichere Grammatikkonstrukte zu verwenden, die für einen Parser möglicherweise einfacher zu erfassen sind. Anscheinend verwenden Sie Stylus, daher bin ich daran interessiert, Ihren Standpunkt dazu zu hören, warum andere Syntaxen von Vorteil sind.

"extend sth" ist NICHT gleich "match sth", es sagt nichts über die DOM-Struktur aus, die ein Selektor haben sollte.

Richtig. Pseudoklassen mit nth _something_ werden von der CSS-Spezifikation als " strukturelle " Pseudoklassen bezeichnet. Es gibt jedoch 6 weitere Typen von Pseudoklassen: "dynamisch", "Negation", "Ziel", "Blank", "UI-Element-Zustände" und "Sprache". Wenn die CSS-Spezifikation tatsächlich ein "Extend"-Feature beschreibt, könnte es als Kategorie zwischen den Pseudoklassen "Negation" und "Target" recht elegant platziert werden.

Pseudoklassen ermöglichen eine Auswahl basierend auf Informationen im Dokumentbaum, aber dies ist wahrscheinlich keine optimale Verwendung der Erweiterungsfunktion.

total falsch

Eine Community, die größer ist als alle anderen Präprozessoren zusammen, kann sich nicht irren. Was gibt es noch zu sagen?

@hax - :extend Threads Ihre eigene Lösung vorschlagen. Nach wochenlangen verschiedenen Vorschlägen und Überlegungen zwischen sehr erfahrenen Front-End-Entwicklern und intensiven Benutzern von LESS sind wir mit der :extend Syntax zu einer zufriedenstellenden Lösung gekommen. Wenn Sie einen besseren Vorschlag haben, glauben Sie mir - wir sind ganz Ohr.

Um @jonschlinkert hinzuzufügen, sind .this:not(.that) { } und .this:matches(.that) { } und .this:extend(.that) { } kategorisch ähnlich. Das heißt: "Gegebenen Selektor 'dies', beziehen Sie ihn auf Selektor 'das' in einer bestimmten Weise." Da LESS oft in CSS eingeführte Konzepte und Syntax erweitert, ist es eine ziemlich logische Erweiterung der Sprache. Wir achten sehr auf die CSS-Spezifikation und spiegeln ihre Eigenheiten wider. Wenn das Konzept seltsam ist, beginnt es hoffentlich zuerst in CSS. Deshalb wird in unseren Mixin Guards "AND" durch das Wort "and" und "OR" durch ein Komma repräsentiert: denn so ist es bei Medienabfragen. Unser Ziel ist es nicht, CSS zu reparieren oder zu ändern, sondern die Arbeit mit CSS viel einfacher zu machen und CSS-Autoren weniger vertraut zu machen. :extend ist ein Beispiel dafür. Wenn Sie wissen, wie man :not , wissen Sie, wie man :extend .

Was wäre, wenn wir dafür eine "implizitere" Syntax verwenden würden, um das Verschachteln von Klammern zu vermeiden und die Erweiterung parametrischer Mixins zu erleichtern?

Heute verwenden wir ein parametrisches Mixin wie folgt:

.square {
  .border-radius(9px);
}

Anstatt das Mixin wie folgt zu erweitern (wie Sie eine normale Klasse erweitern könnten):

.square {
  &:extend(.border-radius);
}

Wir könnten so verlängern:

.box {
  .border-radius:extend(9px);
}
.square {
  .border-radius:extend(9px);
}
.rectangle {
  .border-radius:extend(4px);
}

Der Unterschied besteht darin, dass das "erweiterte Mixin" mit einem Semikolon endet und einen oder mehrere Werte innerhalb der Klammern, .border-radius:extend(9px); , deklariert, anstatt die Klassen aufzulisten, die innerhalb der Klammern erweitert werden sollen, und einen neuen Selektorblock mit geschweiften Klammern zu beginnen. .border-radius:extend(.some-class) {} . IMHO, das ist nicht weniger subtil als implizite Mixins ( .border-radius; ), was wiederum IMHO eines der coolsten Features von LESS ist.

In der gerenderten Ausgabe würde jedes "erweiterte parametrische Mixin" an der Stelle des ursprünglichen Mixins gerendert, wie folgt:

.box, 
.square {
    -webkit-border-radius: 9px;
    -moz-border-radius: 9px;
    border-radius: 9px;
}
.rectangle {
    -webkit-border-radius: 4px;
    -moz-border-radius: 4px;
    border-radius: 4px;
}
.some-other-class, 
.another-class, 
.and-another {
    -webkit-border-radius: 2px;
    -moz-border-radius: 2px;
    border-radius: 2px;
}

Also ich persönlich mag das, weil es genug von der "normalen" Extend-Syntax innerhalb von Selektorblöcken abweicht, um es offensichtlich genug zu machen, was passiert, und es geht einher mit der Subtilität bestehender weniger Konventionen, bei denen es nicht nötig ist, zu erklären, was passiert Sie versuchen, im Code zu erreichen. Diese Funktion steht definitiv ganz oben auf meiner persönlichen Wunschliste.

Mit dem Clearfix-Beispiel, das ich in meiner ursprünglichen Anfrage angegeben habe, würde es mit meiner überarbeiteten Syntax so aussehen:

.clearfix() {
    // ...
}
.navbar {
    .clearfix:extend(); // instead of &:extend(.clearfix());
}
.banner {
    .clearfix:extend();
    &:extend(.some-class); // "implicit mixin" being extended
}

Ich mag, wohin du damit gehst. Ich denke, ein freundlicherer Ansatz ist die Verwendung eines :extend am Ende der _existing_ Mixin-Syntax als solche:

.box {
  .border-radius(9px):extend;
}
.square {
  .border-radius(9px):extend;
}
.rectangle {
  .border-radius(4px):extend;
}

Etwas über das Weglassen der Klammern nach dem :extend gibt dem Gefühl, dass es einem anderen Zweck dient als die vorhandene Extend-Syntax.

Ich könnte jeden Weg damit gehen, aber ich bevorzuge .border-radius:extend(9px); weil es mit der Extend-Syntax übereinstimmt. IMO ist es immer noch offensichtlich, dass es ein Mixin ist, aber es impliziert auch, dass die Parameter / Werte erweitert werden - was zur Erklärung beitragen wird warum die Ausgabe "gruppiert" ist.

@jonschlinkert - zu diesem Zeitpunkt

@DesignByOnyx danke für die

.this:extend(.that) {}

Dein Punkt stimmt also mit meiner eigenen Ansicht überein. @matthewdl oder @lukeapage hat einer von euch eine Meinung/Meinung dazu? Ich denke, beide Syntaxen könnten funktionieren (und wahrscheinlich auch andere), aber zugegebenermaßen habe ich mich bei keiner der Syntaxen auf "Zukunftssicherheit" konzentriert, daher könnte es bei beiden einige Fallstricke geben. Ich würde das einfach gerne sehen, ich denke, das Erweitern von Mixins ist ein aufregendes Feature für Less, es wird mehr zum Generieren von DRY-Code beitragen als jedes andere Feature, das mir im Moment einfällt

Warum kann der Less-Compiler nicht automatisch "das Richtige tun"? Mit anderen Worten, wenn ich dieses Mixin in meinem Code deklariert habe:

.someMixin {
    color: red;
}

Und später verwende ich es so:

#someElement {
    .someMixin;
}

Warum kann der Compiler nicht einfach intelligent genug sein, um diesen Less-Code in dieses CSS zu optimieren:

.someMixin,
#someElement
{
    color:red;
}

Warum sollte ich als Benutzer manuell ein :extends-Schlüsselwort hinzufügen müssen, um dieses Verhalten zu erzielen? Der Compiler sollte intelligent genug sein, um zu erkennen, dass diese Optimierung durchgeführt werden kann, und sie dann ausführen.

Persönlich halte ich diese :extends-Idee für verwirrend. Der ganze Begriff eines "extends"-Schlüsselworts bedeutet: "Nimm dieses Ding X und füge A, B und C hinzu." Aber in diesem Zusammenhang schlagen Sie vor, erweitert neu zu definieren: "Dieses Ding X ist eigentlich dasselbe wie Y, also können Sie Y und X einfach für gleich erklären und einmal schreiben." Dies widerspricht der üblichen Vorstellung, etwas zu "erweitern".

Ja, genau das habe ich mir schon früher gedacht und wollte es posten, aber nachdem ich darüber nachgedacht hatte, entschied ich, dass das automatische Anwenden von "Verhalten erweitern" auf Mixins für Less.js zu eigensinnig ist. Obwohl die Selektorvererbung (Erweitern) ein großartiges Konzept ist, das für die Codereduzierung äußerst vorteilhaft ist, besteht die überwiegende Mehrheit der Beschwerden, die ich über die Funktion gelesen habe, darin, dass sie eine Abstraktionsebene hinzufügt, die es schwierig macht, Code zu durchkämmen und debuggen, wenn es Probleme gibt.

Große Köpfe denken also ähnlich, aber ich persönlich stimme der Idee ab, weil a) wir uns überhaupt nicht mit "normalen" Mixins anlegen sollten, bis die extend Funktion vollständig stabil und die Spezifikation vollständiger ist, b) Ich denke, viele Entwickler möchten diese Entscheidung für sich selbst treffen, und c) oft erscheinen die Dinge so offensichtlich und abgedroschen, obwohl wir viele der Exzentrizitäten von Mixins vergessen, die Sie machen würden Vorschlag ist zumindest schwer zu implementieren und wahrscheinlich unmöglich zu implementieren, während Entwickler immer noch alle "Mixin-Hacks" verwenden können, die wir haben ... ähm, sie kennen und lieben gelernt haben.

Die Syntax von :extends() ist immer noch ein ziemlich ungeschickter Hack, der nicht intuitiv ist und neuen Benutzern schwer zu erklären ist.

Die bessere Lösung besteht darin, den Compiler einfach wie oben beschrieben automatisch optimieren zu lassen, wenn der Benutzer einen geeigneten Ausgabestil (komprimiert, optimiert usw.) ausgewählt hat. Wenn der Benutzer den unkomprimierten Ausgabestil wählt, sollte der Compiler diese Optimierungen vermeiden und weniger DRY-Code generieren.

Außerdem können Sie die Debugging-Schwierigkeiten mit Quellzuordnungen lösen. Sie können leicht auf den Speicherort des kompilierten CSS hinweisen, das aus einem Less-Mixin stammt.

@bdkjones erstelle bitte eine neue Funktionsanfrage für die "automatische Optimierung des CSS" mit deinen Vorschlägen, wie dies im Code erreicht werden kann. Diese Art von Input ist immer willkommen.

Punkt genommen! Ich wollte in meinem letzten Kommentar nicht ganz so hart sein; Ich lasse mich manchmal mitreißen.

Was den Code angeht, so bin ich leider total mit CodeKit beschäftigt. Ich lasse euch die Sprachen raushauen!

Gar nicht! Wirklich, ich habe gesehen, dass Sie mit CodeKit involviert sind, würde gerne Ihren weiteren Beitrag haben. Nicht alle Funktionen werden jedem gefallen, aber Feedback und starke Meinungen sind die einzigen Dinge, die die Räder am Laufen halten!

@bdkjones Das Problem ist die Kaskade. In Ihrem Anwendungsfall funktioniert es, aber die Selektorgruppierung würde nicht in allen Fällen das gewünschte Ergebnis bringen, da sie Selektoren möglicherweise "früher" im Dokument verschieben würde, um Deklarationen zu verhindern, die diese Selektoren überschrieben.

Aber ich stimme Ihren Aussagen gegen die Mixin Extend-Syntax zu, wie sie sich hier entwickelt hat. Selector X sollte Selector oder Mixin Y erweitern, daher erscheint dies seltsam:

.border-radius(9px):extend;

Ich denke, wir missbrauchen die Extend-Syntax. Wenn die vorhandene Extend-Syntax nicht zu Mixins passt (was absolut plausibel ist), würde ich vorschlagen, dass wir die richtige Syntax für Mixins finden, anstatt die Extend-Syntax so zu erweitern, dass die Metapher verstümmelt wird , wie

Ich glaube, wir missbrauchen die Extend-Syntax

Ich bin nicht einverstanden. Wenn es funktioniert, verwenden Sie es. Warum ohne Grund neue Syntaxen erstellen? Ich denke, wir haben einen großartigen Präzedenzfall für die vorgeschlagene Syntax, ich gebe zahlreiche Beispiele und unterstützende Gründe für meine Vorschläge, aber Ihre Meinung zu den vorgeschlagenen Syntaxen scheint sehr subjektiv zu sein. Und da Sie diese Aussage in letzter Zeit einige Male gemacht haben, können Sie erklären, warum Ihrer Meinung nach die Syntax missbraucht wird? Oder erklären Sie, an welcher Stelle eine Syntax missbraucht wird? Oder teilen Sie Ihre Gedanken darüber, wie Mixins erweitert werden sollten, jedoch ohne die Syntax "extend"?

In Ihrem Anwendungsfall funktioniert es, aber die Selektorgruppierung würde nicht in allen Fällen das gewünschte Ergebnis bringen, da sie Selektoren möglicherweise "früher" im Dokument verschieben würde, um Deklarationen zu verhindern, die diese Selektoren überschrieben.
...
Ich denke, wir missbrauchen die Extend-Syntax. Wenn die vorhandene Extend-Syntax nicht zu Mixins passt (was durchaus plausibel ist), würde ich vorschlagen, dass wir die richtige Syntax für Mixins finden, anstatt die Extend-Syntax so zu erweitern, dass die Metapher verstümmelt wird, wie bdkjones hervorhebt .

Nein. Er hat auf nichts hingewiesen, er hat uns gedrängt, Less einfacher zu machen - das war sein Endergebnis. Seine vorgeschlagene Vorgehensweise war fehlgeleitet, aber die Absicht war gut. Woran er nicht gedacht hat, ist die Kaskade, auf die Sie gerade hingewiesen haben. Bei der Verwendung von Extend im Allgemeinen müssen Sie die Kaskade berücksichtigen. Ich denke, jeder, der Extend anstelle eines Mixins verwendet, ist sich dessen bewusst. Aus diesem Grund bietet Ihnen Less.js die Möglichkeit, es entweder zu verwenden, wenn es sinnvoll ist, oder _nicht_, wenn dies nicht der Fall ist. Die Tatsache, dass das erste "C" in CSS für Cascading steht, macht den Vorteil der Konsolidierung doppelter Stile nicht zunichte, wenn die Kaskade nicht wesentlich ist. Was fehlt mir hier?

Können Sie Ihre Meinung also verdeutlichen? Sind Sie gegen diese Funktion oder die Syntax? Wenn Sie gegen die Syntax sind, schlagen Sie bitte etwas anderes vor, um die Dinge am Laufen zu halten.

Sind Sie gegen diese Funktion oder die Syntax?

Ich bin für das Feature, absolut. Dies ist eine offensichtliche Richtung. Ich habe die Syntax in diesem Thread noch einmal überprüft. Einige Gedanken:

Das ist mir erstmal unangenehm:

.something:extend( .clearfix() ) { }

Die doppelten Klammern sind einfach komisch. Aber es ist eine getreue Übernahme der bestehenden Extend-Syntax, also fair genug. Deshalb plädierte ich für etwas anderes, vielleicht etwas anderes als die Ausdehnung.

Dann gibt es das, was Sie vorgeschlagen haben, ich denke aus ähnlichen Gründen:

.border-radius(9px):extend;

...auf die ich allergisch reagiert habe, da es anscheinend im Widerspruch zu den bestehenden Extend-Spezifikationen steht. Also kam es mir wie Missbrauch vor.

ABER

Mir wurde klar, dass es da eigentlich zwei Möglichkeiten gibt. Einer ist, dass wir für Mixins etwas anderes machen. Aber die andere Möglichkeit besteht darin, dass wir die vorhandene Extend-Spezifikation für alle Dinge, einschließlich Mixins, überarbeiten, wie zum Beispiel:

#namespace {
  .box-template {
    .subelement {
      // we'll add the all flag to extend everything here
    }
  }
}
.clearfix() {
  // a clearfix mixin
}
.text-shadow(@shadow) {
  -moz-text-shadow: @shadow;
  text-shadow: @shadow;
}
.some .random .selector {
  // with properties
}
.mybox {
  .clearfix:extend;
  #namespace > .box-template:extend !all;
  .text-shadow:extend(2px 2px #ff0000);
  .some .random .selector:extend;
}

Aber.... mit einem vollen Selektor ( .some .random .selector ) fängt es an, falsch zu lesen. Es sieht so aus, als ob nur .selector die Erweiterung enthält. Und das Wort "verlängern" geht verloren, wenn es das wichtige Wort in dieser Erklärung ist. Dies war nicht der Fall, als es als &:extend() (weil es am Anfang erschien), aber diese Syntax scheint bei Mixins zusammenzubrechen.

Daher würde ich eine dieser Optionen vorschlagen:

// Migrating existing syntax, but ommitting a parens requirement when used with &:

.mybox {
  &:extend .clearfix;
  &:extend #namespace > .box-template !all;
  &:extend .text-shadow(2px 2px #ff0000);
  &:extend .some .random .selector;
}

// Adopting something similar to the SASS approach

.mybox {
  <strong i="24">@extend</strong> .clearfix;
  <strong i="25">@extend</strong> #namespace > .box-template !all;
  <strong i="26">@extend</strong> .text-shadow(2px 2px #ff0000);
  <strong i="27">@extend</strong> .some .random .selector;
}

Ich denke, die Diskussion über das Erweitern von Mixins und Medienabfragen hat gezeigt, dass unser ursprünglicher Syntaxansatz für :extend nicht so flexibel ist, insbesondere wenn wir mehrere Selektoren und Mixins erweitern möchten.

Ich denke, es ist wichtig, :extend richtig zu machen. Wenn wir "extend" für Mixins verwenden möchten, müssen wir meiner Meinung nach die Extend-Syntax überarbeiten.

Ich habe nicht .border-radius(9px):extend; , @DesignByOnyx hat es getan. Ich habe .border-radius:extend(9px);

Aber beide Syntax ist für mich in Ordnung. Oder wir könnten .border-radius(9px) !extend; oder .border-radius:shamallamadingdongscoobiedoo(9px):extendmyass (jk) machen, mir ist das egal, da sich am Verhalten von Mixins nichts ändert oder überhaupt erweitert.

Ich bin mir also nicht sicher, wie Sie auf die Notwendigkeit kommen, all das zu tun, wahrscheinlich machen Sie es sich selbst zu kompliziert.

Bei dieser Feature-Anfrage geht es ausdrücklich darum, die geerbten Eigenschaften eines Mixins _an die Stelle des Mixins_ kopieren zu können, und es werden Regeln befolgt, die beim aktuellen Mixin-Verhalten bereits gut etabliert sind und jetzt auch Vorrang haben und identisches Verhalten zu die <strong i="14">@import</strong> (reference) Funktion (die ich übrigens schon ziemlich oft in der Praxis und Liebe benutzt habe). In einer Nussschale:

• Wenn Sie ein Mixin verwenden, werden seine Eigenschaften an die Stelle des Selektors kopiert, der das Mixin aufruft.
• Wenn Sie Extend verwenden, wird der Selektor _extending_ an die Stelle der Klasse _extended_ kopiert.
• Wenn Sie also ein Mixin erweitern, wird der aufrufende Selektor an die Stelle des Mixins kopiert.

Ich bin mir nicht sicher, warum Sie die Debatte über die Syntax nach zwei Jahren Debatte, > 100 Posts, viel Recherche und der Argumentation, dass es _viel flexibler_ als @extend ist, überhaupt noch einmal aufwärmen wollen.

Übrigens, ich bin mir nicht sicher, was du hier meinst:

mit einem vollen Selektor (.some .random .selector) beginnt es falsch zu lesen. Es sieht so aus, als ob nur .selector die Erweiterung enthält. Und das Wort "verlängern" geht verloren, wenn es das wichtige Wort in dieser Erklärung ist.

Ich stimme nicht zu, dass es verwirrend ist, da es jetzt tatsächlich so funktioniert. Ist das nicht so, als würde man sagen "CSS-Entwickler wissen nicht, wie gruppierte Selektoren funktionieren"? Was ist mit :hover oder :after ? Ich denke, CSS-Entwickler können dies gut herausfinden, da es genauso funktioniert wie andere Pseudos.

.some .random .selector:extend(.something) {}

Ich mag die Flexibilität, die dies bietet, da ich entweder (oder beide) Extend auf den Selektor anwenden kann, der .some .random .selector , nicht .selector , oder ich kann ihn in den Selektorblock stecken.

Ich denke, die Diskussion um das Erweitern von Mixins und Medienabfragen

Ich habe das Problem mit den Medienabfragen geschlossen, weil mir klar wurde, dass es durch das Erweitern von Mixins gelöst werden könnte. "Alle Wege führen zu _____" erweiterten Mixins. ;-)

Ich möchte meine zwei Cent einwerfen und sagen, dass die Eltern in einem Elternteil - :extend( .some-mixin() ) - mich nicht wirklich stören, zumal :extend( .some-selector ) bereits etabliert ist und bis zum Überdruss diskutiert wird. Ich stimme zu, dass die doppelten Eltern keineswegs ideal sind und es sich irgendwie komisch anfühlt. Aber ich denke, dass es wichtig ist, dass Mixins und Selektoren in Bezug auf "Erweitern" gleich behandelt werden, ähnlich wie sie im klassischen Less gleich behandelt werden:

header {
    .some-selector;
    .some-mixin;
    .some-mixin();
}

Als solches fühle ich mich nicht wirklich schlecht (oder eingeschränkt), indem ich Folgendes tue:

header {
    &:extend( .some-selector );
    &:extend( .some-mixin );
    &:extend( .some-mixin() );
}

Aber ich denke, dass es wichtig ist, dass Mixins und Selektoren in Bezug auf "Erweitern" gleich behandelt werden, ähnlich wie sie im klassischen Less gleich behandelt werden

In diesem Punkt bin ich auf der gleichen Seite.

Ich bin mir nicht sicher, warum Sie die Debatte über die Syntax nach zwei Jahren Debatte noch einmal aufwärmen möchten, > 100 Beiträge

Es geht nicht darum, zu wollen. Nein, ich will nicht. Aber zu der Zeit haben wir Mixins sozusagen abgemischt, um uns später damit zu befassen. Ich möchte nur die Frage stellen, ob wir sicher sind, dass diese Syntax für alles so funktioniert, wie wir es wollen. Es ist nichts Falsches daran, die Frage erneut zu prüfen, wenn wir der Meinung sind, dass sie nicht funktioniert oder für einige Anwendungen unelegant ist. LESS gibt es schon lange ohne Ende. Es ist wichtiger, es richtig zu machen, als es schnell zu erledigen.

Also, sind wir damit einverstanden?

.mybox {
  &:extend(.clearfix());
  &:extend(#namespace > .box-template all);
  &:extend(.text-shadow(2px 2px #ff0000));
  &:extend(.some .random .selector);
}

parens in einem parens - :extend( .some-mixin() ) - stört mich nicht wirklich, zumal :extend( .some-selector ) bereits eingerichtet ist

Ja, stimmt, und tatsächlich haben wir auch in Less.js einen Präzedenzfall für doppelte Klammern UND mit der vorhandenen Extend-Syntax. Und der Präzedenzfall, der bereits geschaffen wurde, ist nicht so einfach für die Augen wie das, was wir mit Mixins vorschlagen. Derzeit können wir dies tun:

.one:nth-child(5) {
  color: red;
}
// We can extend psuedos
.two:extend(.one:nth-child(5)) {
  background: blue;
}
// And attributes
.two:extend(.one, [hidden]) {
  width: 2px;
}

Sie finden sogar verschachtelte Klammern in der vorhandenen CSS-Syntax .

Hier haben wir also sowohl _nested parens_ als auch _nested pseudo-class_ Syntax. Und ich habe kein Problem damit, es ist IMO klar.

Also stimme ich @DesignByOnyx zu , das war mein ursprünglicher Vorschlag und schien anderen aus irgendeinem Grund

Tatsächlich würde die ursprüngliche Syntax es ermöglichen, mehrere durch Kommas getrennte Klassen oder Mixins zu erweitern.

.banner {
    &:extend(.clearfix(), .border-radius(4px), .alert, .navbar-fixed-top, [hidden]); 
}

Es macht den Job, und es ist eng. Keine Beschwerden hier.

Also, sind wir damit einverstanden?

ja. ganz und gar. In CSS ist das schon so. Also ich bin gut damit.

ja. ganz und gar. In CSS ist das schon so. Also ich bin gut damit.

SO WIRD ES PASSIEREN.

Frage, ich glaube nicht, dass wir derzeit mehrere Selektoren in :extend unterstützen, daher frage ich mich, wo das Schlüsselwort "all" in dieses Format passen würde, aber das sollte wahrscheinlich Teil eines separaten Problems sein.

Sie haben Ihren Fall vorgetragen, Herr Schlinkert. Du hättest ins Gesetz gehen sollen. ;)

Ich glaube nicht, dass wir derzeit mehrere Selektoren in :extend . unterstützen

Aber wir tun es ;-) Ich habe es ausgiebig getan. Habe das gerade vorhin gemacht:

.global-nav {
  // Extend and override bootstrap styles
  &:extend(.navbar, .navbar-fixed-top all, .navbar-inverse); // this works, and it's pretty handy
  &.hidden:extend(.navbar.hidden) {}
  &.visible:extend(.navbar.visible) {}
  &:hover {
    background: lighten(@brand-primary, 5%);
  }
  .navbar-brand {
    padding-left: 20px; 
  }
  .navbar-nav > .active > a {
    &, &:hover, &:focus {
      background-color: darken(@brand-primary, 5%);      
    }
  }
}

Sie haben Ihren Fall vorgetragen, Herr Schlinkert. Du hättest ins Gesetz gehen sollen. ;)

Pfft, lol oh halt dich!

Ich möchte nur hinzufügen, dass ich denke, diese Syntax:

.foo {
  &:extend( .bar() );
}

ist toll. Ich finde die Klammern gar nicht verkehrt.

Aber hauptsächlich möchte ich nur, dass ihr euch beeilt, damit ich all die coolen Sachen, an denen ich in SASS arbeite, in meinem Lieblings-Präprozessor machen kann :D

Danke für dein Feedback, @mgerring !

+1 Warten auf diese Funktion. Mach weiter so :)

Zum ursprünglichen Beitrag:

.clearfixed {
   // stuff
}
.clearfix() {
    &:extend(.clearfixed);
}
.navbar {
  .clearfix();
}
.banner {
  .clearfix();
}

Vielleicht hat das zum Zeitpunkt der Veröffentlichung nicht funktioniert? Aber es führt zu etwas, das dem, was Sie wollten, sehr nahe kommt:

.clearfixed,
.navbar,
.banner {
  // stuff
}

@aaronmw , Ja, sicher macht Ihr Beispiel dasselbe, aber der Kernpunkt dieses Vorschlags ist die Möglichkeit, ein an anderer Stelle definiertes Mixin zu erweitern (dh wenn Sie das Mixin selbst nicht ändern können oder möchten, z Bibliothek usw.)

Ja, gemäß dem Punkt von @seven-phases-max kann dies so gemacht werden, wie Sie es beschreiben, aber es ist nicht idiomatisch.

Richtig – Entschuldigung, ich habe jetzt viel mehr von diesem Thread gelesen und sehe, was wir anstreben. Die "skeleton" -Klasse, die ich verwendet habe, ist nur Müll in der kompilierten Ausgabe, da die .clearfixed-Klasse außerhalb des Mixins niemals explizit referenziert würde. &:extend(.clearfix()) macht für mich jetzt Sinn und ist ziemlich aufregend. Im Moment beschäftige ich mich mit den Skelettklassen, die mein CSS verunreinigen.

Super Diskussion hier!

:+1:

Wann können wir diese Funktion erwarten? Für Konzepte wie OOCSS ist es sehr nützlich, Konstrukte wie eine "abstrakte Klasse" zu erstellen.

• Entscheiden Sie, wie wir mit Verschachtelung / Geltungsbereich und Mixin im Vergleich zu normaler Klasse umgehen, z

.a {
  color: green;
}
#thing {
  .a() {
    color: black;
   }
}

.b:extend(#thing .a) {}  //
.b:extend(.a) {}  // and if so is the output wrapped by #thing?
.b:extend(.a()) {}  // do I need special format to say extend only that mixin?

• Gehen wir mit Argumenten um? Kombinieren wir Mixins mit den gleichen Argumenten?
• zu-css-visitor ändern, um Mixin-Definitionen nicht zu entfernen
• Bringen Sie den Extend-Besucher dazu, Mixin-Definitionen zu besuchen und einen neuen Regelsatz mit der neuen Klasse zu erstellen

Ich denke, das Schwierigste ist, sich _genau_ zu entscheiden, wie es funktionieren soll.

Entscheiden Sie, wie wir mit Verschachtelung / Geltungsbereich und Mixin im Vergleich zu normaler Klasse umgehen, z

Ich würde versuchen, die Mixin-Erweiterung so zu interpretieren:
.b:extend(.a(1, 2, 3)) {} sollte sich so verhalten, als würde man ein anonymes nicht-parametrisches Mixin (dh einen einfachen Selektor) im Bereich von 'b' erstellen, das .a(1, 2, 3) innen aufruft und dann auf die übliche Weise erweitert, dh dies:

.a(<strong i="11">@a</strong>, <strong i="12">@b</strong>, @c) {
    // ...
}

.b:extend(.a(1, 2, 3)) {}

sollte gleich sein:

.a(<strong i="16">@a</strong>, <strong i="17">@b</strong>, @c) {
    // ...
}

#__anon_a_1_2_3 {.a(1, 2, 3);}

.b:extend(#__anon_a_1_2_3) {}

außer dass kein #__anon_a_1_2_3 in der Ausgabe erscheint. Ich denke, ein solcher Ansatz sollte es weniger oder einfacher machen, ohne spezielle Regeln zu erfinden.

Wenn wir das obige Konzept auf das #thing .a Beispiel anwenden, erhalten wir Folgendes:

.a {
  color: green;
}
#thing {
  .a() {
    color: black;
   }
}

.b:extend(#thing .a) {} // since we do ignore parens on mixin call and have ...
// no plans changing this (?), it should probably create .b {color: black} 

.b:extend(.a) {}  // there's only one .a in this scope so it's -> .b {color: green}

.b:extend(.a()) {}  // same as above -> .b {color: green}

Auf der anderen Seite sind die "optionalen Parens" aus praktischer Sicht eine ziemlich unbedeutende Sache, daher könnte es auch in Ordnung sein, sie strenger zu machen und Parens für parametrische Mixins innerhalb von extend verlangen (es gibt keinen Druck auf extend , um die einfache Mixin-Aufrufsyntax zu erben, da sie sowieso nicht vollständig kompatibel ist).

Kombinieren wir Mixins mit den gleichen Argumenten?

Idealerweise ja, sonst wird das Ganze nutzlos, zB:

.b:extend(.a()) {}
.c:extend(.a()) {}

sollte erstellen:

.b, .c {color: green}

Hmm, es sieht so aus, als ob das Zusammenführen am schwierigsten zu implementieren ist.

Ein weiteres Problem ist der Scope, wie kürzlich in #1730 aufgekommen, Mixins verwenden den 'relativen' Scope-Pfad und Extend verwendet 'absolute', so dass wir eine Art Konflikt bekommen, wenn wir beide kombinieren:

.div {color: green}

body {
   .div {color: red}

   p-a       {.div()}    // -> body p-a {color: red}
   p-b:extend(.div)   {} // -> body p-b {color: green}
   p-c:extend(.div()) {} // -> ???
}

Und es wird noch verwirrender, wenn wir dieses Beispiel mit parametrischen Mixins umschreiben.

Ich möchte meine zwei Cent anbieten, um zu sagen, dass dies ein guter Zeitpunkt sein könnte, einen Schritt zurückzutreten und zu sagen, "wie sollten Erweiterungs-Mixins verwendet werden" - und ich denke, dass @donaldpipowitch Recht hat, wenn er sagt, dass es ein bisschen OOCSS-Fähigkeit bringt . Daher denke ich, dass wir uns nicht zu sehr damit verzetteln sollten, wie Unterklassen ("Eigenschaften", wenn Sie so wollen) innerhalb der Klasse selbst erweitert werden. So haben Benutzer beispielsweise bestimmte "Klassen" (Komponenten) mit "Eigenschaften" (verschachtelte Selektoren):

.dog() {
    .leg { ... }
    .ears { ... }
    .fur { ... }
}

Ich denke, wir sollten uns nicht auf Situationen konzentrieren, in denen ein Benutzer Folgendes tun möchte:

.dog() {
    .leg { ... }
    .ears { ... }
    .fur { ... }
    .tail:extend( .leg() ) { 
        .toes { display:none; } 
    }
}

Dies ist nicht nur ein Randfall-Szenario IMO, sondern der Benutzer sollte seine Stile sowieso so schreiben:

.dog() {
    .leg, .tail { ... }
    .ears { ... }
    .fur { ... }
    .tail .toes { display:none; }
}

Der 99,8%ige Anwendungsfall für die Erweiterung von Mixins besteht darin, Entwicklern zu ermöglichen, ihre massiven LESS-Bibliotheken voller Stile zu haben, die sie im Laufe der Jahre angesammelt haben. Diese riesige Bibliothek wird voller Dinge sein wie:

.clearfix() { ... }
.modal() { ... }
.alert-box() { 
    &:extend( .modal() ); 
    &.message { ... } 
    &.warning { ... } 
    &.error { ... } 
}
.grid-wrap() { ... }
.form-input() { ... }
.form-select() { ... }
.button( <strong i="16">@bgColor</strong>, <strong i="17">@textColor</strong> ) { ... }
[... thousands more like this ...]

Und sie könnten sich auf Schreibstile konzentrieren:

.page-wrap:extend( .grid-wrap(), .clearfix() ) { ... }
input[type="text"]:extend( .form-input ) { ... }
textarea:extend( .form-input() );

Sie könnten dies sogar tun, wenn sie wollten, und keiner der "modalen" Stile wäre in der endgültigen Ausgabe vorhanden, da sie in diesem Projekt nicht verwendet werden:

.inline-error:extend( .alert-box.error )

Ja, ich habe das Gefühl, dass @DesignByOnyx Recht hat. Ich glaube nicht, dass es falsch ist, komplexere Dinge später herauszufinden. Tatsächlich denke ich, dass es im Moment am besten wäre, zuerst _nur nicht-parametrische_ Mixins zu erweitern. Das deckt wahrscheinlich 80 – 90 % aller Anwendungsfälle ab (was eine objektorientiertere Struktur der Stylesheets usw. ermöglicht). Alles andere kann ein oder zwei Patches warten, imo.

@DesignByOnyx und @calvinjuarez wir können das nicht einfach später herausfinden.. es muss auf die eine oder andere Weise codiert werden. Wenn wir eine Lösung überspringen und sie später ändern wollen, führen wir Breaking Changes ein, was nicht gut ist.

Wenn wir einen Ansatz erarbeiten können, der keine Randszenarien unterstützt, bin ich mehr als glücklich, das haben wir mit dem Haupt-Extenden-Support gemacht (der kann bei Bedarf um weitere Keywords erweitert werden), aber wir brauchen einen Plan, was unterstützt wird und wie.

@seven-phases-max im obigen Sinne würde ich gerne parametrische Mixins vorerst ignorieren.

Hmm, es sieht so aus, als ob das Zusammenführen am schwierigsten zu implementieren ist.

• aber es fusioniert? Ich würde den gleichen Ansatz wie die vorhandenen Erweiterungen verwenden, z. B. findet sie eine Übereinstimmung und hängt daran an Fall in seinem genCSS

Ich denke auch, dass das zweite Beispiel von @seven-phases-max über den Geltungsbereich ziemlich wahrscheinlich jemanden betrifft - Sie benötigen nur ein Mixin und ein leeres parametrisches Mixin mit demselben Namen.

@lukeapage :+1: Stimmt, das kann ich ausgraben. Guter Anruf.

Eigentlich denke ich, dass @seven-phases-max es richtig gemacht hat. Also :+1: auch da.

@lukeapage - Ich habe nicht versucht, eine Lösung "so oder so" zu befürworten, sondern eher einen Ansatz, der (wie Sie sagten) keine :extend funktioniert:

.block { color: green; }

.component {
  .block { color: red; }    
  div:extend( .block ) {};
}

/*
.block,
.component div {
  color: green;
}
.component .block {
  color: red;
}
*/

Ich sehe keinen Grund, warum der folgende Code anders als der obige funktionieren sollte - der Vorteil besteht darin, dass die endgültige Ausgabe keine Klasse .block :

.block() { color: green; }

.component {
  .block() { color: red; }  
  div:extend( .block() ) { };
}

/*
.component div {
  color: green;
}
*/

Btw., es gibt leichte Abweichungen in unseren Namenskonventionen :) zum Beispiel bedeutet für mich ein "parametrisches Mixin" jedes mit Klammern definierte Mixin, einschließlich derer mit 0 Parametern (dh .mixin() {} ist ein "parametrisches"). Und "nicht-parametrisches" Mixin ist nur ein einfacher Selektor (dh .mixin {} ). Bisher hat dieser Drift wohl kein Missverständnis verursacht (z. B. war es in den meisten obigen Beispielen aus dem Kontext klar, ob .mixin() {} als "nicht parametrisches" Mixin bezeichnet wurde), aber ...
Verpassen Sie nicht, dass in den Dokumenten ein einfacher Selektor auch als "Mixin" bezeichnet wird (sobald er eingemischt wird) und es auch ein "nicht parametrisches" Mixin ist. Die Bezugnahme auf .mixin() {} allein als "nicht-parametrisch" kann also ziemlich zweideutig sein (technisch gesehen liegt der Unterschied in der Anwesenheit oder dem Fehlen von Definitionsklammern und nicht in der Anzahl der Argumente).
OK, das war mein übliches Boo-Boo-Boo. :)

@lukeapage

Ich würde mich freuen, parametrische Mixins vorerst zu ignorieren.

Dh keine Unterstützung von Extend für Mixins mit Parametern ungleich Null? Das ist ok für mich. Ich habe nur versucht abzuschätzen, wie das implementiert werden könnte (in einer einheitlichen Weise, ohne Null- und Nicht-Null-Parameter-Mixins abzugrenzen, damit es kein Show-Stopper ist, wenn/wenn letztere schließlich einspringen).

aber es fusioniert? Ich würde den gleichen Ansatz wie die vorhandenen Erweiterungen verwenden, z. B. findet sie eine Übereinstimmung und hängt daran an.

Richtig, ich denke da habe ich eher über mögliche Schwierigkeiten beim Zusammenführen von Extends von Mixins mit tatsächlichen Argumenten nachgedacht.: zB:

.b:extend(.a(1, 2, 3)) {}
.c:extend(.a(1, 2, 3)) {}

Auf der anderen Seite vermute ich, dass es auch bei Null-Parameter-Mixins versteckte Überraschungen gibt, zB:

.a {color: red}
.a {width: 2px}

.b:extend(.a) {}   // creates two `.b` blocks (it is expected since there're two `.a` blocks anyway)

.c {.a}            // creates one `.c` block (OK, this is just how mixins work)

.d() {color: blue}
.d() {width: 10px}

.e {.d()}          // creates one `.e` block (OK, this is just how mixins work)

.f:extend(.d()) {} // tada! another room for complains if this creates two `.f` blocks :)

Nun, vielleicht geht das zu tief (und auch zu gering, um es im Moment zu beunruhigen).

.f:extend(.d()) {} // tada! another room for complains if this creates two .f blocks :)

Mit dem Gedanken, dass "da in diesem Beispiel .d() parametrisch ist, sollte es nicht zwei .f Blöcke erstellen"?

Ja, ich kann Ihren Standpunkt verstehen, da ein Mixin Folgendes ergeben würde:

.f {
  color: #0000ff;
  width: 10px;
}

IMHO Wenn es sinnvoll ist, es in Schritten zu machen, vielleicht einfach erklären, aber ich würde nichts _nicht_ implementieren, um eine Beschwerde per se zu vermeiden. Das ist natürlich nur meine 2c. Und wenn es mit dem von dir beschriebenen Verhalten umgesetzt wird, könntest du zum Zeitpunkt des Hinzufügens des Features auch eine Feature-Anfrage zum "Zusammenführen von CSS-Blöcken aus erweiterten Selektoren" erstellen, nur um die Beschwerden abzuwenden...?

aber ich würde nichts implementieren, um eine reklamation per se zu vermeiden.

Ich bin absolut einverstanden. Ich versuche nur, weitere Überraschungen vorherzusagen, die zu einer dieser "zu spät für eine Änderung" werden könnten.

:+1: Ja, ich mag deine Meinung!

Ich finde es gut, dass diese Diskussion noch andauert. Lassen Sie mich auf einige Punkte dieser Diskussion zurückkommen. Erstens, was den allgemeinen Gebrauch anbelangt, ist dies gleich.

.mixin {} == .mixin() {}

Mit der Ausnahme, dass .mixin { } als Klasse ausgegeben wird. Ich weiß, dass sie im Parser wahrscheinlich anders behandelt werden, aber bei der Verwendung geben sie Eigenschafts- / Wertpaare aus.

Bedeutung:

.mixin1() {
    color: red;    
}
.mixin2 {
    color: blue;
}
.use1 {
    .mixin1;
    foo:bar;
}
.use2 {
    .mixin2;
    foo:bar;
}

Aufgrund dieser Less-Syntaxgeschichte ist es sinnvoll, dass ich dies tun könnte:

.mixin1() {
    color: red;    
}
.mixin2 {
    color: blue;
}
.use1 {
    &:extend(.mixin1);
    foo:bar;
}
.use2 {
    &:extend(.mixin2);
    foo:bar;
}

Für mich ist das nicht umstritten, da wir oft über :extend als Drop-In-Ersatz für viele Instanzen der ursprünglichen Mixin-Nutzung gesprochen haben.

Für den Laien wäre dies wahrscheinlich intuitiv identisch, da .mixin1 historisch wie folgt referenziert werden kann, unabhängig davon, ob es in Klammern geschrieben ist oder nicht:

.use1 {
    &:extend(.mixin1);
    foo:bar;
}
.use1 {
    &:extend(.mixin1());
    foo:bar;
}

Also ich würde folgendes erwarten:

.mixin1() {
    color: red;    
}
.use1 {
    &:extend(.mixin1());
    foo:bar;
}
.use2 {
    &:extend(.mixin1());
    bar:foo;
}

...ausgeben...

.use1, .use2 {
    color: red;    
}
.use1 {
    foo:bar;
}
.use2 {
    bar:foo;
}

Wenn mixin zweimal definiert ist, wird es beim Erweitern zweimal ersetzt, genau wie seine Schwester, der Klassenselektor.

.mixin1() {
  color: red;
}
.mixin1() {
  width: 30px;
}
.use1 {
  &:extend(.mixin1);
  foo: bar;
}
.use2 {
  &:extend(.mixin1);
}
//output

.use1, .use2 {
  color: red;
}
.use1, .use2 { 
  width: 30px;
}
.use1 {
  foo: bar;
}

So funktioniert Extend jetzt, wenn Sie Klammern in den Mixin-Definitionen entfernen würden, außer natürlich, dass der Mixin-Name in der Ausgabe erscheint, also wäre es sinnvoll, dem bestehenden Extend-Verhalten zu folgen.

Mit Parametern (mein 90%-Anwendungsfall) dasselbe, außer dass sie nach Eingabe unterschieden werden:

.col(@width) {
  width: @width;
  display: table-cell;
}

.col1:extend(.col(10%)) { }
.col2:extend(.col(10%)) { }
.col3:extend(.col(80%)) { }

//output 

.col1, .col2 {
  width: 10%;
  display: table-cell;
}
.col3 {
  width: 80%;
  display: table-cell;
}

Für mich besteht der Grund für die Erweiterung von Mixins darin, nach Parametern zu gruppieren, was zu leistungsfähigeren Mixin-Bibliotheken führt, die eine sehr prägnante Ausgabe erzeugen können. Sie für Mixins ohne Parameter zu verwenden, ist nicht so wichtig, da ich heute einfach vorhandene Less-Funktionen verwenden könnte, um das gewünschte Ergebnis zu erzielen.

Danke an alle, die das weiter vorantreiben. Ich denke, es könnte eine ziemlich starke Ergänzung sein.

:+1 Danke @matthew-dean für die umfassende Aufschlüsselung - ich stimme allem zu, was Sie behandelt haben. Könnten Sie Ihre Meinung zu diesem Szenario äußern, das eines der Themen der jüngsten Diskussion ist:

.mixin() { color: red; }

.component {
    .mixin() { color: blue; }

    > li:extend( .mixin() ) { ... }
}

So wie LESS derzeit funktioniert, werden nur Mixins im globalen Scope erweitert - dh die roten Styles würden erweitert. Ich persönlich bin mit diesem Verhalten einverstanden, und obwohl wahrscheinlich jemand den obigen Code schreibt und erwartet, dass sich die blauen Stile durchsetzen, denke ich, dass das "globale" Verhalten von Extends ein Einzeiler in der Dokumentation ist.

// this is ".mixin()", which is being extended
.mixin() { color: red; }

.component {
    // this is ".component .mixin()", which is not. 
    .mixin() { color: blue; }

    > li:extend( .mixin() ) { ... }
}

Ich denke, das "globale" Verhalten von Extends ist ein Einzeiler in der Dokumentation.

Stimme voll und ganz zu. Ich finde es eine schreckliche Idee, hier eine Grauzone einzuführen.

Für mich ist Konsistenz wichtig. Wenn das aktuelle Verhalten Selektoren im lokalen Bereich nicht erweitert, sollte dies auch nicht mit Mixins erfolgen. Wenn wir später Selektoren in local erweitern, sollten dies auch Mixins. Die Leute sollten in der Lage sein, einem bibliotheksweiten Muster von :extend zu vertrauen.

(Obwohl ich auch knapper hätte sagen können: "+1 auf @jonschlinkerts Kommentar". ;-)

Kann an dieser Stelle jemand einen Anwendungsfall angeben, der diese Funktion verwirrend machen würde? Bitte beginnen Sie mit dieser umfassenden Übersicht von @matthew-dean und den darauffolgenden Antworten und versuchen Sie, eine reale Situation anzubieten, die noch nicht behandelt wurde.

Schöne Ferien. Frohe Weihnachten. Felices-Fiestas!

Wirklich schöne Übersicht. Ich stimme @matthew-dean und jedem folgenden Kommentar zu. :+1:

Ich stimme auch @matthew-dean zu. Er scheint ein edler Kerl zu sein, und ich würde ihm gerne die Hand schütteln.

(-Anonym)

@matthew-dean Wort. :+1:

Mit dieser Funktion könnten wir den Grid-Systemcode von Bootstrap so viel sauberer machen!

:+1: stimmte @cvrebert zu! wäre nett!

Einfach nochmal vorbeischauen. Ich denke, wir haben fast einen Konsens und müssen nur noch umgesetzt werden, richtig?

Ich versuche, mehr Informationen darüber zu finden, aber es ist wie ein Labyrinth, alles durchzulesen. Wurde das jemals umgesetzt? Wenn ja, kann mich jemand freundlicherweise auf den entsprechenden Bereich in der Dokumentation hinweisen.

@josh18 Nein, wenn eine Funktionsanfrage noch offen ist, bedeutet dies normalerweise, dass sie nicht implementiert ist.

Ok danke, dachte ich schau mal nach, falls ich etwas übersehe.

Ich plane irgendwann offene / zu implementierende Features im Wiki zusammenzufassen, hatte aber noch keine Zeit.

Ich plane irgendwann offene / zu implementierende Features im Wiki zusammenzufassen, hatte aber noch keine Zeit.

@matthew-dean +1

Hallo Leute! Soweit ich weiß, ähnelt diese Funktion den SASS-Platzhaltern. Wollte nur wissen, wann das umgesetzt wird?

Hi,
Ich finde es schwierig, meine Zeit und andere Mitwirkende nur vorherzusagen
Implementieren Sie Dinge, an denen sie interessiert sind, also bin ich mir nicht sicher. Ich kann nur sagen
dass wir es als hohe Priorität betrachten, es ist das nächste große Ding auf meiner Liste.

Vielen Dank für Ihre Antwort. Ich freue mich darauf, dies umgesetzt und funktionieren zu sehen. :)

+1 für diese Funktion. Es ist äußerst hilfreich, um die CSS-Größe zu reduzieren.

+1 für diese Funktion.

+1 für diese Funktion.

+1 mit Interesse zuschauen, danke!

:+1:

es sind ZWEI JAHRE vergangen, seit dieses Problem erstellt wurde. Tag mit hoher Priorität seit November 2014. Meilenstein ist 1.6.0 oder 2.0.0. Groß. Weniger ist jetzt 2,5.

@Grawl

Sie meinen, Sie sind bereit, eine PR zu machen?

@seven-phases-max So ziemlich das habe ich mir gedacht. Eine solche Anzeige der Berechtigung. ;)

@seven-phases-max lol nein, ich bin nur Frontend/Designer.
@Celc sieht wirklich schlecht aus 😅

es sind ZWEI JAHRE vergangen, seit dieses Problem erstellt wurde.

Ja, wofür bezahle ich euch Leute überhaupt? ;-)

Kann leider nicht zur Teilnahme beitragen, aber ich stimme dieser Anfrage sehr zu!

Dies ist eine äußerst wichtige Funktionalität für den Aufbau komplexer und effektiver Frameworks

3 Jahre und Zählen. Glücklicherweise kommt Sass v4 (mit sass-* Präfix-Funktionen) und ich kann Less loswerden.

@stevenvachon Wir

Pull-Requests sind natürlich von jedem willkommen. Gerne binden wir in funktionalen Pull-Request mit diesem Feature ein.

Ich versuche nicht, jemanden zu verletzen, wahrscheinlich versuche ich, dies zu verhindern. Ich denke, es ist besser auszudrücken, wie man sich fühlt und welche neuen Richtungen sie dadurch einschlagen. Ich denke, es ist besser, früher als später zu wissen; bevor alle gehen. Bootstrap v4 wird beispielsweise Less.js nicht verwenden und ich bin mir sicher, dass dies eine große Delle in Ihrer Benutzerbasis bedeuten wird. Sie können solche Politik natürlich ignorieren, so viel Sie wollen.

@stevenvachon warum so offtopic? Sass und Less sind beide großartig. Ich liebe pure JS-ness von weniger. node-sass benötigt einen ac-Compiler, um installiert zu werden, was je nach Umgebung mühsam sein kann. Ich habe die :extend-Funktion verwendet , die bereits in LESS integriert ist und alle meine Bedürfnisse erfüllt. Ich weiß nicht einmal, warum dieses Thema noch offen ist.

Verdammt, ich bin ein Rails-Entwickler und verwende gulp+LESS, wenn es sich nicht um ein Ruby-Projekt handelt.

Off-Thema? Diese Funktion wurde seit 3 ​​Jahren nicht implementiert und wäre sehr nützlich.

Ich würde es vorziehen, wenn Sass in JS geschrieben wäre, aber das ist es nicht, und das ist nicht das Wichtigste. Seine Eigenschaften sind. Sass erlaubt es uns, Platzhalter zu erweitern, aber Less erlaubt uns nicht, Mixins zu erweitern.

Alter, es ist überhaupt nicht offtopic, aber mit Spannung erwartetes Feature! (Auch wenn ich aus verschiedenen Gründen sowieso weniger bevorzugen würde)

Es will einfach gemacht werden.

PS In meinem Fall bin ich eigentlich Designer mit nur einigen Kenntnissen von js, hauptsächlich dom-bezogenem Zeug, wirklich weit entfernt von Entwicklern, die zu less.js Codebase beitragen können. Was sowieso traurig ist)

Nur ein äußerst interessierter Unterstützer des Projekts)

Mitteilung des öffentlichen Dienstes

Sie können jederzeit einen Pull-Request einreichen oder mit einem Entwickler zusammenarbeiten, um einen zu erhalten, und es ist sehr wahrscheinlich, dass diese Funktion integriert wird. Die Less.js-Bibliothek benötigt regelmäßigere Beiträge von Personen wie den Personen in diesem Thread . Es liegt nicht in der Verantwortung einer einzelnen Person. Es hängt ganz davon ab, ob eine Person diesen Thread sieht oder diese Funktion benötigt und sich die Zeit nimmt, dies zu realisieren.

Wenn Ihre Antwort lautet, dass Sie kein Entwickler sind, dann gibt es viele ANDERE Möglichkeiten, dieses Projekt in nicht-Entwicklungsrollen zu unterstützen, sei es die Bereitstellung der erforderlichen Dokumentation für neue Funktionen oder die Designunterstützung auf der Website, das Ausführen von Tests oder das Bereitstellen von Feedback zu Themen, Projektmanagement, Beantwortung von Fragen zu Stack Overflow, Schreiben von Blog-Posts, Tweeten über Less, Beiträge zu CSS und Web-Communitys und Schreiben von Less-Bibliotheken.

Viele dieser Aufgaben werden von Einzelpersonen ausgeführt, die Entwickler sind, sodass die Zeit, die sie zur Entwicklung beitragen könnten, für diese anderen Aufgaben verwendet wird.

Wenn Sie ein Entwickler _sind_ und Ihre Antwort lautet: "Ich habe keine Zeit", dann ist das genau der Grund, warum dieses Problem offen geblieben ist. Es liegt zu 100 % an Ihnen, ob eine Funktion abgeschlossen ist, daher ist es nicht hilfreich, zu fragen, warum sie nicht von "jemandem" abgeschlossen wurde. _Du bist dieser Jemand._ Es wird passieren, ich _garantiere_ es wird passieren, wenn und wenn du dich in dieses Projekt einmischst. Sie können sich an einem der beliebtesten Open-Source-Tools im Web beteiligen. Sie können das Leben von... Tausenden verändern? Hunderttausende? Millionen? Und als Nebeneffekt können Sie sicherstellen, dass Ihre Lieblingsfunktionen eher früher als später verfügbar sind.

Wenn Sie möchten, dass dies oder eine Funktion eintritt, machen Sie es möglich . Wir würden uns freuen, Sie zu haben. Wir arbeiten gerne mit Ihnen zusammen! Weniger kann immer besser werden, je größer diese Community wird!

Und, hör zu, ich weiß es zu schätzen, dass die Leute manchmal wirklich keine Zeit haben, etwas beizutragen und sich dennoch wirklich wünschen, dass ein bestimmtes Feature passiert. Das ist in Ordnung. Ich würde nur sagen, dass Sie in diesem Szenario Empathie und Dankbarkeit für die Menschen anstreben, die ihre Zeit (und manchmal auch Geld) spenden, um Ihnen zu helfen weiter so, wie es ihnen möglich ist.

Aufrichtig,
Matthew Dean, Mitglied des Kernteams von Less.js

Ich unterstütze bereits meine eigenen Projekte und höre auf ihre Feature-Anfragen. Ich habe ehrlich gesagt keine Zeit, mich mit dem Kern von Less.js zu beschäftigen.

Für diejenigen, die hierher kommen, um Unterstützung für sass-Platzhalter (oder "stille Klasse") zu erhalten, lesen Sie diesen Kommentar . Es wird Sie nicht den ganzen Weg dorthin bringen (wegen #1851 und solche Klassen nicht in einer "referenzierten" Datei), aber es ist besser als nichts.