Less.js: La fonction data-uri utilise le chemin de l'appel data-uri, pas la chaîne avec le chemin du fichier dans.

Je suis heureux de recevoir des commentaires sur la question de savoir s'il s'agit d'un changement de rupture (justifiant une augmentation majeure) ou d'une correction de bogue.

FYI: Vous pouvez mettre en œuvre élégamment cela sans rompre la rétrocompatibilité d'une manière très simple.

Actuellement, la fonction data-uri() accepte un nœud d'arbre Quoted contenant une chaîne comme chemin du fichier et le résout en interne comme une URL par rapport à l'emplacement du fichier contenant l'appel de fonction. Vous pouvez surcharger la fonction data-uri pour accepter également un nœud d'arbre Url contenant une URL réelle. De cette façon, l'URL devrait se normaliser par rapport à l'emplacement où la fonction url() CSS est appelée et ne devrait plus être normalisée en interne dans la fonction data-uri() Less.

Par exemple

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

@rjgotten

Pour moi, cela ressemble plus à une solution de contournement qu'à un correctif. Lors d'une itération ultérieure, ils _ essaieront_ d'éviter la verbosité en déplaçant url vers le mixin et le problème reviendra. L'autre problème est qu'en prenant le cas d'utilisation d'origine d'où ce problème vient (# 2541), il est souvent utilisé comme ceci:

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

(Par exemple, pour un mixin font-face, par exemple, il s'agit généralement de plusieurs extensions woff , ttf , eot , eot?#iefix etc. ajoutées au même nom de fichier ). Et de cette façon, le url antérieur est également impossible.

@ sept-phases-max

Ensuite, je ne pense pas vraiment qu'il y ait une période de solution appropriée. Vous avez besoin d'un moyen de déterminer le contexte dans lequel une URL relative doit être résolue. Soit vous prenez ce contexte à partir des informations de fichier du fichier qui a défini la valeur de chaîne entrant dans la fonction data-uri() , soit vous rendez le point de coupure plus explicite via la fonction url() et la fonction Url nœud d'arbre.

Si vous souhaitez prendre en charge la substitution de variable de chemin, les choses deviennent rapidement délicates car vous devez comprendre comment les différentes parties du chemin doivent être normalisées.

Par exemple, comment normaliser quelque chose comme:

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

Comment combineriez-vous la résolution relative des URL et la combinaison de ces deux chemins, basée sur la substitution de jetons?

Je suppose qu'une option consiste à résoudre uniquement le fichier définissant la chaîne qui est substituée à un jeton de remplacement, lorsque le jeton de remplacement est à la tête de la valeur de l'URL finale allant dans un url() ou data-uri() fonction et ignorez les cas comme ci-dessus. Cela semble le plus logique.

Une autre solution pourrait être d'introduire des fonctions de gestion des chemins pour joindre des chemins ou d'ajouter / supprimer / éditer des extensions de fichier (similaire au fonctionnement de la fonction unit() pour les dimensions, peut-être?) Et rendre les choses plus explicites.

Par exemple

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

Pour votre premier exemple, il n'a besoin d'aucune normalisation spéciale, "../../@{image}.jpg" développe en "../../../images/btn.jpg" juste comme il est écrit (et puis c'est jusqu'à data-uri pour gérer le chemin).
Et le deuxième exemple est juste ... empiler une fonction pour contourner une fonction pour contourner une rétrocompatibilité avec ... quoi exactement? _Wrong_ chemins de fichiers lors de l'appel d'un mixin défini dans un autre fichier?

Après tout, si cela est censé fonctionner "comme prévu" _uniquement_ avec .background(url("images/btn.jpg")); , en quoi est-ce différent d'écrire simplement .background(data-uri("images/btn.jpg")); directement sans aucun changement? :)

En d'autres termes, ce que je veux dire, c'est que si cela doit être corrigé, alors il devrait être corrigé avec data-uri peu importe à quel point cela pourrait être cassant. (Honnêtement, je ne sais pas quelle serait une meilleure stratégie: a. Attendez plus de rapports / demandes pour cela, puis (s'il y en a suffisamment) changez ou b. Modifiez-la plus tôt pour minimiser l'impact de rupture possible).

_{En d'autres termes, en supposant que url et data-uri ont été initialement conçus comme interchangeables (c'est- data-uri dire que url (et se compile en CSS url à la fin)), il serait assez pénible de décrire pourquoi exactement ulr se comporte "comme ça" (avec des options comme ça) alors que data-uri se comporte "comme ça" (avec options comme celle-ci), et pour obtenir un certain comportement, vous aurez besoin de data-uri(url()) combo, limité à " data-uri dans un mixin et url _out_ avec --relative-urls: on "<- Bhrrrr ... :)}

Pour moi, cela ressemble plus à une solution de contournement qu'à un correctif. Lors d'une itération ultérieure, ils essaieront d'éviter la verbosité en déplaçant l'URL vers le mixin et le problème reviendra.

Oui je suis d'accord.

J'essaie lentement de mettre plus d'efforts en moins pour une version v3 et de corriger cela.

Je pensais travailler sur tous les chemins de fichiers possibles et les essayer un par un - bien que ce soit un peu désagréable s'il y a plusieurs fichiers à différents endroits ... Je pense que je suis d'accord qu'il n'est pas possible de résoudre complètement cela pour toujours, mais au moins nous pouvons réparer le cas normal.

Peut-être qu'une fonction resolve() pourrait aider à transmettre des URL résolues aux fonctions (mais si ce n'est pas un chemin complet qui ne fonctionnerait pas et un chemin complet fonctionnerait lorsque cela a été corrigé ...)

