Less.js: Code CSS conditionnel

allez sur http://www.lesscss.org/ et recherchez des gardes.

pour éviter d'avoir à utiliser des mixins, regarde la demande de fonctionnalité pour autoriser les gardes sur n'importe quel css.

Oui, je le sais, mais si nous écrivons énormément MOINS, nous devons écrire et gérer des centaines de .mixins
Je ne pense pas que mixin résolve ce problème. Même les mixins auront beaucoup de puissance avec cette fonctionnalité.
Moins de CSS ont presque toutes les fonctionnalités que certains langages de programmation ont alors pourquoi pas ça ?

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

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

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

J'ajouterais un gros +1 pour cette fonctionnalité qui me manque vraiment. Maintenir des gardes avec une grande base de code est vraiment un cauchemar. Cela faciliterait vraiment les choses...

Nous pouvons même ajouter une instruction switch.

@lukeapage pouvez-vous s'il vous plaît rouvrir ce problème. Je pense que nous devrions discuter de ce problème/fonctionnalité

LESS n'est pas un langage de script. La syntaxe/style ressemble à CSS.

LESS est censé être déclaratif, ce qui signifie qu'il ne devrait pas être capable de situations complexes avec une logique de branchement, des boucles, etc.

@pierresforge avez-vous des exemples où les gardes sont insuffisants ?

et où cela ne serait pas résolu en pouvant avoir des gardes sur n'importe quel sélecteur ?

la discussion est ouverte .. si vous pouvez me persuader (ou un autre membre de l'équipe principale) qu'ils sont nécessaires, je rouvrirai le problème .. mais la conversation a déjà eu lieu et beaucoup de temps y a été consacré .

La phrase de http://lesscss.org/
"LESS étend CSS avec un comportement dynamique tel que des variables, des mixins, des opérations et des fonctions."

Oui LESS n'est pas un langage de script, mais il a toujours des fonctionnalités comme des variables, des fonctions et des opérations.
Ce qui manque, c'est la logique conditionnelle.

Je pense que CSS Media Query n'est rien d'autre que la logique conditionnelle.

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

Si CSS peut avoir une logique conditionnelle comme les gardes. Alors, quelle est la difference. Les gardes l'étendent juste aux mixins.
Les gardes n'autorisent que les conditions en dehors du bloc de code CSS et non à l'intérieur du bloc de code.
Veuillez consulter https://github.com/cloudhead/less.js/issues/1293#issuecomment -16929701 pour une instance, les gardes ne peuvent pas aider avec une telle exigence.

Même HTML a une logique conditionnelle, oui et c'est un langage de balisage et non un langage de script.

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

@lukeapage merci..

Les gardes sont analogues à ce que font les requêtes multimédias. Notez qu'en CSS ordinaire, vous ne pouvez pas imbriquer des requêtes multimédias dans des sélecteurs ; Vous ne pouvez les placer qu'à la racine du document.

Non, je n'ai aucun exemple où les gardes ne suffisent pas. Cependant, il y a beaucoup de cas où les gardes ne sont pas vraiment les meilleurs pour la maintenabilité.

Un exemple:

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

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

est à mon sens plus concis et explicite (principalement dans les cas où il ne sert à rien de rendre le code réutilisable, car l'algorithme dépend de nombreux facteurs) que:

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

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

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

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

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

Je suis d'accord que cela est sujet à discussion, mais ce serait un très bon ajout, s'il n'implique pas beaucoup de changements de base. Il permet de regrouper la plupart des règles à appliquer à un seul élément sans nécessiter l'ajout de mixins.

Ce genre de situation est la raison pour laquelle j'ai écrit la fonction de contraste - elle agit comme une sorte d'opération conditionnelle qui n'est pas disponible autrement, et c'est beaucoup plus propre que d'utiliser des gardes, comme vous le dites. Je suppose que nous pourrions implémenter une sorte de fonction générique qui agit comme une sorte de sélecteur, plutôt que d'aller jusqu'à ajouter une syntaxe pour les conditions.

@Soviut Devil's Advocate - Dans LESS, vous POUVEZ placer votre requête multimédia dans un sélecteur, ce qui est souvent très utile.

J'ai été contre les ifs, car cela commence à faire augmenter la complexité de votre code de manière exponentielle, et LESS est conçu pour être simple et direct. En ce moment, il y a des pressions pour stabiliser le langage plutôt que d'ajouter de nouvelles fonctionnalités.

Cependant .... avocat du diable encore une fois, basé sur la logique selon laquelle les requêtes des médias apparaissent désormais dans les sélecteurs, les gardes pourraient théoriquement suivre le même principe.

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

  background-color: @coreBackgroundColor;

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

or

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

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

Plus déclaratif que ifs, syntaxe plus proche de LESS existant, et évalue chaque instruction indépendamment (comme LESS / CSS est défini).

Alternativement (ou en plus de), de la même manière, attacher l'évaluation d'un mixin au point d'évaluation :

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

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

On peut dire que les gardes au niveau de l'instruction ne sont pas plus/moins complexes ou une logique différente que les gardes au niveau mixin IMO. Les exemples 2 et 3 sont probablement moins expansifs pour le langage. Je pensais juste que je mettrais ça là-dedans pour réflexion / discussion.

Je suppose que personne n'avait grand-chose à dire sur ma proposition de gardiens de la déclaration. ;-)

En fait, non, pas grand chose à dire. Ce serait juste une bonne chose, IMO :)

Oui, s'ils sont déjà sur des mixins et que les requêtes multimédias peuvent être à l'intérieur d'éléments, il semble que la logique pour les étendre soit raisonnable. Curieux de savoir ce que pensent @lukeapage et @jonschlinkert et d'autres.

@matthewdl :+1:

Je pense que je les ai déjà soutenus sur la question dont ils sont discutés.... :)

