Less.js: Autoriser les gardes à travailler avec des variables indéfinies

+1
Cela pourrait également être utilisé pour définir des couleurs de base sur les bibliothèques.
Imaginez le cas suivant :
Vous avez un fichier less pour une application spécifique, par exemple le menu principal d'un site Web.
Vous importez ce fichier less dans le fichier less principal, où vos couleurs de base sont définies comme des variables.
Maintenant, si vous utilisez ces couleurs de base dans le fichier less du menu principal, elles dépendent du fichier principal.
Si vous pouviez vérifier l'existence des variables, vous pourriez revenir aux couleurs définies par le module.
Voici un exemple de la façon dont j'imagine le fichier sans menu :

@menu-base-color: white;
@menu-base-color: @base-color when (@base-color);
...or...
@menu-base-color: @base-color when isset(@base-color);

+1, nous avons déjà istext , isnumber ayant isdefined et isundefined aidera grandement à thématiser avec moins.

Par exemple, utilisez value ou userValue si isdefined

Je rencontre souvent ce problème lorsque j'essaie de configurer des conventions de thème pour l'interface utilisateur sémantique avec MOINS.

+1 à ce sujet - serait vraiment génial.

+1 pour moi aussi

Ce n'est pas grave d'ajouter la fonction is-defined (je m'attends à ce qu'elle apparaisse dans l'un des premiers plugins dès la sortie de la v2). Bien que pour être honnête, le plus triste est que ceux qui veulent cette fonctionnalité manquent vraiment le fait que les deux cas d'utilisation ci-dessus peuvent être résolus (dans de nombreux cas, même avec un code plus compact) sans aucune fonctionnalité de ce type.

Cas d'utilisation de @InitArt :

// library.less
<strong i="9">@variable</strong>: false;

a when (@variable) {
    color: red;
}

// ......................................
// user.less
<strong i="10">@import</strong> "library.less"
<strong i="11">@variable</strong>: true;

Cas d'utilisation de @nemesis13 :

// library.less
@base-color: green;
@menu-base-color: @base-color;

.menu {
    background-color: @menu-base-color;
}

// ......................................
// user.less
<strong i="16">@import</strong> "library.less"
@base-color: white;
// or:
@menu-base-color: black;
// or whatever...

C'est-à-dire en résumé : au lieu de tester si une variable est définie, fournissez simplement une valeur par défaut pour cette variable, car les valeurs des variables sont librement remplaçables.

Quelqu'un peut-il répondre pourquoi l'exemple de max n'est pas faisable pour eux? je peux seulement
supposons que c'est parce que vous ne savez pas si la variable est définie ci-dessus ou
en dessous de l'import ? Ou s'agit-il d'autre chose?
Nous n'allons pas considérer quelque chose qui n'a pas de cas d'utilisation.
L'inconvénient de faire cela est que les gens qui tapent mal une variable ne verront pas un
Erreur. Nous pourrions contourner ce problème avec un avertissement, mais si vous l'avez fait sur
mais vous ne voudriez pas d'avertissement .. c'est mon seul problème avec ça
suggestion.

Ceci est particulièrement utile lors de la définition de thèmes afin de réduire la taille du CSS résultant. Lors de la création de thèmes en général, on souhaite activer la définition de nombreuses propriétés. Cependant, les utilisateurs peuvent vouloir définir uniquement certaines d'entre elles en laissant le reste des propriétés non définies. Bien sûr, les définir sur des valeurs par défaut fonctionnerait en général, cependant, cela gonfle le CSS final.

Considérez le thème de base suivant (modèle):

.my-class {
    color: @text-color;
    background-color: @background-color;
    border-color: @border-color;
}

L'utilisateur du thème peut souhaiter définir uniquement la couleur du texte en laissant le reste des propriétés non définies. Il est bien sûr possible de définir les valeurs sur "initial", "transparent", "inherit", etc., cependant, cela augmente la taille du CSS final. Les thèmes ont tendance à avoir des centaines de propriétés de ce type, de sorte que la taille peut augmenter considérablement.

@JechoJekov

Je pense que vous manquez le point de cette demande de fonctionnalité, notez que pour votre cas d'utilisation, vous devrez toujours mettre la garde pour chacune de ces propriétés (d'où la justification que j'ai suggérée deux messages ci-dessus s'applique toujours). Donc, je ne pense pas que votre cas d'utilisation ajoute quelque chose de nouveau à # 1400 (en gros, il semble que vous suggériez une fonctionnalité différente comme "ignorer la propriété si toutes ses valeurs sont définies avec des variables indéfinies" ou quelque chose comme ça mais c'est un autre grande histoire).