Désolé juste de noter rapidement ses pensées.

Ceci est juste une note rapide, mais nous aurons le même problème avec l'importation en utilisant l'interpolation variable.

importer à l'aide d'une interpolation variable.

C'est à la fois intéressant et troublant.
S'agit-il d'un cas d'utilisation réellement pris en charge ou d'une heureuse coïncidence?

@rjgotten Il est pris en charge, mais le support est quelque peu limité. Il a été suivi dans # 410

Cela marche:

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

Cela ne fait pas:

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

Edit: modifié pour que le lien fonctionne.

Je ne suis pas sûr de vouloir prendre en charge les variables @import dans les mixins.
L'ensemble de l'importation de variables est un peu magique et peut créer du code contre-intuitif ... donc je préfère décourager cela.

Beaucoup de discussions sur la solution de contournement, peut-être simplement résoudre le problème réel? N'est-il pas clair que data-uri doit être relatif au fichier en cours de traitement.

En ce moment, j'ai un fichier qui importe une _une référence_ d'un autre chemin, et il se plaint toujours de data-uri. Au moins ça doit être un bug? Je veux dire que si j'importe par référence, il ne devrait pas essayer de réécrire les chemins par rapport au fichier actuel.

@Ciantic

Je veux dire que si j'importe par référence, il ne devrait pas essayer de réécrire les chemins par rapport au fichier actuel.

Basé sur quoi exactement? Qu'est-ce que cela a à voir avec reference ?

En ce moment, j'ai un fichier qui importe une référence d'un autre chemin, et il se plaint toujours de data-uri.

Cela ressemble à l'opposé du problème ci-dessus. Pouvez-vous fournir plus de détails? (par exemple, chemins des fichiers d'importation, importés et de données, etc.).

styles sans

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

sous / test.less

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

Il compile style.less, mais pas test.less car il essaie d'utiliser data-uri par rapport à test.less.

Pourquoi l'importation de références essaierait-elle de réécrire les chemins, ce n'est pas nécessaire à mon avis lors de l'utilisation de références.

Je m'attendrais à ce que data-uri suive les règles de réécriture d'url dans les options. Bien sûr ... difficile de dire ce que cela signifie réellement avec data-uri.

