Less.js: Die Funktion data-uri verwendet den Pfad des Daten-uri-Aufrufs, nicht die Zeichenfolge mit dem Pfad zur Datei in.

Ich freue mich über Feedback, ob dies eine bahnbrechende Änderung (die eine größere Verbesserung rechtfertigt) oder eine Fehlerbehebung ist.

Zu Ihrer Information: Sie können dies elegant implementieren, ohne die Abwärtskompatibilität auf sehr einfache Weise zu beeinträchtigen.

Derzeit akzeptiert die data-uri() -Funktion einen Quoted -Baumknoten, der eine Zeichenfolge als Dateipfad enthält, und löst sie intern als URL gegen den Speicherort der Datei auf, in der sich der Funktionsaufruf befindet. Sie können die data-uri -Funktion überladen, um auch einen Url -Baumknoten zu akzeptieren, der eine tatsächliche URL enthält. Auf diese Weise sollte sich die URL an der Stelle normalisieren, an der die CSS-Funktion url() aufgerufen wird, und sollte in der Funktion data-uri() Less nicht mehr intern normalisiert werden.

Z.B

// app/content/button.less
button {
  .background(url("images/btn.jpg"));
}

@rjgotten

Für mich sieht es eher nach einer Problemumgehung als nach einer Lösung aus. Bei einer weiteren Iteration werden sie versuchen, Ausführlichkeit zu vermeiden, indem sie url in das Mixin verschieben, und das Problem tritt erneut auf. Das andere Problem besteht darin, dass der ursprüngliche Anwendungsfall, aus dem dieses Problem stammt (# 2541), häufig wie folgt verwendet wird:

// mixins.less
.background(@image) {
    background-image: data-uri("@{image}.jpg");
}
// app/content/button.less
button {
  .background("images/btn");
}

(Zum Beispiel für ein Schrift-Gesicht-Mixin als Beispiel sind es normalerweise mehrere woff , ttf , eot , eot?#iefix usw. Erweiterungen, die an denselben Dateinamen angehängt sind ). Und auf diese Weise ist auch das frühere url unmöglich.

@ siebenphasen-max

Dann denke ich nicht wirklich, dass es einen geeigneten Lösungszeitraum gibt. Sie benötigen eine Möglichkeit, den Kontext zu bestimmen, in den eine relative URL aufgelöst werden soll. Entweder nehmen Sie diesen Kontext aus den Dateiinformationen der Datei, die den Zeichenfolgenwert für die Funktion data-uri() hat, oder Sie machen den Grenzwert über die Funktion url() und die Funktion Url expliziter

Wenn Sie die Ersetzung von Pfadvariablen unterstützen möchten, werden die Dinge schnell schwierig, da Sie herausfinden müssen, wie die verschiedenen Teile des Pfads normalisiert werden müssen.

ZB wie normalisierst du so etwas wie:

// mixins.less
.background(@image) {
    background-image: data-uri("../../@{image}.jpg");
}
// app/content/button.less
button {
  .background("../images/btn");
}

Wie würden Sie die relative URL-Auflösung und die durch die Tokensubstitution gesteuerte Kombination dieser beiden Pfade kombinieren?

Ich nehme an, eine Option besteht darin, nur gegen die Datei aufzulösen, die die Zeichenfolge definiert, die ein Ersatztoken ersetzt, wenn sich das Ersatztoken an der Spitze des endgültigen URL-Werts befindet, der in ein url() oder data-uri() funktionieren und ignorieren Sie Fälle wie die oben genannten. Das scheint am logischsten.

Eine andere Lösung könnte darin bestehen, einige Pfadbehandlungsfunktionen einzuführen, um Pfade zu verbinden oder Dateierweiterungen hinzuzufügen / zu entfernen / zu bearbeiten (ähnlich wie die Funktion unit() für Dimensionen funktioniert?) Und die Dinge expliziter zu gestalten.

Z.B

// mixins.less
.background(@image) {
    background-image: data-uri(extension(<strong i="21">@image</strong>, "jpg"));
}
// app/content/button.less
button {
  .background(url("./images/btn"));
}

Für Ihr erstes Beispiel ist keine spezielle Normalisierung erforderlich. "../../@{image}.jpg" genau wie geschrieben auf "../../../images/btn.jpg" "../../@{image}.jpg" erweitert (und dann sind es bis zu data-uri , um den Pfad zu verarbeiten).
Und das zweite Beispiel ist nur ... eine Funktion zu stapeln, um eine Funktion zu umgehen, um eine Abwärtskompatibilität zu umgehen, mit ... was genau? _Wrong_ Dateipfade beim Aufrufen eines in einer anderen Datei definierten Mixins?

Wenn es "nur wie erwartet" _nur_ mit .background(url("images/btn.jpg")); funktionieren soll, wie unterscheidet es sich dann davon, einfach .background(data-uri("images/btn.jpg")); direkt ohne Änderungen zu schreiben? :) :)