@lukeapage Parlez -vous du numéro 748 ? Si oui, j'ai ajouté un peu à la syntaxe. ;-)

J'aimerais exprimer mon désir d'avoir une forme de if ou @when .

Je ne suis pas d'accord avec le sentiment que les gardes sont universellement meilleurs et rendent le code MOINS moins complexe que l'utilisation de conditions. Je trouve des situations pratiques où les gardes rendent en fait mes fichiers LESS plus laids et plus difficiles à lire, mais un if / @when serait en fait exceptionnellement lisible. Les gardes et les conditionnels if / @when ne sont par nature que des outils, les deux peuvent être utilisés pour rendre les choses belles ou laides et sont mieux adaptés à différentes situations. Enfer, je peux créer un fichier ~ 300b .less qui n'utilise que la fonction d'extension de sélecteur la plus basique de LESS pour consommer plus de 1 Go de RAM et laisser le processeur tourner pendant des minutes.

Dans un projet récent sur lequel je travaillais avec l'intention de prendre en charge à la fois les ordinateurs de bureau et les appareils mobiles, j'ai finalement décidé que faire cela avec des requêtes multimédias en ligne n'était pas suffisant. Servir du css supplémentaire à l'un ou l'autre mode qu'il n'utiliserait même pas ne sonnait pas bien, plus tout le problème d'essayer de cascader le double chargement des images d'arrière-plan et d'avoir à contourner cela tout en étant toujours incapable d'intégrer un URI de données sans perdre de temps servant une image entière qu'un mode n'utiliserait pas. Et gérer cela en essayant de cascader deux feuilles de style ne ferait que réduire le désordre, car il y aurait maintenant deux endroits déclarant les styles pour une classe.

Ma décision a été de prendre une page de la façon dont MediaWiki gère RTL, en servant deux feuilles de style à partir d'une seule. MediaWiki le fait en écrivant des feuilles de style dans LTR, puis en retournant la feuille de style pour créer une deuxième feuille de style RTL. Il n'est pas nécessaire d'essayer de remplacer tout ce qui est spécifié pour que LTR gère RTL. De même, j'ai décidé d'écrire mes styles principaux dans un main.less (et potentiellement des fichiers référencés à partir de celui-ci pour séparer les styles), ce fichier ne serait pas compilé directement. Au lieu de cela, j'aurais deux feuilles de style un desktop.less et un mobile.less, les deux définiraient des choses comme <strong i="14">@mobile</strong>: true/false; , <strong i="16">@desktop</strong>: true/false; , et remplaceraient également certaines variables comme la taille des choses. De cette façon, mon main.less finit par devenir à la fois un desktop.css et un mobile.css, et je peux gérer la requête/le test multimédia en déterminant lequel charger ailleurs (si je le voulais VRAIMENT, je pourrais en fait déterminer lequel charger même sur un appareil qui ne prend même pas en charge les requêtes multimédias).