En général, data-uri doit être résolu par rapport au "fichier .less appelant". Donc, dans le cas d'un mixin, il devrait être résolu par rapport à l'endroit où le mixin est appelé, et non par rapport à l'emplacement du mixin. Le mixin «mélange» ces déclarations et les résout ensuite. Donc @lukeapage, je pense que votre interprétation est correcte:

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

Il devrait rechercher btn.jpg à app/content/images/ . Si ce n'est pas le cas, c'est un bug car ce n'est pas ainsi que les mixins devraient fonctionner. Je ne pense pas que ce soit un "changement de rupture" mais une correction de bogue.

Cela dit ... je ne pense pas qu'il y aurait un problème avec une résolution comme:

1. Tentative de résolution relative à l'appelant.
2. Tentative de résolution par rapport au mixin.

Node.js tente plusieurs chemins pour la résolution. Tant que l'ordre de résolution est clairement documenté, vous pouvez gérer les attentes. Et faire comme ça signifierait que si quelqu'un avait basé son .less to do behavior # 2, cela fonctionnerait toujours dans presque tous, sinon tous les cas.

@ matthew-doyen
En général, data-uri doit être résolu par rapport au "fichier .less appelant". Donc, dans le cas d'un mixin, il devrait être résolu par rapport à l'endroit où le mixin est appelé, et non par rapport à l'emplacement du mixin. Le mixin «mélange» ces déclarations et les résout ensuite.

Vous ne pourriez jamais faire en sorte que cela fonctionne d'une manière généralement correcte pour tous les cas d'utilisation.

Par exemple, comment supporteriez-vous les URL paramétrées, c'est-à-dire les URL avec des jetons de remplacement, qui devraient être résolues par rapport à un dossier de base connu avec juste les jetons de remplacement remplis? Ce cas nécessite un resovling par rapport au fichier de l'appelé, pas au fichier de l'appelant.

J'ai eu une petite révélation sur la façon de résoudre ce problème de manière transparente sans utilisation explicite de url() sur le site d'appel, ce que @ seven-phases-max a légitimement qualifié de mauvaise idée (parce que quelqu'un _will_ essaiera éventuellement de le refactoriser dans l'appel mixin et casser les choses):

Lorsque des nœuds littéraux Quoted sont créés, conservez leurs informations de fichier. Propager cette information par le biais des affectations de variables, les appels mixins, etc. Tous Quoted valeur provenant d'un fichier appelant serait, lorsqu'ils sont traités par url() ou data-uri() , être résolu contre ce fichier de l' appelant . Mais une Quoted qui fait partie d'une logique interne d'un mixin est toujours résolue par rapport au fichier local du mixin.

Cela permet que tout fonctionne comme prévu, sauf pour les scénarios avec des chaînes de substitution telles que dans:

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

Il y a une astuce que vous pouvez utiliser pour les corriger également: lorsque vous remplissez les jetons de substitution, si un jeton est au tout début de la chaîne de substitution, la chaîne résultante devrait hériter des informations de fichier du jeton rempli, plutôt que cela de la chaîne de substitution.

Si l'intention du propre auteur du mixin est de résoudre ces chemins par rapport au fichier mixin, il peut toujours le faire fonctionner en utilisant, par exemple, "./@{image}.jpg" comme motif. Cela déplace efficacement le fardeau de la responsabilité de l'appelant, ce que vous voudriez.

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

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

production:

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

Wow, c'est une question très ancienne ... Mes deux cents car cette question m'affecte également.

Qu'en est-il de l'ajout de l'option à la fonction url, ou de la création d'une nouvelle fonction, qui résoudra l'url comme absolue. De cette façon, peu importe où le mixin est défini, il fonctionnera avec des chemins absolus et aucune marge d'erreur.