Mit anderen Worten, was ich meine ist, dass, wenn dies behoben werden soll, es mit data-uri festgesetzt werden sollte, egal wie kaputt es sein könnte. (Ehrlich gesagt weiß ich nicht, was eine bessere Strategie wäre: a. Warten Sie auf weitere Berichte / Anfragen und ändern Sie sie dann (wenn es genug davon gibt) oder b. Ändern Sie sie früher, um mögliche Auswirkungen auf das Brechen zu minimieren.)

_{Mit anderen Worten, unter der Annahme, dass url und data-uri ursprünglich als austauschbar konzipiert wurden (dh data-uri ist nur eine spezielle Version von url (und wird zu CSS url kompiliert) ulr "so" (mit solchen Optionen) verhält, während sich data-uri "so" (mit data-uri(url()) , die auf " data-uri in einem Mixin und url _out_ davon mit --relative-urls: on "<- Bhrrrr ... :)}

Für mich sieht es eher nach einer Problemumgehung als nach einer Lösung aus. Bei einer weiteren Iteration werden sie versuchen, Ausführlichkeit zu vermeiden, indem sie die URL zum Mixin verschieben, und das Problem tritt erneut auf.

Ja ich stimme zu.

Ich versuche langsam, mehr Aufwand für eine v3-Version in weniger zu stecken und dies nur zu beheben.

Ich habe darüber nachgedacht, alle möglichen Dateipfade auszuarbeiten und sie einzeln auszuprobieren - obwohl das etwas unangenehm ist, wenn sich mehrere Dateien an verschiedenen Speicherorten befinden ... Ich glaube, ich stimme zu, dass es nicht möglich ist, dies für immer vollständig zu beheben, aber zumindest Wir können den Normalfall beheben.

Möglicherweise kann eine resolve() -Funktion helfen, aufgelöste URLs an Funktionen zu übergeben (aber wenn es sich nicht um einen vollständigen Pfad handelt, der nicht funktioniert, würde ein vollständiger Pfad funktionieren, wenn dies behoben wurde ...)

Tut mir leid, nur schnell Gedanken aufzuschreiben.

Dies ist nur eine kurze Anmerkung, aber wir werden das gleiche Problem beim Importieren mit variabler Interpolation haben.

Import mit variabler Interpolation.

Das ist sowohl interessant als auch beunruhigend.
Ist es ein tatsächlich unterstützter Anwendungsfall oder ein glücklicher Zufall?

@rjgotten Es wird unterstützt, jedoch ist die Unterstützung etwas eingeschränkt. Es wurde in # 410 verfolgt

Das funktioniert:

<strong i="8">@variable</strong>: "path.less";
<strong i="9">@import</strong> "@{variable}";

Das tut nicht:

.mixin(@variable) {
  <strong i="13">@import</strong> "@{variable}";
}

Bearbeiten: geändert, damit der Link funktioniert.

Ich bin nicht sicher, ob ich die Variablen @import in Mixins unterstützen möchte.
Die ganze Sache mit dem Variablenimport ist ein bisschen magisch und kann einen kontraintuitiven Code erzeugen. Ich würde das eher entmutigen.

Viele Diskussionen über Problemumgehung, vielleicht nur das eigentliche Problem beheben? Ist es nicht klar, dass Daten-URI relativ zu der zu verarbeitenden Datei sein sollte?

Im Moment habe ich eine Datei, die eine Referenz von einem anderen Pfad importiert, und sie beschwert sich immer noch über Daten-Uri. Zumindest muss das ein Fehler sein? Ich meine, wenn ich als Referenz importiere, sollte es nicht versuchen, die Pfade relativ zur aktuellen Datei neu zu schreiben.

@Ciantic

Ich meine, wenn ich als Referenz importiere, sollte es nicht versuchen, die Pfade relativ zur aktuellen Datei neu zu schreiben.

Basierend auf was genau? Was hat das mit reference zu tun?

Im Moment habe ich eine Datei, die eine Referenz von einem anderen Pfad importiert, und sie beschwert sich immer noch über Daten-Uri.

Es klingt wie das Gegenteil des obigen Problems. Könnten Sie weitere Details angeben? (zB Pfade der Import-, Import- und Datendateien etc.).

Styles.less

.something {
    background: data-uri("some.svg");
}

sub / test.less

<strong i="11">@import</strong> (reference) "../style.less";
.test {
    color: green;
}

Es kompiliert style.less, aber nicht test.less, da es versucht, data-uri relativ zu test.less zu verwenden.

Warum sollte der Referenzimport versuchen, die Pfade neu zu schreiben? Dies ist meiner Meinung nach nicht erforderlich, wenn Referenzen verwendet werden.

Ich würde erwarten, dass data-uri die Regeln zum Umschreiben von URLs in den Optionen befolgt. Natürlich ... schwer zu sagen, was das eigentlich mit Data-Uri bedeutet.

Im Allgemeinen sollte data-uri relativ zur "aufrufenden .less-Datei" aufgelöst werden. Im Fall eines Mixins sollte es sich also relativ zu dem Ort auflösen, an dem das Mixin aufgerufen wird, und nicht relativ zum Ort des Mixins. Das Mixin "mischt" diese Anweisungen ein und löst sie dann auf. Also @lukeapage Ich denke deine Interpretation ist richtig:

// app/content/button.less
button {
  .background("images/btn.jpg");
}

Es sollte nach btn.jpg bei app/content/images/ suchen. Wenn nicht, ist das ein Fehler, weil Mixins nicht so funktionieren sollten. Ich denke nicht, dass es eine "bahnbrechende Veränderung" ist, sondern eine Fehlerbehebung.

Das heißt ... Ich glaube nicht, dass es ein Problem bei der Lösung geben würde wie:

1. Versuch, relativ zum Anrufer aufzulösen.
2. Versuch, relativ zum Mixin aufzulösen.

Node.js versucht mehrere Pfade zur Auflösung. Solange die Auflösungsreihenfolge klar dokumentiert ist, können Sie die Erwartungen verwalten. Und es so zu machen würde bedeuten, dass wenn jemand sein .less to do Verhalten # 2 basiert hätte, es immer noch in fast allen, wenn nicht allen Fällen funktionieren würde.

@ Matthew-Dean
Im Allgemeinen sollte data-uri relativ zur "aufrufenden .less-Datei" aufgelöst werden. Im Fall eines Mixins sollte es sich also relativ zu dem Ort auflösen, an dem das Mixin aufgerufen wird, und nicht relativ zum Ort des Mixins. Das Mixin "mischt" diese Anweisungen ein und löst sie dann auf.

Sie könnten niemals dafür sorgen, dass dies auf eine Weise funktioniert, die im Allgemeinen für alle Anwendungsfälle korrekt ist.

Wie würden Sie beispielsweise parametrisierte URLs unterstützen, dh URLs mit Ersatz-Token, die gegen einen bekannten Basisordner aufgelöst werden sollten, wenn nur die Ersatz-Token gefüllt sind? In diesem Fall muss die Datei des Angerufenen erneut erstellt werden, nicht die Datei des Anrufers.

Ich hatte eine gewisse Offenbarung darüber, wie ich dies transparent beheben kann, ohne explizit url() an der Anrufstelle zu verwenden, was @ sieben-Phasen-max zu Recht als schlechte Idee bezeichnet hat (weil irgendwann jemand versuchen wird) Refactor es in den Mixin Call und brechen Dinge):