@sept-phases-max

Il serait peut-être préférable qu'il soit possible de définir une variable sur une valeur "indéfinie" ou "non définie". Définir une propriété sur une telle valeur signifierait que la propriété n'est pas rendue dans le CSS final. Cela simplifie la syntaxe et permet de valider que la variable est déclarée.

@JechoJekov

Il serait peut-être préférable qu'il soit possible de définir une variable sur une valeur "indéfinie" ou "non définie".

Comme je l'ai mentionné, il s'agit d'une autre fonctionnalité qui nécessite son propre ticket (avec sa propre discussion).

Juste quelques éclaircissements pour la feuille de route : ceci est marqué "ReadyForImplementation", mais il ne semble pas y avoir de consensus dans ce fil, et il semble que @seven-phases-max ait suggéré une alternative décente. @lukeapage @seven-phases-max, le prêt pour la mise en œuvre doit-il être supprimé ?

@matthew-dean Aucune idée. Je suppose qu'ici "ReadyForImplementation" est toujours en quelque sorte valide, ce qui signifie quelque chose comme "cette fonctionnalité ne semble pas vraiment nécessaire, mais si quelqu'un propose un PR implémentant une telle chose, il n'y aura pas de résistance" ou une sorte de :)

Comment est-ce? (En cours d'examen)

Pour moi, "Prêt pour la mise en œuvre" signifie qu'il existe un consensus général (mais pas nécessairement unanime) sur le fait qu'il _devrait_ être abordé ou mis en œuvre. Je pense que "Under Consideration" correspond à votre définition.

Toujours en train de rencontrer ce problème lors de l'utilisation de la portée

<strong i="6">@foo</strong>: 'bar';
& { 
  // not sure if <strong i="7">@foo</strong> is defined
}

J'adorerais pouvoir utiliser isDefined

Bien que quelque chose comme is-defined ait du sens (en tant que sucre syntaxique), ce n'est pas vraiment nécessaire. Définissez simplement _toujours_ @foo (avec la valeur par défaut dont vous avez besoin), après tout, si vous utilisez une variable dans vos styles - vous _pouvez_ prédire que vous devez la définir, par exemple :

// in a far far away galaxy of your library default variables:
<strong i="8">@foo</strong>: undefined;

// the code where you need it
& when not(<strong i="9">@foo</strong> = undefined) { 
    // <strong i="10">@foo</strong> is defined by user    
}

// some user code
<strong i="11">@foo</strong>: bar;

Bien que je suppose que j'ai déjà écrit cela dans les exemples ci-dessus (j'essaie juste de m'assurer d'exprimer le fait que l'absence de cette fonctionnalité ne peut pas être un obstacle pour quoi que ce soit. Si vous connaissez un cas d'utilisation où il est celle-ci, merci de la partager).

J'essaie de configurer des aperçus de thème dans le navigateur.

Cela signifie que je dois utiliser less.js et écraser la variable par défaut @theme avec les paramètres d'exécution.

Ala

window.less.modifyVars({
  theme: 'someOtherValue'
})

Dans mon LESS, j'importe un fichier global theme.less qui inclut

<strong i="14">@theme</strong>: undefined;