Qu'en est-il de l'ajout de l'option à la fonction url, ou de la création d'une nouvelle fonction, qui résoudra l'url comme absolue. De cette façon, peu importe où le mixin est défini, il fonctionnera avec des chemins absolus et aucune marge d'erreur.

Le problème ici ne concernait pas les chemins absolus ou relatifs. Il s'agissait d'un rapport relatif au site d'appel vs relatif au site de déclaration. Problème totalement différent.

Le problème a peut-être évolué, mais le commentaire initial et le titre concernent la résolution du chemin d'accès par rapport au fichier où il a été appelé, qui, combinée à un mixin placé ailleurs, peut résoudre le chemin de manière incorrecte. Eh bien, c'est le problème que je rencontre.

Alors, où les chemins absolus sont-ils pris en compte en tant que solution?

En supposant que data-uri accepte les chemins absolus et qu'il existe une fonction absolute-url hipotethical, le code suivant fonctionnerait peu importe où le mixin est placé.

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

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

@ miljan-aleksic Par "absolu", voulez-vous dire relatif au fichier à l'emplacement de data-uri ? Si tel est le cas, «absolu» est probablement le mauvais terme.

Il semble cependant qu'un wrapper fonctionnel pour une URL afin de rendre toute URL relative à un fichier est une bonne approche. Ou un argument supplémentaire à url ().

@ matthew-dean, par absolu, je veux dire le chemin complet vers le fichier, par exemple: /users/myuser/projects/lessproject/icon.svg .

Je ne comprends pas votre approche car je ne vois pas comment url () pourrait créer un chemin relatif vers le fichier de localisation data-uri sans le savoir.

Il semble cependant qu'un wrapper fonctionnel pour une URL afin de rendre toute URL relative à un fichier est une bonne approche. Ou un argument supplémentaire à url ().

Assez amusant; c'est presque ce que j'ai suggéré il y a quelques années. ;-)

par absolu, je veux dire le chemin complet vers le fichier, par exemple: /users/myuser/projects/lessproject/icon.svg.

Il semble qu'avec absolu, vous voulez dire que cette fonction absolute-url _pré-résout_ le chemin relatif qui lui est passé à un chemin de sortie complet, en fonction de l'emplacement du fichier dans lequel la fonction absolute-url est appelée, par rapport à l'emplacement où le fichier CSS de sortie compilé ira.

C'est-à-dire que vous entendez tous les deux la même chose. Tout comme moi, à l'époque.

vers un chemin de sortie complet, basé sur l'emplacement du fichier dans lequel la fonction absolu-url est appelée, par rapport à l'emplacement où le fichier CSS de sortie compilé ira.

Comme dans, réécrire les URL ou le chemin racine s'appliquerait toujours, mais en fonction de l'emplacement de la définition? Cela semble un peu différent de l'exemple original de @lukeapage , qui ne parlait pas d'URL par rapport à la sortie, mais d'URL _durant la compilation_; par exemple, l'emplacement data-uri() .

Ce problème est donc un peu difficile à suivre car des gens ont publié des articles sur des problèmes similaires, mais pas exactement identiques. Autrement dit, la modification d'une _source_ relative nécessiterait probablement une solution bien différente de celle d'une _source_ relative. Ou peut-être pas; cela dépend de la logique de cheminement; mais nous devons être clairs que data-uri ne produit aucun chemin en sortie.

Peut-être avons-nous besoin de quelque chose comme un resolve() ? Je ne sais pas, je crache juste, mais url(resolve(file(), "my/path")) ? Je suppose que c'est ce que @ miljan-aleksic voulait dire par absolute() , en ce sens qu'il se résoudrait en une URL absolue. Mais cela devrait toujours prendre une entrée (comme file() , pour résoudre le problème). Sinon, vous pouvez faire quelque chose comme file-resolve() pour désigner cette logique dans une fonction, mais avoir resolve() et file() comme deux fonctions peut être utile séparément.