Le seul problème est cependant les blocages conditionnels. Il y a des parties du code que je décide "le mobile n'a pas besoin de ces styles" ou "le bureau n'a pas besoin de ces styles". Actuellement, la seule façon de le faire en moins est avec:
((Ok, techniquement, ces styles sont hypothétiques puisque je n'utilise pas de navigation en accordéon mais ils sont fidèles à ce que je fais))

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

Dans cette situation, il serait beaucoup plus compréhensible d'utiliser quelque chose comme @when .

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

En fait, j'ai envisagé de pré-traiter mes moins de fichiers pour transformer quelque chose comme une syntaxe @when en un hack où un mixin+guard généré dynamiquement est créé puis inclus directement après.
Inutile de dire que si l'idée de pré-traiter un pré-processeur semble être une bonne idée qui rendra les choses plus faciles à comprendre... quelque chose ne va pas avec le pré-processeur actuel.

Et la vérité est que cela ne s'applique pas seulement à ma technique de bureau/mobile. Cela pourrait également s'appliquer aux schémas thématiques. Écrivez un fichier principal en moins avec votre thème. Ensuite, ayez un tas de fichiers en moins dans lesquels vous incluez simplement ce fichier en moins, puis définissez moins de variables pour contrôler des choses comme le jeu de couleurs. Les ajustements de couleur fonctionneront bien, mais vous tomberez immédiatement d'une falaise une fois que vous découvrirez que vous pouvez vraiment utiliser quelque chose comme @use_horizontal_nav .

@dantman à partir de 1.5.0 et protège les styles CSS qui sont liés, vous pouvez le faire

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

qui est le sucre pour votre exemple.

Le seul inconvénient est que pour le moment, il pense qu'il s'agit d'un nouveau sélecteur, il ne le fusionne donc pas avec le sélecteur précédent. Cependant, je pense qu'il est peu probable que cela vous cause des problèmes et ce sera quelque chose que je/nous corrigerons dans les futures versions.

Ok merci, pouvons-nous avoir cela documenté en tant que fonctionnalité ?

Pour être honnête, je ne suis pas non plus sûr que ce soit très compréhensible par rapport à @when , je ne suis pas sûr que si j'avais déjà vu & when(...) dans un fichier .less, j'aurais compris ce que c'était fait d'un coup d'œil. @when comme sucre pour & when() pourrait être sympa.

Je suis d'accord avec @matthew-dean en ajoutant ce type de structures conditionnelles qui rendra probablement les fichiers de base LESS plus difficiles à maintenir et à tester. Et les fichiers .less plus difficiles à déboguer et ainsi de suite.

Ce que nous avons en ce moment est une œuvre d'art, les gens peuvent comprendre et apprendre les bases de MOINS en moins de 10 minutes (je parle d'imbrication et de mélange), l'ajout d'instructions conditionnelles rend les choses plus difficiles à digérer pour d'autres types de personnes comme créateurs et passionnés. essayer d'utiliser des gardes pour imiter ou simuler des instructions IF, c'est simplement essayer d'exacerber un problème qui n'existe pas et n'a pas besoin de solution.

Si un développeur a besoin de plus de complexité et de contrôle sur ses fichiers LESS avant de les compiler, rien ne l'empêche d'utiliser des langages comme PHP pour pré-traiter moins de fichiers afin d'obtenir plus de contrôle, de flexibilité et de complexité, il existe de nombreuses façons de faire cela n'est qu'une question d'utilisation de l'imagination pour le faire de la manière la plus correcte ou la plus pratique.

Par exemple, de peur de dire que j'ai un fichier nommé "myfile.less.php" qui contient un code fou avec conditionnel, des commutateurs, des tableaux et tous les trucs fantaisistes que vous pouvez voir sur PHP, puis à partir de ce fichier ".less.php" cracher un autre fichier appelé "myfile.less" qui a le code LESS final, de cette façon je peux interroger tous les vars du serveur avec PHP, décider ce que @imports mon nouveau fichier .less inclura ou exclura, plus besoin de passer une grande quantité de vars stupides à le compilateur LESS et pas besoin d'écrire des gardes stupides et difficiles à lire pour imiter les structures IF ou Switch simulées.

Un flux de travail de base pourrait ressembler à ceci

1- vérifier si le cache a expiré
1- appelez le script pour trouver et pré-traiter tous les fichiers ".less.php"
2- appelez le script pour compiler tous les fichiers ".less"
3- mettre à jour le cache

@enav Je ne suis pas d'accord avec ferveur. en plus de développer moins, je l'utilise dans des solutions d'entreprise basées sur le dessus de nœud, où nous ne voulons pas avoir à utiliser 2 langages pour résoudre un problème.

@dantman , il y a pas mal de choses non documentées et oui, nous devons documenter cela. il y a un effort en cours chez less-docs pour étendre la documentation et améliorer le site Web. J'y ajouterai un problème.

@lukeapage , ouais j'ai remarqué ça récemment. J'ai parcouru le journal des modifications et j'ai remarqué des choses comme svg-gradient et propriété fusionnant avec +.

Strictement parlant, & when ... est déjà documenté puisqu'il ne s'agit que d'une simple combinaison de deux fonctionnalités documentées & et CSS Guards . Mais un exemple dédié ne fera pas de mal bien sûr.

@ seven-phases-max, je n'étais pas au courant de cette documentation. À première vue, il s'agit d'un nouvel ensemble de documentation incomplet pour remplacer l'ancien site, en passant par le "Ceci sera bientôt déplacé vers le dépôt lesscss.org ! Nous vous recommandons d'éviter de créer un lien vers ce site tant que tout n'est pas en ligne." commenter. Ce qui est bien de savoir que quelque chose comme ça est en préparation.

Je faisais référence à la documentation actuelle sur lesscss.org, qui était la seule documentation que je connaisse, et ne documente actuellement que les gardes en tant que fonctionnalité mixin, sans suggérer qu'elle est disponible ailleurs.

Les gardes ne sont pas aussi bons que ça. :(

Il s'agit d'une fonctionnalité requise et également présente dans scass.

+1 pour ça

Étant donné que ce commentaire d'aujourd'hui a été soulevé quelques années après l'ouverture de ce numéro, je soulignerai une chose qui me vient à l'esprit pour le moment.

Une partie de la résistance à @when dans la discussion d'origine est la règle supplémentaire. Cependant, en y réfléchissant maintenant, cela ne devrait pas être nécessaire.

Considérant que ces deux blocs sont égaux :

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

Ensuite, ces deux déclarations doivent également être acceptées par l'analyseur comme égales.

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

Si pour aucune autre raison que & when est syntaxiquement vraiment gênant. Omettre & pour impliquer toujours une jointure de sélecteur avec le sélecteur parent a toujours existé, donc omettre & pour impliquer une garde sur le sélecteur parent ne semble pas être un saut. De plus, les fonctions de racine de bloc sont maintenant acceptées par l'analyseur pour être utilisées avec des plugins, donc cela n'a plus l'air aussi étrange qu'il aurait pu l'être en 2013.

Je ne vois aucune raison de le rouvrir. Après tout nous avons déjà #2072

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

Ouvrir une grande boîte à confusion juste pour l'économie de deux personnages ?

Les gardes ne sont pas aussi bons que ça.

Je pensais que ce ne serait même pas la peine de commenter un commentaire déraisonnable au hasard. Toute position devrait avoir quelque chose derrière elle (sinon, je dirais que tout code conditionnel est boiteux et que if sont idiots simplement parce que je sais écrire _n'importe quoi_ sans même une seule condition dans presque toutes les langues).

Je ne vois aucune raison de le rouvrir. Après tout, nous avons déjà when (1=1) { color: blue; }

Euh... non, nous ne le faisons pas ?

Mais il est raisonnable que nous le fassions. Nous pourrions simplement le permettre et en finir avec cela.

Attendez, jusqu'à ce que je trouve la demande de fonctionnalité à laquelle il est censé être lié (désolé, j'ai accidentellement cliqué sur Entrée avant de le terminer)

Donc, fusionnez ceci avec # 2072.

@sept-phases-max

Ce problème s'appelle "Autoriser la redéfinition de variables à l'intérieur de blocs auto-exécutables gardés" et la discussion tangentielle en bas de ce problème contenait des cas d'utilisation analogues à un select / case et un vbscript iif([ifcond], [then], [else]) fonction plus que juste le nu quand, même si c'est peut-être un pick-up plus logique pour la discussion. Buuut... il devrait probablement être soulevé comme un nouveau problème avec seulement la question when () vs & when () .

avec juste la question quand () vs & quand ().

Vous ne pouvez pas être sérieux là-dessus, n'est-ce pas ? A cause de quoi exactement ? when ne deviendra pas if (voir #2072 pour toutes les raisons) si vous supprimez & . Alors laissez-le tel quel et finissez-en.

Hey, pouvez-vous baisser le ton d'un cran? Si cela vous dérange, prenez un moment et revenez plus tard pour regarder le raisonnement que j'ai publié dans le nouveau numéro. Certaines choses ont évolué depuis ces discussions initiales.

Je ne voulais pas offenser ou quoi que ce soit.
Mon:

Alors laissez-le tel quel et finissez-en.

n'était qu'une réponse à :

Nous pourrions simplement le permettre et en finir avec cela.

@ seven-phases-max Ok, le ton se perd dans le texte. En tout cas, je n'étais pas très attaché à cette idée, et dans l'ensemble, la proposition existante @when est meilleure / plus polyvalente de toute façon.

Je pense que 'sass' vaut mieux que moins. Il a déjà if-else. C'est vraiment dur et beaucoup de lignes de codage en moins. Quand ça marche mais ça ne répond pas complètement au besoin. De plus, nous pouvons faire des boucles en moins mais la langue devrait avoir sa propre fonctionnalité.

@aukgit Utilisez le bon outil pour le travail. Si SCSS vous convient mieux, il vaut mieux l'utiliser. Sass et Less sont des projets très différents.

@matthew-dean après avoir appris moins pendant des mois et écrit des tonnes de moins si la communauté "moins" ne veut pas être meilleure, alors c'est une perte pour nous deux. Je pense que c'est pourquoi bootstrap est passé à 'sass' (https://github.com/twbs/bootstrap/tree/v4-dev) à partir de moins (la raison initiale était une compilation plus rapide). Alors que la source initiale était dans "moins". Maintenant, ils écrivent leur source d'origine en "sass" puis la convertissent en less (alors que c'était l'inverse).

Autre chose :

"Le bon outil pour le bon travail"

ne devrait pas s'appliquer ici

Moins | Scs | Stylet projets similaires . Commencé avec un qui était populaire à l'époque, il semble maintenant que cette communauté "moins" ne veut pas s'améliorer.

L'idée derrière le « moins » est d'écrire moins et d'en faire plus. Quelque part, cela fait de la réduction, mais quelque part, cela nécessite plus d'écriture.

Merci pour vos commentaires.

Propagande obsolète fanboyish. Ce serait une perte de temps d'argumenter toutes ces déclarations biaisées ou simplement fausses.

Par exemple:

Il n'y a aucun moyen de faire du code conditionnel vraiment compilé.

Ouais, "J'ai besoin d'un outil pour écrire mon code spaghetti" - juste comme ça . Si vous écrivez un code comme celui-ci, en effet Less n'est certainement pas votre outil.

Je pense que "moins" fait 'x' quelque chose de très différent de sass et stylus. Tous les autres font des choses similaires alors que "moins" prétend que ce n'est pas un genre similaire. :)

@aukgit

Je pense que "moins" fait 'x' quelque chose de très différent de sass et stylus.

_Pourquoi_ devrait-il faire la même chose ? Voir par exemple [1] et [2] pour trouver les principales différences entre les conceptions. Donc, vous n'aimez peut-être pas le concept, mais personne ne vous oblige à utiliser un outil que vous n'aimez pas.

Maintenant je comprends. Merci. Vraiment, c'est vraiment la langue la plus mal comprise qui soit. Même le javascript n'est pas si mal compris que le dit Douglas Crockford.

Les gens font des erreurs en js mais il y a beaucoup de prise de conscience. Pour "Moins", cela devrait être dans la première page (less.org) décrivant ce qu'est moins et ce qui ne l'est pas.

Merci.

A écrit un mix :

Moins:

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

    .x(@value);
}

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

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

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

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

Sortie CSS :

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

si la communauté "moins" ne veut pas être meilleure, c'est une perte pour nous deux

Je pense que c'est une erreur de supposer que "la fonctionnalité X que je veux n'est pas prise en charge" == "Moins de communauté ne veut pas être meilleur". Cela ne nous mène nulle part.

Il y a plusieurs discussions sur Github pour travailler sur l'amélioration des flux de contrôle. En fait, ce fil n'a pas été rejeté, il a été fusionné avec le #2072. Vous avez commenté un sujet fermé vieux de 3 ans. J'avais d'autres idées qui, je pensais, auraient pu le rendre un peu différent de # 2072, mais j'étais essentiellement convaincu du contraire.

maintenant il semble que n'a pas de meilleures fonctionnalités

Moins n'a pas _plus_ de fonctionnalités, c'est vrai. C'est par conception. C'est ainsi que vous pouvez apprendre Less en une journée, et les fonctionnalités de Less couvrent 99% des cas d'utilisation typiques. Sass a une courbe d'apprentissage plus abrupte. Sass avait tellement de fonctionnalités qu'ils ont dû créer un compilateur bas niveau basé sur C juste pour pouvoir continuer à le compiler. Ce qui est une grande réussite. Mais ce n'est pas un grand témoignage pour quelque chose qui, en fin de compte, ne fait que créer une feuille de style.

Maintenant, ils écrivent leur source d'origine en "sass" puis la convertissent en less (alors que c'était l'inverse).

C'est vrai, mais c'est basé sur plusieurs facteurs, et vous pouvez leur demander lesquels. Personnellement, je pense qu'abandonner les utilisateurs de Less est une erreur, car il y a beaucoup de gens qui utilisent Bootstrap dans Less aujourd'hui.

En fin de compte, vos plaintes concernant les cerceaux nécessaires pour écrire des conditionnels ne sont _pas fausses_. Les exemples proposés ici ne correspondent tout simplement pas au langage. Je vous suggère de relire le fil du #2072.

(c'est en fait un peu hors sujet, mais je me demande juste)

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

Et à quoi serviraient ces variables en plus d'appeler .if-value-present-multi ?
(Et _si_ ces variables _sont_ utilisées pour autre chose) Ne serait-il pas logique d'utiliser à la place une paire propriété/valeur, par exemple :

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

De plus, quel pourrait être le but d'écrire .x {.if-value-present(content, 'new val')} si vous n'avez besoin que .x {content: 'new val'} ? Et écrire .x {.if-value-present(content)} s'il ne fait rien ?

(Bien qu'honnêtement, j'ai regardé [1] - eh bien, ne commentant rien sauf une seule chose : (_juste pour gagner du temps_) pensez à jeter les anciennes bibliothèques comme elements et lesshat - et utilisez autoprefixer la place. Nous n'avons plus besoin de bibliothèques de préfixation de fournisseur pour l'un ou l'autre des préprocesseurs CSS depuis un moment maintenant).

C'est généralement ainsi que la plupart des "demandes de fonctionnalités" arrivent : "Problème XY" . (Autres bons exemples d'échecs similaires dans le domaine connexe : #1400 et #1894, ce n'est pas que les fonctionnalités seraient totalement inutiles (donc les deux sont maintenues ouvertes), mais quand on commence à demander leurs cas d'utilisation réels, cela révèle généralement c'était juste une erreur Y dans la tentative de résoudre X).

Bon voici le cas d'utilisation :
J'ai essayé de faire mixn avec 3 paramètres si le dernier n'est pas donné, alors il devrait créer son attribut à l'intérieur du mixn c'est pourquoi les conditions étaient utiles.

Ici https://github.com/aukgit/WeReviewProject/blob/master/WereViewApp/Content/Less/remixens/responsive/responsive-placements.less j'avais essayé d'implémenter le même mixage encore et encore là où j'aurais pu y parvenir avec des conditions très facilement.

Je l'ai maintenant .. Merci à tous.

@aukgit Vous devriez pouvoir réduire facilement ces mixins.

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

Merci @matthew-dean d'avoir pris votre temps et de m'avoir aidé. :) Je suis super plein pour toi.

:)

Je pense que 'sass' vaut mieux que moins. Il a déjà if-else.

Les deux langues ont leurs propres problèmes.

Leur manque d'importations dynamiques - et leur réticence à l'implémenter - est la principale raison pour laquelle j'aimerais passer de Sass à Less. Less a cette fonctionnalité depuis des années !

Cependant, le manque de structures de contrôle traditionnelles (comme la boucle FOR ou les instructions IF-ELSE) et la syntaxe digne de grincer des dents sont ce qui m'empêche de faire ce pas.

Je me sens coincé entre le marteau et l'enclume...

@jslegers Même commentaire que dans #249. Less a diverses formes (de plus en plus dans la nouvelle version) de restrictions conditionnelles depuis v1.x.

@sept-phases-max

Je connais les mixins gardés comme alternative aux instructions IF et les mélanges récursifs comme alternative aux boucles dans Less. Mais c'est tout ce que j'ai pu trouver dans la documentation sur les structures de contrôle dans Less. Et en tant que personne ayant de l'expérience en programmation dans de nombreux langages, je trouve leur syntaxe déroutante et - pour être honnête - assez digne de grincer des dents.

S'il existe d'autres structures de contrôle que celles qui méritent d'être mentionnées, je n'ai pas pu les trouver dans la documentation.

Quoi qu'il en soit, quelque chose comme ...

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

... ou quelque chose comme...

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

... ou ca...

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

... dans Sass est bien plus lisible et bien plus élégant à mon avis que d'avoir à écrire quelque chose de similaire avec des mixins gardés ou des mixins récursifs dans Less.

L'absence de telles déclarations et la syntaxe globalement moins lisible de Less (par rapport à Sass) sont les deux principales raisons pour lesquelles je préfère m'en tenir à Sass et j'hésite même à envisager Less pour l'un de mes projets.

Et étant donné que Sass est devenu beaucoup plus populaire que Less, je ne suis clairement pas le seul à ressentir cela.

@jslegers Pour vos exemples - essayez d'apprendre ce qui est déjà disponible avant de les publier.
Pour le reste (popularité et ainsi de suite) - il est inutile de discuter de quelque chose de manière aussi simplifiée (Stylus a tout cela et alors quoi ?), d'ailleurs Less n'a jamais été déclaré pour remplacer d'autres préprocesseurs CSS ni pour devenir leur clone. Et enfin, l'erreur la plus courante est de penser que la popularité de quelque chose est le principal et le seul objectif des auteurs de ce quelque chose.

essayez d'apprendre ce qui est déjà disponible avant de les poster.

Essayez de mieux documenter ou de diriger les gens directement vers ce qu'ils recherchent, s'ils ne le trouvent pas.

Pour le reste (popularité et ainsi de suite) - il ne sert à rien de discuter de quelque chose de manière aussi simpliste [...] Et enfin, l'erreur la plus courante est de penser que la popularité de quelque chose est le principal et le seul objectif des auteurs de ce quelque chose.

Pour info, je n'ai jamais laissé entendre que la popularité est un indicateur fort de qualité ou d'utilité. En fait, bien souvent, c'est l'inverse.

Pourtant, si vous regardez pourquoi les gens passent de Less à Sass, c'est assez simple ...

Personnellement, je ne vois rien d'autre que l'habituel "Je veux mes spaghettis PHP" (voir les articles sur le mauvais outil ci-dessus), sans même compter son 2012 (j'ai déjà laissé entendre que la plupart de ces exemples sont assez compacts dans Less modernes, mais il semble que vous ne voulez pas vous réveiller).
Mais peu importe, d'habitude je ne fais valoir qu'une désinformation claire, les discussions d'opinions personnelles sur les raisons pour lesquelles quelque chose se produit ou ne se produit pas sont totalement hors de mon intérêt.

Personnellement, je ne vois rien d'autre que l'habituel "Je veux mes spaghettis PHP"

Il me semble qu'utiliser Less au lieu de Sass fait inévitablement ressembler votre code à du "spaghetti PHP" (si vous pensez que PHP est la quintessence du code spaghetti, vous n'avez évidemment jamais fait de programmation ABAP) dès que vous voulez faire quelque chose de plus complexe que les variables de base et les mixins, mais je suis prêt à considérer que je me trompe ici.

J'ai déjà laissé entendre que la plupart de ces exemples sont assez compacts dans Less modernes, mais il semble que vous ne vouliez pas vous réveiller

Alors pourquoi ne pas faire un effort pour me réveiller et me donner une source ou deux qui pourraient me soulager de mon ignorance ?

Il y a peu de choses que je trouve plus excitantes que quelqu'un qui me prouve que j'ai tort. D'après mon expérience, c'est la meilleure façon de grandir...