.setTheme {
  <strong i="15">@theme</strong> : 'default';
}
.setTheme;

j'ai aussi essayé juste

<strong i="19">@theme</strong>: 'default';

Dans le premier cas, la valeur sortie est undefined dans le second cas, elle est toujours default indépendamment de ce qui est défini dans modifyVars

Cliquez sur la liste déroulante des thèmes ici pour un exemple.

Le travail actuel (qui est sur le site en direct) consiste à saisir manuellement le chemin d'importation de la variable et à l'analyser à l'aide de regexp, puis à importer toutes ces variables avec modifyVars , car vous pouvez deviner que c'est assez compliqué

@ seven-phases-max Je l'ai réduit à un cas de test très spécifique avec @import causant des problèmes.

Dans les deux cas supposez :

Javascript

window.less.modifyVars({
  theme: 'changedValue'
});

Dans le premier cas dans theme.less, outer est correctement défini sur changedValue

sans composant

<strong i="17">@import</strong> 'theme.less';

sans thème

<strong i="22">@theme</strong>: 'default';
.outer {
  value: @theme; // value is set to changedValue
}

Dans ce cas d'échec, dans theme.less @theme est défini sur default et non changedValue

sans composant

<strong i="32">@import</strong> 'theme.less';

sans thème

<strong i="37">@theme</strong>: 'default';
<strong i="38">@import</strong> "@{theme}"; // theme is set to default not changedValue

En cas de "var in mixin", l'extrait se transforme en :

// defaults:
.setTheme {
   <strong i="6">@theme</strong>: undefined;
}

// custom:
.setTheme {
  <strong i="7">@theme</strong>: 'default';
}
.setTheme;

Bien que pour modifyVars , il devrait toujours en résulter 'someOtherValue' pour l'un ou l'autre des extraits que vous avez essayé (parce que modifyVars fonctionne simplement en ajoutant simplement la ligne <strong i="14">@theme</strong>: 'someOtherValue'; juste à la fin du compilé code source). Donc, si modifyVars ne fonctionne pas, le problème est probablement ailleurs.
J'ai regardé le code de la page button mais c'est trop complexe pour dire rapidement ce qui pourrait être faux. En un coup d'œil rapide, je ne peux pas voir (ou peut-être ne peux-je tout simplement pas comprendre) comment le code Less est recompilé et le CSS résultant est réappliqué après modifyVars (dans de simples extraits, cela se fait via less.refreshStyles suivant modifyVars ).

Au fait, au cas où, êtes-vous sûr de ne pas utiliser is-default comme quelque chose comme :

.setTheme when not(is-defined(@theme)) {
  <strong i="26">@theme</strong>: 'default';
}
.setTheme;

? Si c'est le cas, le problème est qu'un tel code violera directement le principe d'évaluation paresseuse ( is-defined devrait renvoyer false si la variable n'est pas définie, mais puisqu'elle _sera_ définie immédiatement dans cette portée , is-defined a également pour retourner true -> récursivité insoluble (pour plus de détails sur les raisons pour lesquelles les redéfinitions conditionnelles de type impératif ne peuvent pas être autorisées en toute sécurité dans Less, voir #2072).
C'est-à-dire que cela pourrait réellement fonctionner comme prévu (à moins que is-defined ne soit codé pour détecter et renflouer explicitement une telle récursivité) mais seulement comme un type de comportement non spécifié/indéfini, sans cohérence avec les règles normales de visibilité des variables, créant ainsi même plus de désordre.

@jlukic

<strong i="8">@theme</strong>: 'default';
<strong i="9">@import</strong> "@{theme}"; // theme is set to default not changedValue