Wenn wörtliche Quoted -Knoten erstellt werden, behalten Sie deren Dateiinformationen bei. Verbreiten Sie diese Informationen durch Variablenzuweisungen, Mixin-Aufrufe usw. Jeder Quoted -Wert, der aus einer Anruferdatei stammt, wird, wenn er mit url() oder data-uri() , gegen diese Anruferdatei aufgelöst . Ein Quoted -Wert, der Teil einer internen Logik eines Mixins ist, wird jedoch immer noch anhand der lokalen Datei des Mixins aufgelöst.

Damit funktioniert alles wie erwartet, bis auf Szenarien mit Substitutionszeichenfolgen wie:

// mixins.less
.background(@image) {
    background-image: data-uri("@{image}.jpg");
}
// app/content/button.less
button {
  .background("images/btn");
}

Es gibt einen Trick, den Sie anwenden können, um diese ebenfalls zu beheben: Wenn sich beim Ausfüllen der Substitutionstoken ein Token ganz am Anfang der Substitutionszeichenfolge befindet, sollte die resultierende Zeichenfolge die Dateiinformationen von dem ausgefüllten Token erben und nicht von diesem der Substitutionszeichenfolge.

Wenn die Absicht des eigenen Autors des Mixins darin besteht, solche Pfade gegen die Mixin-Datei aufzulösen, können sie dies trotzdem tun, indem sie beispielsweise "./@{image}.jpg" als Muster verwenden. Dadurch wird die Last der Verantwortung effektiv vom Anrufer weg verlagert, was Sie möchten.