La partie délicate de tout cela est toutes les options de réécriture d'URL, dont il y en a maintenant plus à partir de la fusion PR qui a ajouté la prise en charge du module. (https://github.com/less/less.js/pull/3248). Donc, s'il renvoie une URL relative au fichier, peut-il encore être réécrit? Je suppose que oui, mais il faudrait être clair.

Oui, résoudre () et file () définissent exactement ce que j'essayais d'expliquer. J'espère que nous pourrons voir cela mis en œuvre dans un avenir proche.

@ miljan-aleksic D'accord, c'est logique alors.

En fait, file() n'est pas tout à fait correct, puisque cela renverrait le nom de fichier que je suppose, ce serait plutôt dir() . Et cela devrait probablement être une constante variable par fichier.

Qu'en est-il de:

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

Donc, deux choses ont été ajoutées: 1) une fonction resolver () pour combiner les chemins, 2) une constante @DIR (et @FILE ?) Injectée dans chaque fichier lors de l'évaluation. La seule chose délicate à ce sujet serait de vérifier que ces variables injectées ne remplacent pas ou ne fusionnent pas avec d'autres variables à la racine, mais cela devrait être assez simple à tester. Ou devraient-ils être en minuscules, comme @arguments ? Dans ce cas, je suggérerais @directory et @filename pour éviter les conflits. Quelle est l'option la moins-y?

Peut-être avons-nous besoin de quelque chose comme un resolve() ?

^ Bingo. Exactement ça.

Quelle est l'option la moins-y?

J'irais pour l'option Node.js-y: __dirname
Il existe depuis longtemps et est bien connu. Utiliser le même nom pour le même concept dans Less pourrait être une bonne idée.

Je choisirais l'option Node.js-y: __dirname

Err ... qui ne correspondrait pas au mot-clé Less / CSS, ni à la variable Less, ni à la sémantique de la fonction. Il faudrait faire mieux que ça. @__dirname peut-être, mais les traits de soulignement sont encore un peu bizarres pour la langue. Ça ne va pas du tout.

les traits de soulignement sont encore un peu bizarres pour la langue. Ça ne va pas du tout.

Un double trait de soulignement est utilisé pour indiquer «quelque chose que le système fournit» dans de nombreux langages, surtout lorsqu'il s'agit de choses comme les variables intrinsèques. Donc, le manque de placidité est un peu le point ici.

Bien sûr; si vous ne l'aimez pas, vous pouvez toujours utiliser un dérivé comme @dirname ou @dir-name .

Cependant, après y avoir réfléchi un peu plus, pourquoi avons-nous même besoin du chemin du fichier actuel exposé en tant que variable? Ne peut-il pas être intégré à la fonction conceptuelle resolve() elle-même?

Ne peut-il pas être intégré à la fonction conceptuelle de resolution () elle-même?

Et nous sommes revenus à ma proposition, juste avec un nom de fonction différent. Je l'aime toujours le plus, encore mieux que la résolution ().

Et nous sommes revenus à ma proposition, juste avec un nom de fonction différent.

Sorte de.

Ce à quoi je veux en venir, c'est qu'il n'est pas nécessaire de transmettre l'URL / le chemin du fichier contenant l'appel à une fonction resolve() , car cet emplacement devrait être _connu_ à la fonction.

this intérieur d'une fonction fait référence à une instance FunctionCaller , qui a une propriété currentFileInfo .
Cette propriété est initialisée aux informations de fichier du nœud Call AST correspondant à l'appel de fonction.
C'est à dire

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

Si je lis correctement le code, les informations de fichier correspondent aux informations de fichier de l'endroit où l'appel de fonction est _déclaré_ - et non du fichier où l'appel de fonction est évalué.

Cela signifie qu'il devrait être acceptable d'utiliser ces informations de fichier pour un résolveur d'URL «impatient». Il agirait comme prévu, même si un appel de fonction est placé dans un mixin importé et évalué dans le contexte d'un autre fichier. À savoir: avec la résolution épinglée sur le fichier où le mixin est défini.