Oui, c'était aussi l'un de mes soupçons (Malheureusement, je ne peux pas tester cela pour le moment, je ne peux pas non plus deviner comment cela pourrait se produire, mais oui, c'est possible car l'utilisation variable dans les importations est une véritable magie noire. Je vais créer un rapport d'émission si tel est le problème).

Je suis presque certain que cela a quelque chose à voir avec cette merveilleuse magie noire.

J'ai travaillé avec moins de fichiers très simples à déboguer, mais je n'ai pas encore eu l'occasion de créer un dépôt de cas de test.

Dans mes tests, l'échec est spécifique à l'utilisation des valeurs {@variable} dans l'importation, mais pas dans les propriétés CSS.

Profitant vraiment de la thématisation avec moins, j'aimerais surmonter ces problèmes. Voici un exemple de thème amusant avec MOINS que je viens de montrer à Meteor DevShop la semaine dernière (cliquez sur l'icône du pot de peinture en haut à droite)

@jlukic Je l'ai testé et modifyVars fonctionne pour les vars dans les importations comme prévu à la fois avec lessc et avec less.js (voir la démo codepen , c'est un code un peu délicat car il devait importer depuis l'URL effrayante de l' essentiel , mais je suppose que c'est égal à ce que vos pages sont censées effectuer... Il semble donc que le problème soit ailleurs).

Merci d'avoir pris le temps de produire le cas de test pour moi. C'est assez clair. Je ne sais pas ce qui se passe pour moi.. Je vais devoir enquêter

Y a-t-il eu du mouvement sur cette demande? J'ai été anxieux pour une vérification variable indéfinie depuis un certain temps maintenant. En ce moment, j'ai un travail autour qui est loin d'être idéal...

p {
  & when not (@body-text-color = null) {
    color: @body-text-color;
  }
}

mais, pour que cela fonctionne, la variable doit exister et être définie comme null par défaut. Ce serait beaucoup plus efficace/flexible si je pouvais simplement vérifier si la variable existe même en premier lieu.

+1

Donc en résumé : l'implémentation d'une fonction is-defined(name) (et/ou get-value-of(var-name, fallback-value-if-not-defined) ) dans un plugin nécessite moins de 15 lignes de code. Alors faites-le si vous êtes assez courageux.

+1 à ça. Y a-t-il des progrès à ce sujet en tant que plugin? Je veux dire, @seven-phases-max vous connaissez mieux le code que la plupart des contributeurs, je suppose. Si cela nécessite environ 15 lignes de code, pourquoi n'a-t-il pas encore été fait ?

Si cela nécessite environ 15 lignes de code, pourquoi n'a-t-il pas encore été fait ?

Parce que personne n'est vraiment intéressé ? Chaque fonctionnalité est cool et "extrêmement utile" quand quelqu'un d'autre le fait pour vous... Mais magiquement, cela ne devient pas si important quand il s'agit de votre propre temps ;)

vous connaissez mieux le code que la plupart des contributeurs

Cela ne signifie pas que je dois mettre quoi que ce soit de mon propre intérêt après tout ce qui intéresse quelqu'un d'autre, désolé (surtout si c'est quelque chose d'encourageant ce que je considère personnellement comme une mauvaise utilisation/un mauvais style de code).