// _mixins.less
.sprite(@image) {
    background: data-uri("../images/sprites/@{image}.png") no-repeat;
}

// main.less
div {
   .sprite('logo');
}

Ausgabe:

div {
   background: url(data:image/png;base64,...) no-repeat;
}

Wow, das ist sehr alt ... meine zwei Cent, da dieses Problem mich auch betrifft.

Was ist mit dem Hinzufügen der Option zur URL-Funktion oder dem Erstellen einer neuen Funktion, die die URL als absolut löst? Auf diese Weise arbeitet das Mixin unabhängig davon, wo es eingestellt ist, mit absoluten Pfaden und ohne Raum für Fehler.

Was ist mit dem Hinzufügen der Option zur URL-Funktion oder dem Erstellen einer neuen Funktion, die die URL als absolut löst? Auf diese Weise arbeitet das Mixin unabhängig davon, wo es eingestellt ist, mit absoluten Pfaden und ohne Raum für Fehler.

Hier ging es nicht um absolute oder relative Pfade. Es ging um Verwandte gegen Anrufstelle gegen Verwandte gegen Deklarationsstelle. Ganz anderes Problem.

Vielleicht hat sich das Problem weiterentwickelt, aber der erste Kommentar und Titel handelt von der Daten-URL, die den Pfad in Bezug auf die Datei auflöst, in der sie aufgerufen wurde. In Kombination mit einem Mixin, das an einer anderen Stelle platziert ist, kann der Pfad möglicherweise falsch aufgelöst werden. Nun, das ist das Problem, das ich habe.

Wo also spielen absolute Pfade als Lösung eine Rolle?

Angenommen, data-uri akzeptiert absolute Pfade und es gibt eine hipotethische absolute-url -Funktion. Der folgende Code würde unabhängig davon funktionieren, wo sich das Mixin befindet.

// mixins.less
.background(@image) {
    background-image: data-uri(@image);
}

// app/content/button.less
button {
  .background(absolute-url("images/btn.jpg"));
}

@ miljan-aleksic Mit "absolut" meinen Sie relativ zur Datei am Speicherort von data-uri ? Wenn ja, ist "absolut" wahrscheinlich der falsche Begriff.

Es scheint jedoch ein guter Ansatz zu sein, wenn eine URL eine URL relativ zu einer Datei relativ macht. Oder ein zusätzliches Argument zu url ().