Cependant, après y avoir réfléchi un peu plus, pourquoi avons-nous même besoin du chemin du fichier actuel exposé en tant que variable? Ne peut-il pas être intégré à la fonction conceptuelle de resolution () elle-même?

Si nous sommes sûrs que personne n'a besoin du fichier actuel ou d'une fonction de résolution générale ... peut-être ... la chose est une var locale explicite indique clairement que ce n'est pas une fonction générique, et que la fonction ne sera pas évaluée comme toute autre fonction. C'est ma vraie préoccupation, c'est la sémantique. Peu importe le nom que vous lui donnez, si vous n'avez pas de "marqueur" spécial pour le "fichier courant", alors ce n'est pas comme toute autre fonction qui est résolue de la même manière en fonction des entrées. En d'autres termes, c'est une fonction qui se résout en fonction d'entrées invisibles, et cela me préoccupe. Cependant, si la fonction est quelque chose d'extrêmement explicite comme current-file-resolve() , c'est peut-être assez clair. Sinon, vous allez simplement confondre les gens pourquoi un appel mixin n'a pas résolu specialfunction() fonction du fichier dans lequel il a été appelé, au lieu du fichier dans lequel le mixin a été défini.

Donc, non, une variable locale n'est techniquement pas nécessaire, mais le sens / la sortie / le comportement doit être clair dans la sémantique.

Hmm...

D'accord. Alors que diriez-vous nous avons une fonction resolve-url(url, [base]) - avec une option base ; par défaut dans le répertoire du fichier dans lequel l'appel de fonction est écrit / déclaré / défini. Ensuite, ayez une fonction declared-dir() qui tire juste this.fileInfo et saisit le chemin, si les auteurs veulent tirer le chemin explicitement; voulez prendre un chemin à partir d'un fichier différent; ou besoin de l'utiliser dans le cadre d'une autre fonctionnalité non liée à la résolution d'URL.

Ie un appel de forme complète (sans base implicite) serait quelque chose comme:

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

... et équivaudrait à simplement faire

resolve-url("../foo")

... qui est l'équivalent impatient du paresseux

url("../foo")

Aucune variable injectée «automatiquement» n'est nécessaire de cette façon. Cela pourrait être mis en œuvre uniquement comme un ensemble de fonctions de plugin, je pense. Et le seul mécanisme de base dont nous avons besoin est un moyen de marquer les URL comme `` déjà résolues '', de sorte que la logique de résolution par défaut puisse être empêchée de s'exécuter sur les URL qui sortent de la fonction resolve-url .

La sémantique doit être clarifiée dans la documentation ofcourse. Et cette documentation peut comparer explicitement url à resolve-url pour illustrer l'évaluation / résolution impatiente et paresseuse.

_{Juste au cas où l'idée de "variables injectées" ne fonctionnerait pas (sans hacks supplémentaires) de toute façon parce que les fichiers importés ont la même portée.}

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

En parlant de l'implémentation basée sur la fonction, je pense (mais je ne peux pas être sûr) qu'il est toujours possible d'obtenir le chemin du fichier où la fonction est appelée quelque part dans son this.context.? ou this.context.frames[?] ou alors.

emmmm, nous n'avons donc pas de meilleur moyen de le résoudre?

@heynext
emmmm, nous n'avons donc pas de meilleur moyen de le résoudre?

Une évaluation paresseuse rend cela très difficile à résoudre correctement, j'en ai bien peur.

@ sept-phases-max
En parlant de l'implémentation basée sur la fonction, je pense (mais je ne peux pas être sûr) qu'il est toujours possible d'obtenir le chemin du fichier où la fonction est appelée quelque part dans son this.context.? ou this.context.frames[?] ou alors.

Vous devriez pouvoir trouver le nœud Call dans sa hiérarchie, oui.