Pour ne pas sembler vide, pour le cas d'utilisation de @ashenden : voici la bonne façon de rendre l'un de vos ensembles de règles personnalisable par des "inconnus" (en supposant évidemment un cas où le remplacement CSS normal n'est pas applicable pour une raison quelconque) sans le défaut idée de "déplacer en aveugle chaque valeur CSS vers une variable-plus-utiliser-quelque-chose-que-vous-n'utilisez pas" (je n'entrerai pas dans les détails pourquoi c'est réellement cassé car c'est une histoire pour un long article de blog).

Il y a un concept généralement nommé "hooks", donc ce qui suit "ne peut pas me décider festival":

// .............................................
// base code:

p {
    & when not (is-defined(@body-text-color)) {
        color: @body-text-color;
    }
    & when not (is-defined(@body-text-color)) {
        background-color: @body-back-color;
    }
}

span {
    & when not (is-defined(@body-text-color)) {
        color: @body-text-color;
    }
    & when not (is-defined(@body-text-color)) {
        background-color: @body-back-color;
    }
}

// .............................................
// customization:

@body-back-color: blue; // how about gradient?

doit être remplacé par :

// .............................................
// base code:

p {
    .body-text();
    .body-back();
    // ^ it's actually better to group all this into a singe entity, e.g. .p()
    // so that as you don't know WHAT or HOW to be customized
    // you don't pre-enforce any limitations and/or hardcoded approach
    // for something YOU do not even write
}

span {
    .body-text();
    .body-back();
}

.body-text() {}
.body-back() {}

// .............................................
// customization:

.body-back() {background-color: blue}

Comptez les lignes, comptez les possibilités, comptez les limites.
C'est-à-dire vraiment, si vous n'utilisez pas certaines propriétés CSS, veuillez les laisser seules pour ceux qui le feront .

Les gars, voici où j'ai rencontré cela, veuillez jeter un œil à cet exemple et dites-moi si c'est un cas valide et ne peut pas être corrigé sans is-undefined.

Je veux charger des thèmes dans une bibliothèque comme un module comme ça :

Dans mon application principale, je définis la variable @theme : 'jaune', puis j'importe moins de bibliothèque.

Et voici à quoi pourrait ressembler moins de bibliothèque dans ce cas :

@import 'thèmes/@{thème}' ;

corps {
arrière-plan : @primaryColor ;
}

De cette façon, je pourrais avoir yellow.less et default.less avec @primaryColor : yellow et @primaryColor : red.

En fin de compte, je peux écrire ma bibliothèque en utilisant des noms de variables sémantiques comme primaryColor et fournir un ensemble de thèmes avec ces variables définies. Et l'utilisateur de la bibliothèque définirait simplement le nom du thème dans son application et importerait les styles de la bibliothèque.

Ok, peu importe, on dirait que j'ai compris, j'ai juste besoin d'un mixin d'importation comme celui-ci :

<strong i="6">@theme</strong>: 'default';

.imports(@theme) when (<strong i="7">@theme</strong> = 'yellow') {
    <strong i="8">@import</strong> "themes/yellow";
}
.imports(@theme) when (<strong i="9">@theme</strong> = 'default') {
    <strong i="10">@import</strong> "themes/default";
}
.imports(@theme);

@waterplea Vous pouvez simplifier votre code pour :

<strong i="7">@theme</strong>: default;

.imports(yellow) {<strong i="8">@import</strong> "themes/yellow";}
.imports(default) {<strong i="9">@import</strong> "themes/default";}
.imports(@theme);

notez également les guillemets redondants supprimés.

Bien que pour être honnête, je ne vois pas comment <strong i="13">@theme</strong>: yellow; (+ tout le code mixins) est meilleur que la ligne explicite <strong i="15">@import</strong> "themes/yellow"; . C'est-à-dire tout d'abord êtes-vous au courant de la dérogation ? C'est-à-dire que vous n'avez pas besoin de masquer par défaut <strong i="18">@import</strong> "themes/default"; , si l'utilisateur de votre bibliothèque doit appliquer des trucs yellow - elle importe simplement votre thème jaune ( n'importe où après votre fichier de bibliothèque principal, et encore une fois c'est le même une ligne) et voilà - votre bibliothèque utilise des valeurs variables spécifiées dans le fichier jaune.

Je me suis retrouvé avec une importation facultative d'un fichier qui remplace le thème ou passe à un thème prédéfini. Dans un projet qui utilise la bibliothèque, nous configurons ensuite Webpack pour utiliser l'alias de ce fichier en tant que module de nœud si le projet a besoin d'un thème différent. Ce que j'ai écrit auparavant ou ce que vous avez écrit ne fonctionnerait pas dans notre cas car nous construisons un kit d'interface utilisateur pour Angular et il est hautement modulaire. Nous pouvons importer un seul bouton ou sélectionner un contrôle et il doit être conscient du thème que nous utilisons avec l'encapsulation de tous ses styles. La solution est facile à mettre en place donc j'en suis content.

ce que vous avez écrit ne fonctionnerait pas dans notre cas car nous construisons un kit d'interface utilisateur pour Angular et il est hautement modulaire.

_{J'ai vu cela une infinité de fois auparavant - c'est l'un des problèmes les plus tristes de Less (mal)compréhension - les gens manquent juste le principe fondamental d'évaluation Less paresseux et, au lieu d'utiliser le naturel Less prioritaire, construisent des bibliothèques avec une injection de fichiers lourde - basés sur des modèles de personnalisation inspirés des habitudes des langages avec une sémantique variable directement opposée (comme PHP, Sass, etc.). Ce doit être quelque chose de plus qu'un type qui crie continuellement "Les gars, vous vous trompez !"}

J'aimerais bien faire les choses, je ne prétends pas tout comprendre :) Voulez-vous expliquer votre suggestion sur mon exemple ? Voici ce que nous avons :

Voici un exemple structurel minimum :

Bibliothèque:

• importer.moins
  <strong i="10">@import</strong> 'theme-default';
<strong i="13">@import</strong> 'mixins';
• moins de mixins
  some mixins here like resetting default browser button styles
• theme-default.less
  <strong i="20">@primary</strong>: red;
<strong i="23">@secondary</strong>: blue;
• thème-secondaire.moins
  <strong i="27">@primary</strong>: green;
<strong i="30">@secondary</strong>: yellow;
• boutonComposant
  <strong i="34">@import</strong> 'import';
.button { color: @primary; }

Projet 1 (doit utiliser le thème par défaut) :

• composant
  <strong i="42">@import</strong> 'import';
body { background: @secondary; }

Projet 2 (doit utiliser le thème secondaire) :

• composant
  <strong i="50">@import</strong> 'import';
body { background: @secondary; }

Notre bibliothèque est ajoutée en tant que module de nœud et dans les projets, nous importons uniquement le composant de bouton de la bibliothèque. Puisqu'il s'agit d'un module angulaire pour ce bouton avec son propre fichier moins, il est compilé séparément du reste du projet 1 ou du projet 2.

J'y réfléchis depuis un moment et je n'arrivais pas à trouver un moyen d'organiser moins de fichiers pour permettre au projet 1 ou au projet 2 de définir le fichier de thème à utiliser lors de la compilation des composants et du propre code de Projects. Je ne vois aucun moyen de remplacer les styles du composant de bouton à partir du code de Project.

Donc à la place, en gros, voici comment j'ai écrit import.less :
<strong i="58">@import</strong> 'theme-default';
<strong i="61">@import</strong> 'mixins';
<strong i="64">@import</strong> (optional) '~custom-theme';

Et dans les projets, si je veux remplacer les variables de thème pour les composants de code et de bibliothèque de projets, j'alias ce fichier en tant que module à l'aide de webpack. Ce fichier pourrait avoir un remplacement explicite de, par exemple, @primary ou simplement un passage au thème secondaire :
<strong i="69">@import</strong> '~myLibrary/styles/theme-secondary';

Donc, je connais le dépassement, le problème est - l'utilisateur de la bibliothèque n'a aucun moyen d'entrer entre "n'importe où après votre fichier de bibliothèque principal" et le code du composant de la bibliothèque. Je comprends que ce que vous dites fonctionnerait pour les frameworks sans encapsulation de styles, mais pour Angular, cela ne fonctionnerait pas ou j'ai mal compris quelque chose dans votre solution.

Je vois. Ensuite, nous parlons en fait de la même chose (juste dans des mots différents). Dès que buttonComponent (ou tout autre composant) est compilé séparément, "le maître de personnalisation du projet" reste le fichier import.less et vous avez fait exactement ce que j'ai suggéré. (alors que Project 1 et Project 2 deviennent juste un autre composant "autre chose" (ou "tout-en-un" ?) du même niveau que buttonComponent et non tout un "projets").

C'est-à-dire que de cette façon, je dirais que vous "l'avez bien fait" à mon goût.

Ce problème a été automatiquement marqué comme obsolète, car il n'a pas eu d'activité récente. Il sera fermé s'il n'y a plus d'activité. Merci pour vos contributions.

@stale Ping.

Techniquement, un plugin implémentant la fonctionnalité est disponible depuis 2015 . Mais personnellement, je ne l'ai jamais testé, alors ne me blâmez pas si quelque chose ne va pas (c'est juste pour votre information).