@ matthew-dean, mit absolut meine ich den vollständigen Pfad zur Datei, zB: /users/myuser/projects/lessproject/icon.svg .

Ich verstehe Ihren Ansatz nicht, da ich nicht sehe, wie url () einen relativen Pfad zur Daten-URI-Speicherortdatei erstellen kann, ohne die Ubikation zu kennen.

Es scheint jedoch ein guter Ansatz zu sein, wenn eine URL eine URL relativ zu einer Datei relativ macht. Oder ein zusätzliches Argument zu url ().

Lustig genug; Das habe ich vor ein paar Jahren fast vorgeschlagen. ;-);

Mit absolut meine ich den vollständigen Pfad zur Datei, z. B.: /users/myuser/projects/lessproject/icon.svg.

Es sieht so aus, als ob Sie mit absolut meinen, dass diese absolute-url -Funktion den relativen Pfad, der an einen vollständigen Ausgabepfad übergeben wird, basierend auf dem Speicherort der Datei, in der die absolute-url -Funktion aufgerufen wird, vorauflöst. relativ zu dem Speicherort, an den die kompilierte Ausgabe-CSS-Datei verschoben wird.

Dh ihr beide meint dasselbe. Wie ich damals.

Dies führt zu einem vollständigen Ausgabepfad, basierend auf dem Speicherort der Datei, in der die Absolut-URL-Funktion aufgerufen wird, relativ zu dem Speicherort, an dem die kompilierte Ausgabe-CSS-Datei gespeichert wird.

Wie in, URLs oder Rootpath neu schreiben würde immer noch gelten, aber die basierend auf dem Definitionsort? Das scheint ein wenig anders zu sein als das ursprüngliche Beispiel von @lukeapage , in dem es nicht um URLs im Verhältnis zur Ausgabe ging, sondern um URLs _während des Kompilierens_; zB der Ort data-uri() .

Daher ist dieses Problem etwas schwer zu verfolgen, da Leute über ähnliche, aber nicht genau identische Probleme geschrieben haben. Das heißt, das Ändern einer relativen Quelle würde wahrscheinlich eine ganz andere Lösung erfordern als das Ändern der relativen Ausgabe. Oder vielleicht auch nicht; es hängt von der Pfadlogik ab; aber wir sollten klar sein, dass data-uri keinen Pfad als Ausgabe erzeugt.

Vielleicht brauchen wir so etwas wie ein resolve() ? Ich weiß nicht, nur spucken, aber url(resolve(file(), "my/path")) ? Ich denke, das ist es, was @ miljan-aleksic mit absolute() meinte, da es sich in eine absolute URL auflösen würde. Aber es sollte immer noch eine Eingabe erforderlich sein (wie file() , um dagegen zu lösen). Andernfalls könnten Sie so etwas wie file-resolve() tun, um diese Logik in einer Funktion zu kennzeichnen, aber resolve() und file() als zwei Funktionen zu haben, könnte separat nützlich sein.

Der schwierige Teil bei all dem sind alle Optionen zum Umschreiben von URLs, von denen es ab der PR-Zusammenführung jetzt mehr gibt, die die Modulunterstützung hinzugefügt haben. (https://github.com/less/less.js/pull/3248). Wenn eine dateirelative URL zurückgegeben wird, kann sie dennoch neu geschrieben werden? Ich würde ja annehmen, aber wir müssten klar sein.

Ja, resolve () und file () definieren genau das, was ich erklären wollte. Ich hoffe, wir konnten dies in naher Zukunft umsetzen.

@ miljan-aleksic Okay, das macht dann Sinn.

Eigentlich ist file() nicht ganz richtig, da dies den Dateinamen zurückgeben würde, den ich annehmen würde, wäre es eher dir() . Und es sollte wahrscheinlich eine variable Konstante pro Datei sein.

Wie wäre es mit:

data-uri(resolve(<strong i="10">@DIR</strong>, "my/path"))

Es wurden also zwei Dinge hinzugefügt: 1) eine Auflösung () -Funktion zum Kombinieren von Pfaden, 2) eine Konstante @DIR (und @FILE ?), Die während der Auswertung in jede Datei eingefügt wird. Das einzig schwierige daran wäre, zu testen, ob diese injizierten Vars nicht überschreiben oder mit anderen Vars in der Wurzel zusammengeführt werden, aber das sollte ziemlich einfach zu testen sein. Oder sollten sie klein geschrieben sein, wie @arguments ? In diesem Fall würde ich @directory und @filename vorschlagen, um Konflikte zu vermeiden. Was ist die Less-y-Option am meisten?