Ce problème a été automatiquement marqué comme obsolète, car il n'a pas eu d'activité récente. Il sera fermé s'il n'y a plus d'activité. Merci pour vos contributions.

Alors ... J'ai parcouru ce fil et je ne peux pas vraiment déterminer s'il s'agit principalement de cas de personnes qui comprennent mal Moins de portée ou non.

Je ne vois pas vraiment la nécessité de vérifier si les variables sont définies. Les variables doivent être définies si elles doivent être consommées.

<strong i="7">@import</strong> "library";  // contains @library-color: blue;

@library-color: red;

.box {
  color: @library-color;
}

Je ne comprends pas la nécessité de définir conditionnellement une propriété basée sur la valeur _changing_. Si la propriété est définie sur une variable, modifiez simplement la valeur de la variable.

Autrement dit, si library.less a ceci :

@library-color: blue;
.box {
  color: @library-color;
}

Tout ce que quelqu'un aurait besoin de faire pour définir sa sortie :

<strong i="16">@import</strong> "library";
@library-color: red;

Cela produirait:

.box {
  color: red;
}

Est-ce que l'OP et les autres dans ce fil comprennent ce comportement ?

Je pense que le cas d'utilisation de "est-ce que var existe" est une bonne façon de faire des drapeaux. Autrement dit, je ne pense pas qu'il y ait un "faux" conceptuellement simple. Ou plutôt, il est inhabituel que true soit la seule valeur "véridique". En d'autres termes, je pense que c'est une question d'éducation, plutôt qu'une question de comportement.