Vielleicht brauchen wir so etwas wie ein resolve() ?

^ Bingo. Genau das.

Was ist die Less-y-Option am meisten?

Ich würde mich für die Option Node.js-y entscheiden: __dirname
Es gibt es schon lange und es ist bekannt. Es könnte eine gute Idee sein, in Less denselben Namen für dasselbe Konzept zu verwenden.

Ich würde mich für die Option Node.js-y entscheiden: __dirname

Ähm ... das würde weder mit dem Schlüsselwort Less / CSS noch mit der Semantik von Less Variable oder Funktion übereinstimmen. Wir müssten es besser machen. @__dirname vielleicht, aber die Unterstriche sind für die Sprache immer noch etwas seltsam. Es passt überhaupt nicht.

Die Unterstriche sind für die Sprache immer noch etwas seltsam. Es passt überhaupt nicht.

Ein doppelt führender Unterstrich wird verwendet, um in vielen Sprachen anzugeben, was das System bietet, insbesondere wenn es um Dinge wie intrinsische Variablen geht. Die Unanständigkeit ist also eine Art Punkt dort.

Natürlich; Wenn Sie es nicht mögen, können Sie immer mit einem Derivat wie @dirname oder @dir-name .

Nachdem wir darüber nachgedacht haben, warum brauchen wir überhaupt den aktuellen Dateipfad, der als Variable verfügbar gemacht wird? Kann es nicht in die konzeptionelle resolve() -Funktion selbst eingewebt werden?

Kann es nicht in die konzeptionelle Auflösung () -Funktion selbst eingewebt werden?

Und wir sind auf meinen Vorschlag zurückgekommen, nur mit einem anderen Funktionsnamen. Ich mag es immer noch am meisten, noch besser als Entschlossenheit ().

Und wir sind auf meinen Vorschlag zurückgekommen, nur mit einem anderen Funktionsnamen.

Art von.

Was ich damit sagen will ist, dass afaik es nicht notwendig ist, die URL / den Pfad der Datei, die den Aufruf enthält, an eine resolve() -Funktion zu übergeben, da dieser Speicherort der Funktion _bekannt_ sein sollte.

this in einer Funktion bezieht sich auf eine FunctionCaller -Instanz mit einer currentFileInfo -Eigenschaft.
Diese Eigenschaft wird mit den Dateiinformationen des Call AST-Knotens initialisiert, der dem Funktionsaufruf entspricht.
Dh

https://github.com/less/less.js/blob/4e903e8254cc20fec80fccd35794fb797949e653/lib/less/tree/call.js#L47

Wenn ich den Code richtig lese, entspricht die Dateiinfo dort der Dateiinfo des Ortes, an dem der Funktionsaufruf _declared_ ist - nicht der Datei, in der der Funktionsaufruf ausgewertet wird.

Das heißt, es sollte in Ordnung sein, diese Dateiinformationen für einen "eifrigen" URL-Resolver zu verwenden. Es würde sich wie erwartet verhalten, selbst wenn ein Funktionsaufruf in einem Mixin platziert wird, das im Kontext einer anderen Datei importiert und ausgewertet wird. Nämlich: mit der Auflösung, die an die Datei angeheftet ist, in der das Mixin definiert ist.

Nachdem wir darüber nachgedacht haben, warum brauchen wir überhaupt den aktuellen Dateipfad, der als Variable verfügbar gemacht wird? Kann es nicht in die konzeptionelle Auflösung () -Funktion selbst eingewebt werden?