Je pense que nous devrions envisager de fermer ce problème, car cela est généralement résolu avec une ligne déclarant la valeur de la variable par défaut. Bien qu'avec Less v3.5 évoluant vers un accord plus permissif, peut-être que les variables à l'intérieur des gardes sont évaluées de manière plus permissive ?

Mon vote est non, cependant. @the-variable: false; semble être tout ce que OP doit ajouter.

Pour tous ceux qui ont des questions sur la façon de résoudre un problème spécifique qui leur semble lié à cela, n'hésitez pas à poster sur le moins gitter et @ moi.

Ok fermeture, merci @calvinjuarez.

Ce qui s'est également passé depuis que c'était ouvert est la fonction if() . Vous pouvez donc faire color: if((@variable), green, red);

@matthew-dean Merci beaucoup d'avoir écrit avec cette astuce. J'ai vu l'ajout de if() dans les notes de version 3.0, mais je n'ai pas fait le lien avec ce problème, pour lequel j'avais un cas unique (mais pas le temps d'en faire une version réduite). Encore une fois, très apprécié. Bravo, l'équipe LESS.

@kbav Pas de problème ! Une autre astuce en plus de cette astuce : lorsque if() a été introduit pour la première fois, il fallait des parenthèses autour des conditions car il s'agissait essentiellement "d'intégrer" une protection "lorsque" (comme dans la partie après when dans when (@variable) ). Cependant, cela a été corrigé à partir de Less 3.6, vous pouvez donc écrire l'exemple ci-dessus sans parenthèses (si vous compilez avec la dernière version):

color: if(<strong i="10">@variable</strong>, green, red);