Wenn wir sicher sind, dass niemand die aktuelle Datei oder eine allgemeine Resolver-Funktion benötigt ... vielleicht ... macht die Sache eine explizite lokale Variable, die klar macht, dass es sich nicht um eine generische Funktion handelt und dass die Funktion nicht wie folgt ausgewertet wird jede andere Funktion. Das ist meine eigentliche Sorge, ist die Semantik. Egal wie Sie es nennen, wenn Sie keinen speziellen "Marker" für "aktuelle Datei" haben, ist es nicht wie jede andere Funktion, die aufgrund von Eingaben gleich aufgelöst wird. Mit anderen Worten, es ist eine Funktion, die nach unsichtbaren Eingaben aufgelöst wird und die mich betrifft. Wenn die Funktion jedoch extrem explizit ist, wie current-file-resolve() , ist das vielleicht klar genug. Andernfalls werden Sie die Leute nur verwirren, warum ein Mixin-Aufruf specialfunction() gemäß der Datei aufgelöst hat, in der er aufgerufen wurde, anstatt mit der Datei, in der das Mixin definiert wurde.

Also, nein, eine lokale Variable ist technisch nicht erforderlich, aber die Bedeutung / Ausgabe / das Verhalten muss aus der Semantik klar sein.

hmm ...

OK. Wie wäre es dann mit einer resolve-url(url, [base]) -Funktion - mit einer optionalen base ; Standardmäßig wird das Verzeichnis der Datei verwendet, in der der Funktionsaufruf geschrieben / deklariert / definiert ist. Dann haben Sie eine declared-dir() -Funktion, die nur this.fileInfo zieht und den Pfad erfasst, falls Autoren den Pfad explizit abrufen möchten. möchte einen Pfad aus einer anderen Datei nehmen; oder müssen dies als Teil einer anderen Funktion verwenden, die nicht mit der URL-Auflösung zusammenhängt.

Dh ein vollständiger Formularaufruf (ohne implizite Basis) wäre ungefähr so:

resolve-url("../foo", declared-dir())

... und wäre gleichbedeutend damit, es einfach zu tun

resolve-url("../foo")

... was das eifrige Äquivalent zum Faulen ist

url("../foo")

Auf diese Weise werden keine "automatisch" injizierten Variablen benötigt. Dies könnte meiner Meinung nach nur als eine Reihe von Plugin-Funktionen implementiert werden. Und die einzige Kernmechanik, die wir benötigen, ist eine Möglichkeit, URLs als "bereits aufgelöst" zu markieren, damit die Standard-Resolver-Logik für URLs blockiert werden kann, die aus der resolve-url -Funktion stammen.

Die Semantik sollte in der Dokumentation des Kurses klargestellt werden. Und diese Dokumentation kann url explizit mit resolve-url , um die eifrige und faule Bewertung / Auflösung zu veranschaulichen.

_{Nur für den Fall, dass die Idee "injizierte Variablen" ohnehin nicht funktioniert (ohne zusätzliche Hacks), da importierte Dateien den gleichen Umfang haben.}

<strong i="7">@__dir</strong>: "whatever";
// *everywhere* it's the only <strong i="8">@__dir</strong> value = the path of "c"
<strong i="9">@import</strong> "a";
<strong i="10">@import</strong> "b";
<strong i="11">@import</strong> "c";

In Bezug auf die funktionsbasierte Implementierung denke ich (kann aber nicht sicher sein), dass es immer noch möglich ist, den Pfad der Datei abzurufen, in der die Funktion irgendwo in ihrem this.context.? oder this.context.frames[?] aufgerufen wird oder so.

emmmm, also haben wir keinen besseren Weg, um es zu lösen?

@heynext
emmmm, also haben wir keinen besseren Weg, um es zu lösen?

Eine faule Bewertung macht es sehr schwer, dies richtig zu lösen, fürchte ich.

@ siebenphasen-max
In Bezug auf die funktionsbasierte Implementierung denke ich (kann aber nicht sicher sein), dass es immer noch möglich ist, den Pfad der Datei abzurufen, in der die Funktion irgendwo in ihrem this.context.? oder this.context.frames[?] aufgerufen wird oder so.

Sie sollten in der Lage sein, den Knoten Call in seiner Hierarchie zu finden, ja.