Less.js: Comment gérer les mathématiques

Je ne pense pas que nous voulions changer les choses massivement ou revenir à la planche à dessin

Oui, j'ai suggéré de commencer cela uniquement parce que _si_ nous voulons des mathématiques strictes "par défaut" en 3.0, nous devrons inventer quelque chose de moins lourd que l'actuel (et une possibilité de résoudre tous les problèmes sans introduire de nouveau --alt-strict-math option font ...).

Je n'avais pas réalisé que sa croissance

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

:(

Je pense pour le moment que je suis favorable à l'expansion initiale de strictMaths pour être

• Désactivé
• Division
• Au

puis pour 2.0.0 définir la valeur par défaut sur Division

Alors..

Media Queries - si désactivé, passez à la division pour les sous-nœuds
Police - si désactivé, passer à la division pour le sous-nœud
calc( - si désactivé ou division, activer pour les sous-nœuds

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

Oui, je pense qu'ils sont en train d'autoriser les "valeurs abrégées" (c'est- x/y dire

connexe : https://github.com/less/less.js/issues/1480

Une autre option.. traiter les appels de calcul, mais uniquement lorsque les unités le permettent, par exemple
calc( 1% + 2%) => 3%
calc(100% - 10 px) => inchangé

Cela corrigera calc mais ne corrigera pas #1627 et les éléments connexes.
Je veux dire oui, calc(100% - 10 px) => unchanged pourrait être une solution pour le calc mais cela n'annule pas le besoin d'une solution less-heavy-than-parens-everywhere .

Si les mathématiques strictes sont revisitées, j'aimerais suggérer que les fonctions Less comme percentage() ne nécessitent pas de parenthèses supplémentaires à l'intérieur. Avec des mathématiques strictes, vous devez doubler l'argument. Cela réduirait considérablement la possibilité de confusion et de bogues difficiles à trouver, puisque percentage(16 / 17) et percentage((16 / 17)) seraient valides.

@calvinjuarez V2 fournit un sous-système de plug-in où un plug-in peut ajouter un nombre arbitraire de fonctions à l'environnement et, en ce sens, le noyau ne pourra pas décider si une telle fonction intégrée attend une valeur unique ou une expression, c'est-à-dire autorisé à accepter 16/17 , puis évaluer 16/17 _avant_ qu'il ne soit passé à une fonction serait incorrect (enfin, grosso modo - c'est un peu plus compliqué que cela en interne).

Dans ce contexte, le changement ./ semble être mon préféré même si je comprends que ce serait un changement très dramatique (si comparé à (/) , sans compter cela nécessite également un espace avant . , par exemple 16 ./17 et non 16./17 , hmm).

Une autre chose où moins de casse actuellement css valide est la sténographie d'arrière-plan :

background: url(image.png) 50%/300px no-repeat;

Je pense pour le moment que je suis favorable à l'expansion initiale de strictMaths pour être

Désactivé
Division
Au
puis pour 2.0.0 définir la valeur par défaut sur Division

Désolé de ne pas avoir répondu à cela avant la sortie de la 2.0. Je pense que c'est un bon instinct. Les opérateurs de division nus entrent simplement en conflit avec trop de CSS, et seront de plus en plus en conflit à mesure que les gens utilisent plus de fonctionnalités CSS3. Et je comprends la réticence des gens à ne pas exiger de parenthèses pour tous les mathématiques, car ce n'est pas nécessaire dans de nombreux cas.

@sept-phases-max

il est autorisé à accepter 16/17, puis évaluer 16/17 avant qu'il ne soit passé à une fonction serait incorrect

Strictement parlant, oui, c'est tout à fait correct. Cela ne doit pas être évalué AVANT d'atteindre la fonction, en particulier pour une fonction personnalisée. Cependant, je pense qu'il serait intelligent de permettre aux fonctions de choisir de traiter des arguments comme celui-ci, si cela a du sens. Ainsi, le pourcentage recevrait 16/17 comme argument de texte, puis la fonction de pourcentage pourrait appeler une fonction d'assistance pour voir si le texte est mathématique. Dans le cas du pourcentage, l'argument n'est pas ambigu. Une déclaration CSS3 n'est pas valable ici. Ainsi, d'autres fonctions définies par l'utilisateur pourraient fonctionner de la même manière : choisir d'évaluer les arguments pour les équations mathématiques valides. Par conséquent, il n'est pas nécessairement vrai que les mathématiques strictes "forcent" une double parenthèse dans ce cas. Je pense suggérer que cela provoque un certain recul sur l'idée de mathématiques strictes, qu'elles doivent, par nécessité, être verbeuses dans tous les cas.

Nos options --math pourraient ressembler davantage à :

• Toujours
• Division (par défaut)
• Strict

Ainsi, nous pourrions déprécier --strict-math=true et en faire un alias pour --math=strict

Cependant, je pense qu'il serait intelligent de permettre aux fonctions de choisir de traiter des arguments comme celui-ci, si cela a du sens.

Ils sont déjà autorisés (testez simplement comment percentage(16 / 17) et percentage((16 / 17)) fonctionnent avec --strict-math=on ).
Bien qu'aucune des fonctions n'utilise :

puis la fonction de pourcentage pourrait faire un appel à une fonction d'assistance pour voir si le texte est mathématique.

simplement parce que de cette façon, chaque fonction devrait avoir ces ~ 20 lignes supplémentaires de cette extra-helpers-conversion-arg-checking-smart-arg-handling-stuff alors que le code de la propre fonction n'est qu'une (!) ligne dans la plupart des cas.

Chaque fonction doit avoir 20 lignes supplémentaires ? Comment figurez-vous?

Si le pourcentage fonctionne déjà avec des parenthèses simples, alors je ne comprends pas le problème de

Chaque fonction doit avoir 20 lignes supplémentaires ? Comment figurez-vous?

C'est juste une exagération typique de : peut-être 5, peut-être 10, peut-être 20... Qui se soucierait des nombres exacts si le rapport code réel/code auxiliaire -> 0 . (En adoptant une approche pragmatique, je m'arrêterais à percentage(16 / 17) jetant simplement une erreur au lieu de produire NaN% (comme maintenant), et en n'essayant d'effectuer aucune conversion... Bien que même de cette façon, c'est toujours 4 lignes de code supplémentaires - enfin, moins ou plus acceptables je suppose :)

Ma réponse initiale impliquait qu'il supposait que cette conversion 16/17 -> (16/17) devait être effectuée implicitement par le compilateur lui-même (et non par la fonction).

En parlant d'options. Dans un monde parfait, je rêverais qu'il n'y ait aucune option pour cela (c'est-à-dire que ce devrait être le seul et le seul et le reste à marquer comme obsolète et finalement supprimé) ... Toutes ces options supplémentaires rendent la base de code non -maintenable... même pour une petite correction/modification d'une seule ligne, le nombre de cas extrêmes que vous devez prévoir et les tests que vous devez effectuer augmente de façon exponentielle... (presque sans raison).

Je pensais juste que ce serait quelque chose comme :

percentage: function(...) {
  Helper.convertMath(arguments);  // a function that doesn't need it doesn't call it
  // ... the rest
} 

En parlant d'options. Dans un monde parfait, je rêverais qu'il n'y ait aucune option pour cela

Je suis d'accord. Mais nous aurons besoin des options à court terme. Surtout si nous nous écartons des mathématiques strictes et du comportement hérité. Ils peuvent tous les deux être marqués comme obsolètes si nous perfectionnons une option « mathématiques plus intelligentes ».

Helper.convertMath(arguments);

arguments est trop optimiste.
Au mieux (en comptant pas seulement percentage - ce qui est de toute façon inutile , mais toute autre fonction attendant un argument numérique), une exigence minimale serait :

some: function(a, b, c) { 
    a = convert2number(a, "Error message when fails"); 
    // b is not a number for example
    c = convert2number(c, "Error message when fails"); 
} 

Mais ce n'était pas vraiment mon propos, ce que je voulais dire est probablement quelque chose comme : bien que cela soit/était toujours possible, personne ne prend la peine d'écrire un tel code... (à quelques exceptions limitées comme )...

Ouais, je te comprends.

percentage(16 / 17) vient de lancer une erreur

serait une amélioration, certainement. (Je ne peux pas penser à un moment où NaN% serait une sortie utile.)

En ce qui concerne les fonctions qui essaieraient d'être intelligentes dans leurs arguments, il n'y a aucune raison d'essayer de tout anticiper. Une fonction d'assistance comme le suggère @matthew-dean pourrait être implémentée assez simplement au fur et à mesure que les demandes de fonctionnalités sont faites et discutées pour que des fonctions spécifiques soient plus intelligentes.

En fait, dès le départ, je dirais que seules les fonctions mathématiques devraient être intelligentes quant à leurs arguments.

Edit : En fait, juste à chaque fois qu'une fonction mathématique reçoit un seul argument.

Quel est le statut à ce sujet ? Nous recevons des plaintes selon lesquelles LESS essaie d'analyser les propriétés CSS invalides en tant que mathématiques. par exemple lost-column: 1/3; pauses.

Il semble également que http://www.w3.org/TR/css-grid-1/#grid -template-rowcol ne fonctionnera pas avec LESS.

Quelqu'un peut-il corriger cela si quelqu'un veut explicitement utiliser LESS pour effectuer une division sur une propriété dont il a besoin de l'envelopper entre parenthèses ou quelque chose du genre ?

@corysimmons Ne

Une chose dont nous n'avons pas discuté la première fois. Il semble que le seul vrai conflit mathématique soit la division. Et la division est essentiellement un problème parce que nous « réaffectons » essentiellement un caractère de « séparation » CSS.

Plutôt que d'essayer d'« envelopper » la division de plusieurs manières, ou d'envelopper toutes les mathématiques (comme notre première solution à ce problème), je me demande pourquoi nous n'avons jamais parlé de l'évidence : _ne pas réutiliser un opérateur existant en premier lieu_, surtout quand il donc clairement a) rend le code Less ambigu, b) provoque un conflit.

Après que nous ayons eu le temps de digérer cela, mettre les mathématiques entre parenthèses, même s'il ne s'agit que d'une division, _toujours_ provoque une ambiguïté pour les cas où les mathématiques sont déjà entre parenthèses. (Ce qui aurait pu aussi signifier que les parenthèses étaient un mauvais choix de "math wrapper".)

Alors pourquoi ne pas déprécier / tant qu'opérateur de division ? Je sais que c'est un symbole de division commun, mais il existe d'autres compromis syntaxiques. Less a fait pour étendre CSS. Et il est clair pour moi maintenant que nous essayons essentiellement de contourner un problème créé par Less en premier lieu en utilisant la barre oblique unique. Nous créons une ambiguïté, puis tentons de renverser l'ambiguïté.

Pour être juste, les autres symboles mathématiques sont tous réutilisés dans d'autres parties de CSS, c'est juste que leur utilisation en mathématiques ne cause aucune ambiguïté.

J'allais proposer quelques idées, mais voilà, il existe déjà des caractères alternatifs standards à la division. A part ÷ , qui n'est pas sur le clavier, j'ai trouvé ceci :

Le signe de division est également mathématiquement équivalent au symbole de rapport, habituellement désigné par deux points (:) et lu "est à". Ainsi, pour tout nombre réel x et tout nombre réel non nul y , cette équation tient :

x ÷ y = x : y

En d'autres termes:

lost-column: 1/3;   //  value
lost-column: 1:3;   // division 

Je sais qu'il faudrait un peu de peaufinage de l'analyseur pour utiliser un deux-points en mathématiques, mais c'est mathématiquement correct, apparemment. Je ne peux pas penser à d'autres symboles qui feraient de meilleurs substituts. Peut-être | comme deuxième choix ? Ce serait quand même plus arbitraire.

Les pensées?

_Alternativement_, nous pourrions toujours prendre en charge le symbole de division entre parenthèses et/ou crochets, comme dans :

lost-column: 1/3;   //  value
lost-column: 1:3;   // division 
lost-column: (1/3);
lost-column: [1/3];

Oui, c'est pourquoi au départ j'ai commencé avec ./ (inspiré de l'opérateur Matlab vector-div, c'est deux syms mais visuellement c'est probablement le moins lourd à cause du point léger, bien que dans le contexte de Moins gâcher le point n'est pas une idée géniale).
: - Cela poussera à nouveau les marguerites, ce symbole est utilisé dans trop de contextes CSS. En fait, il y a déjà une syntaxe conflictuelle :

.foo(<strong i="9">@a</strong>: 1, <strong i="10">@b</strong>: 2) {
  result: <strong i="11">@a</strong> @b;  
}

bar {
    <strong i="12">@b</strong>: 4;
    .foo(<strong i="13">@b</strong>:3); // would mean both @second-parameter:3 and 4/3
}

@seven-phases-max Ah, oui, putain. SI SEULEMENT LES CLAVIERS ETAIT PLUS GRANDS. Oui, une séquence de 2 caractères pour la division semble inévitable. Cela faisait longtemps que je n'avais pas lu tout le fil, alors j'ai oublié ça. ./ C'est vraiment pas mal. Si vous et @lukeapage êtes tous les deux à bord, ce ne serait pas un mauvais compromis. Peut-être que nous passerons à l'étape de la proposition et verrons s'il y a des objections ?

Relisez, jusqu'à ce point :

sans compter cela nécessite également un espace avant . , par exemple 16 ./17 et non 16./17

Pas sûr d'être d'accord. Oui, 16. est un nombre valide, techniquement, mais ce serait bizarre pour quelqu'un de l'écrire de cette façon. Je pense que peu importe comment vous l'écririez, espace blanc ou non, il devrait diviser 16 par 17.

Il n'y aura pas d'option parfaite, mais je pense que c'est mieux que a) Utiliser / pour la division par défaut, b) toujours exiger des parenthèses. (Malgré mes positions dans le passé, j'en suis également venu à dire oui, c'est un peu ennuyeux, surtout entre parenthèses. Et surtout parce que ce n'est nécessaire qu'à cause de la division, à ma connaissance. Oui ?)

Je pense que peu importe comment vous l'écririez, espace blanc ou non, il devrait diviser 16 par 17.

Oui en effet.
Bien que j'y réfléchisse davantage, je m'attends ./ ce que ./ alors qu'actuellement, elle mange toujours la fin . ).

Et surtout parce que ce n'est nécessaire qu'à cause de la division, à ma connaissance. Oui?)

Oui, exactement. Sans compter le code à l'intérieur de calc - mais pour celui-ci, je suppose que la solution suggérée par @lukepage devrait faire l'affaire.

(Techniquement, à l'avenir, cela pourrait être une ambiguïté supplémentaire pour +, -, * s'ils restent à la syntaxe de leurs fonctions de manipulation des couleurs CSS - mais cela ne devrait pas être trop dramatique puisque les valeurs y ont la forme * 20% (donc ils peuvent clairement être détectés comme des expressions non moins évaluées. Après tout, ces divertissements auront besoin de quelques modifications d'analyse de toute façon, car actuellement des valeurs telles que (* 20%) provoquent une erreur d'analyse).

Peut-être que... nous avons tout faux. (M'incluant certainement dans ce que nous, puisque j'étais un fervent partisan initial de la fonctionnalité « mathématiques strictes ».)

Nous essayons de faire fonctionner les mathématiques de manière universelle, mais... ce n'est pas vraiment nécessaire. C'est-à-dire que nous essayons de faire des calculs dans les cas où il devrait être évident qu'aucun calcul ne doit être effectué.

L'exemple calc(100% - 10px) est le plus évident. Il n'y a pas de calcul de Less qui peut/doit être effectué à moins que nous ne lancions des unités, ce que je suis d'accord avec Less qui devrait arrêter de le faire, par défaut. ¹

Regardons la propriété raccourcie de police utilisée comme exemple.

font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif;
font: italic bold 12px/30px Georgia, serif;

La solution de contournement actuelle consiste à activer strict-math: on pour la propriété de police. Mais... pourquoi Less devrait-il faire des calculs en premier lieu ? Bien sûr, 13px/150% est un énoncé valide en mathématiques, mais est-il raisonnable de le traiter comme valide en Less ? 12px/30px vous _pourriez_ considérer comme un énoncé mathématique valide, mais devriez-vous le faire ? ²

C'est-à-dire : dans Less, les opérations mathématiques sur les unités doivent être effectuées par _integers_ et _floats_, pas par des unités. Nous les traitons comme des déclarations mathématiques valides, comme si les gens écrivaient réellement leurs mathématiques de cette façon. Mais je ne vois pas en quoi c'est peut-être vrai.

C'est-à-dire qu'il est raisonnable d'exiger que quelqu'un écrive 13px/150% sous la forme 13px/1.5 . Et même en ignorant le fait que 12px/30px n'aurait pas de sens en tant qu'opération mathématique, nous n'avons pas besoin de savoir que ce n'est pas le cas, et nous n'avons pas besoin d'ajouter font à la liste blanche . Si un auteur de Less effectuait une opération mathématique, il l'écrirait raisonnablement 12px/30 . Non seulement cela serait raisonnable, mais il est extrêmement probable que _comment ils l'écrivent en premier lieu_.

C'est courant pour moi d'écrire un mixin ou même d'utiliser quelque chose comme ça dans un seul bloc :

width: <strong i="5">@size</strong> / 2;
height: <strong i="6">@size</strong> / 2;

Pourquoi est-ce que je l'écrirais de cette façon ? Est-ce que _quelqu'un_ l'écrit de cette façon ?

width: <strong i="10">@size</strong> / 2px;
height: <strong i="11">@size</strong> / 2px;

L'opération _sort of_ a du sens si @size est une unité px , mais, quoi qu'il en soit, cela a moins de sens dans le domaine de LESS/CSS d'essayer de faire des maths dans ce dernier cas lorsque le diviseur est une valeur avec une unité. Le second ne ressemble pas à des maths. Cela ressemble à une valeur CSS.

Si nous arrêtions de faire des opérations mathématiques pour la multiplication ou la division (juste la division nécessaire pour l'ambiguïté, mais la multiplication également pour la cohérence logique) lorsque le multiplicateur ou le diviseur est une valeur avec une unité, je pense que ce problème disparaîtrait en grande partie. En revanche, les unités _sont_ logiques pour l'addition et la soustraction, mais n'ont probablement pas besoin d'être requises (c'est ainsi que c'est maintenant).

<strong i="18">@pad</strong>: 2px;
width: 10px + @pad; 

Mais lors de l'ajout / de la soustraction d'une valeur avec une unité à une autre avec une unité différente, Less doit le laisser seul.

<strong i="22">@val1</strong>: 100%;
<strong i="23">@val2</strong>: 10px;
width: calc(<strong i="24">@val1</strong> - @val2);

// output
width: calc(100% - 10px);

Exiger des unités correspondantes pour l'addition / la soustraction (ou un nombre entier / flottant) et exiger des nombres entiers / flottants dans les opérations mathématiques par rapport aux unités (aucune unité multipliée / divisée par des unités) résoudrait 99% des ambiguïtés et permettrait toujours des opérations mathématiques valides sans aucun nouveau symbole .

Par exemple, sur la base de ces règles, le raccourci d'arrière-plan conviendrait :

background: no-repeat 10px 10px/80% url("../img/image.png");

% est une unité CSS. px est une unité CSS différente. Donc pas de maths. L'exception spéciale serait un zéro.

background: no-repeat 0 0/80% url("../img/image.png");

Si quelqu'un semble diviser zéro par un autre nombre, ou diviser un nombre par zéro, je pense que nous pouvons en toute sécurité sortir tels quels.

Bordure-rayon, même chose :

border-radius: 30% / 20%;

Moins lui donnerait un laissez-passer. Si quelqu'un avait l'intention de faire des mathématiques, la façon appropriée de l'écrire serait :

border-radius: 30% / 0.2;

Ce qui est bien, c'est qu'en faisant ces distinctions, il devrait être évident qu'une opération mathématique _ne peut pas_ être une valeur CSS, puisque, comme dans l'exemple border-radius , une valeur CSS valide nécessiterait des unités des deux côtés. Il n'y aurait pas de chevauchement / ambiguïté.

Sauf un cas auquel je peux penser, et il peut y en avoir d'autres :

font: 10px/1.5;

Vous pouvez (et devriez généralement) représenter la hauteur de la ligne sous la forme d'un simple nombre. (Mais il ne faut probablement pas non plus utiliser de raccourci de police.) Mais si nous l'avons réduit à un cas, c'est plutôt bien. L'activation des mathématiques strictes pour font (sauf pour les fonctions internes dans la valeur de la police) est une bonne solution. (Je ne suis pas sûr qu'il n'y en ait pas de meilleur, mais cela fonctionne.) Et c'est toujours la solution la moins douloureuse, car ces valeurs abrégées de police apparaissent généralement dans les bibliothèques de styles d'interface utilisateur importées, les réinitialisations CSS ou les feuilles de style de police personnalisées.

Donc, il y a toujours une utilité pour les mathématiques strictes, mais je pense qu'avec ces changements, moins, et peut-être pas nécessaire comme option à l'avenir.

Je me réjouis des réponses/commentaires de la galerie.

¹ _J'ai réalisé que je devais préciser que les commentaires de @lukeapage et le lien de @seven-phases-max m'ont poussé à penser dans cette direction, pour aller plus loin._
² _Comme je l'ai compris en regardant des exemples, activer les mathématiques strictes pour la police peut être une solution inévitable, mais je pense que le reste de la logique s'applique._

Juste pour un certain contexte historique, il est important de noter que les unités de coulée lors de la première publication de Less.js n'étaient pas autant un problème. calc() n'a pas été implémenté et background et border-radius n'avaient pas de barres obliques comme valeurs valides. Je pense que font était le seul endroit qui a fait trébucher les choses (ce qui, ironiquement, peut toujours être le cas).

Ma seule préoccupation est le côté implémentation, par exemple : pour calc(4px + 2rem + 20%) (les unités réelles n'ont pas d'importance), le premier ajout donne un résultat non plus numérique, donc le deuxième gestionnaire d'ajout ne peut pas distinguer son entrée de quelle que soit l'instruction not-a-number + 20% où elle devrait générer une erreur. Pas un gros problème probablement (résolu en mettant des indicateurs de type/type supplémentaires), mais nécessite encore quelques recherches.

Et l'autre souci est euh, pas sûr, "redabilty" ? C'est-à-dire que si pour les nombres explicites le résultat est limpide, pour les variables, il commence à sembler assez ambigu, par exemple : border-radius: 10px <strong i="8">@a</strong> / <strong i="9">@b</strong> 30px; - vous ne savez jamais ce que cela signifie tant que vous ne voyez pas @a et @b définitions.

Et oui, font reste toujours un problème (probablement d'autres propriétés abrégées semblent utiliser des unités des deux côtés mais encore une fois nous ne savons jamais ce qu'elles proposent ensuite (en comptant également des choses comme #2769)... A quelques autres goodies comme font et ça recommencera à avoir l'air cassé).

PS Encore un problème (une régression mineure peut-être). Il y a des valeurs comme :

border-radius: 10px / auto;
border-radius: 1px inherit / 2px;
background: ... center / 80% ...;
// etc.

C'est-à-dire que pour que tout fonctionne, nous devrons désactiver toutes les erreurs d'opérande incompatibles en cours afin que tout foo/bar , 1x/bar et foo/1x puissent passer sans Erreur.

Ma seule préoccupation est le côté implémentation, par exemple: pour calc (4px + 2rem + 20%) (les unités réelles n'ont pas d'importance)

C'est ce que je dis. Les unités réelles devraient compter. Moins devrait laisser cela de côté, peu importe. 4px + 2rem a un sens dans le navigateur, mais n'a pas de sens dans Less. Il n'y a aucune raison d'essayer de l'ajouter lorsque cela n'a aucun sens et provoque ces problèmes de module complémentaire.

ex : border-radius: 10px <strong i="10">@a</strong> / <strong i="11">@b</strong> 30px ; - vous ne savez jamais ce que cela signifie tant que vous ne voyez pas les définitions @a et @b .

C'est un cas où nous ne pouvons pas sauver l'auteur du style d'eux-mêmes (même chose avec le premier exemple, si quelqu'un essayait réellement d'ajouter des rems aux pixels pour une raison quelconque). Je suis sûr qu'il existe toutes sortes d'exemples existants où quelqu'un pourrait écrire son code LESS pour être déroutant à suivre. Cela existe n'importe où.

Avec ces règles mathématiques que je propose, considérez :
calc(4px + 2rem - 2px)

Moins pourrait/calculerait cela comme calc(2px + 2rem) , ce qui est en fait parfaitement bien, et est en fait une sortie de valeur correcte. À l'heure actuelle, Less le calcule comme calc(4px) , ce qui n'est pas une réponse correcte ou utile. (Oui, c'est actuellement correct si nous laissons tomber des unités, mais les unités n'ont pas de sens et, sauf dans quelques cas, ne sont pas interopérables.) Less calcule 2px + 100% comme 102px , comme s'il y avait une valeur dans ce résultat, alors que personne ne le voudrait probablement comme résultat.

pour que le tout fonctionne, nous devrons désactiver toutes les erreurs d'opérande incompatibles div actuelles afin que tout foo/bar, 1x/bar et foo/1x puisse passer sans erreur.

Je pense que c'est en fait la façon la plus saine de le traiter. Comme les fonctions, s'il n'y a pas de résultat Less, alors il devrait passer. Étant donné que / est un séparateur valide pour plusieurs valeurs de propriété, Less ne peut pas savoir qu'il _n'est_ pas_ valide, à moins que nous n'ajoutions des valeurs en liste blanche pour des propriétés particulières. (Non.) À ce stade, le résultat n'est pas tragique. Si une valeur de transmission n'est pas valide dans le navigateur, elle est visuellement apparente. Il semble préférable d'essayer de transmettre la valeur au navigateur au cas où elle serait valide, plutôt que de lancer une erreur car Less n'est pas sûr.

Moins pourrait / voudrait calculer cela comme calc(2px + 2rem)

Je crains que cela ne le soit jamais car cela nécessitera un tout nouveau gestionnaire d'expression d'optimisation qui entraînerait une surpuissance (essentiellement, 4px + 2rem - 2px est stocké dans l'arborescence sous la forme (4px + 2rem) - 2px afin d'obtenir 2px + 2rem il doit s'agir d'un moteur de réorganisation pour essayer tous les mélanges valides (très simple dans ce cas particulier mais devenant assez complexe pour plus d'opérandes/opérateurs). Mais peu importe, laisser 4px + 2rem - 2px tel quel est bien (après tout si vous faites 4px - 2px + 2rem c'est optimisé).

Mais ce que je voulais dire avec cette remarque, c'est la chose semblable à :

de sorte que tout foo/bar, 1x/bar et foo/1x puissent passer sans erreur.

C'est-à-dire que (4px + 2rem) - 2px pour expr.evaluator serait similaire à foo + 2px , donc pour fonctionner, cela ne devrait pas générer d'erreurs pour ce genre de choses aussi.
En fait, j'ai testé foo/bar, 1x/bar, foo/1x et ils passent déjà sans erreurs (étrange, je pensais qu'ils jetaient), mais d'autres opérateurs entraînent toutes sortes de choses étranges (rien de vraiment critique cependant, juste une question de corriger chaque cas un par un).

Je crains que cela ne le soit jamais car cela nécessitera un tout nouveau gestionnaire d'expression d'optimisation qui entraînerait une surpuissance (essentiellement 4px + 2rem - 2px est stocké dans l'arborescence sous la forme (4px + 2rem) - 2px donc pour obtenir 2px + 2rem il a être un moteur de réorganisation pour essayer tous les mélanges valides (trivial dans ce cas particulier mais devenant assez complexe pour plus d'opérandes/opérateurs).

Pourquoi mélanger ? Vous aplatissez les opérateurs au même niveau de priorité (donc l'arbre est Sum(4px, 2rem, -2px) ), collectez les termes avec des unités compatibles (peut-être en normalisant les unités au préalable) et simplifiez chaque partie. C'est de l'algèbre symbolique, où les unités sont traitées comme des variables indépendantes.

J'aimerais l'écrire moi-même, mais il existe de nombreuses bibliothèques qui sont probablement mieux testées et plus susceptibles d'être complètes. Je parierais que certains compilateurs d'optimisation open source écrits en Javascript ont de tels sous-systèmes de simplification.

Le fait est que, bien que ce ne soit pas un problème facile à résoudre, le problème plus général est déjà assez bien résolu, et un tel sous-système pourrait être utile pour Less.js d'autres manières.

Vous aplatissez les opérateurs au même niveau de priorité (donc l'arbre est Sum(4px, 2rem, -2px)),

Et qu'est-ce qui fait exactement le code pour penser qu'un arbre d'expression est en fait aplati du tout ? (Donc, mon « suffling » ne concerne pas un algorithme de déduction spécifique, mais un raccourci pour « essayez-les tous », y compris votre « aplatir »).

mais il existe de nombreuses bibliothèques qui sont probablement mieux testées et plus susceptibles d'être complètes.

Je ne sais pas si vous êtes sérieux. Donc, vous pensez que tout ce code pour convertir Less tree en un arbre de bibliothèque externe et inversement (sans compter qu'aucune de ces bibliothèques JS ne peut gérer les unités CSS) vaut en fait ce cas spécifique 4px + 2rem - 2p à optimiser ? Hmm...

Donc, pas de problème du tout (je n'ai pas dit que c'était impossible, juste que ça n'en vaudrait jamais la peine) - essayez et les relations publiques sont les bienvenues.
(Aussi juste au cas où il est probablement important de noter que l'optimisation des sous-expressions n'est même pas l'objectif de ce ticket, même pas dans ses trois premiers).

Et qu'est-ce qui fait exactement le code pour penser qu'un arbre d'expression est en fait aplati du tout ? (Donc, mon « suffling » ne concerne pas un algorithme de déduction spécifique, mais un raccourci pour « essayez-les tous », y compris votre « aplatir »).

L'analyseur syntaxique détermine si le contexte est par exemple "longueur", et si le sous-arbre peut être interprété comme "longueur".

Je ne sais pas si vous êtes sérieux. Donc, vous pensez que tout ce code pour convertir Less tree en un arbre lib externe et inversement

Il doit être analysé dans un arbre syntaxique. À partir de là, il serait relativement simple de produire une chaîne représentant une expression algébrique. Revenir en arrière peut être plus difficile : il peut être nécessaire de l'analyser à nouveau à partir d'une chaîne, ou oui, il peut être nécessaire de prendre l'arborescence de la bibliothèque externe. La difficulté dépend de la bibliothèque choisie.

(sans compter qu'aucune de ces bibliothèques JS ne peut gérer les unités CSS)

Vous convertiriez simplement des unités en variables algébriques. Les substitutions (par exemple mm -> px ) peuvent même être effectuées alors que l'expression est sous forme symbolique.

vaut-il vraiment la peine d'optimiser ce cas spécifique 4px + 2rem - 2p?

Je fais une suggestion alternative pour l'optimisation des expressions qui est moins difficile (en tant que problème d'algorithme que le propre code de Less doit résoudre) et plus généralement utile que ce que vous avez dit était nécessaire.

La simplification algébrique peut résoudre les problèmes avec des sous-expressions entre parenthèses et permettre à Less d'ajouter plus de fonctionnalités mathématiques.

essayez et PR est le bienvenu.

J'essaierai. Je n'ai commencé à m'intéresser à Less qu'aujourd'hui et j'ai du mal à terminer des projets, alors j'admets que je ne sortirai probablement pas de RP.

Aussi juste au cas où il est probablement important de noter que l'optimisation des sous-expressions n'est même pas l'objectif de ce ticket, même pas dans ses trois premiers

Je sais. J'étais ici pour l'une des raisons. Pourquoi une telle morsure ?

Pourquoi une telle morsure ?

Eh bien, peut-être... Si c'est le cas - mes excuses (il semble que je sois trop choqué par les efforts et le temps que quelqu'un est prêt à consacrer pour résoudre un problème de calc(4px + 2rem - 2px) inexistant. Nous avons probablement une notion très différente de légèreté).

et permettez à Less d'ajouter plus de fonctionnalités mathématiques.

Pouvez-vous en nommer quelques-uns ?

pour résoudre à peu près le problème calc(4px + 2rem - 2px) n'existe pas

Hein? Moins ne peut pas du tout gérer ça. [reste supprimé car j'ai mal compris ce qui était abordé]

Pour simplifier / reformuler la proposition - les changements mathématiques seraient les suivants

1. L'addition et la soustraction ne seraient calculées que sur des unités similaires. par exemple 1px + 2px = 3px , 1px + 1vh = 1px + 1vh
2. La division et la multiplication ne seraient calculées qu'avec des diviseurs/multiplicateurs sans unité. par exemple 10px/2 = 5px , 10px/5px = 10px/5px
3. Les ratios de valeur sans unités seraient traités de la même manière que n ° 2. par exemple 1/3 = 1/3
4. Pour simplifier, les expressions avec des sous-expressions partiellement invalides peuvent être traitées comme une expression mathématique invalide et sorties telles quelles. par exemple 1px + 2vh / 2 = 1px + 2vh / 2

Cette proposition résout les problèmes suivants (à partir de ce fil) :

• font: 10px/5px et syntaxe (ratio) similaire (pas de calcul)
• calc(100vh - 30px) (pas de calcul)
• lost-column: 1/3 et syntaxe de ratio personnalisé similaire (pas de calcul)

Dans le même temps, ces changements préserveraient 99 % de l'utilisation typique de Moins de mathématiques. De plus, les fonctions unit() et convert() existantes permettent aux utilisateurs de convertir des valeurs en unités compatibles pour les mathématiques.

Moins ne peut pas du tout gérer ça.

Vous n'avez tout simplement pas lu ce que moi et @leewz parlions ci-dessus. Cela n'avait rien à voir avec calc(100vh - 30px) . Et mon « résoudre un problème pratiquement inexistant » se limite à « optimiser les expressions arithmétiques dans calc ».

@seven-phases-max Ohhh c'est ça. Pardon. Non, nous n'avons pas besoin d'optimiser. Il suffit de savoir quand faire des maths.

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité ne se produit. Merci pour vos contributions.

Suppression de l'étiquette ardoise car le problème est toujours important et ne fait qu'empirer à mesure que CSS évolue.

@matthew-dean
Je vais jouer l'avocat du diable un instant ici...

12px/30px vous _pourriez_ considérer comme un énoncé mathématique valide, mais devriez-vous le faire ?

Oui; tu devrais. Il calcule une valeur scalaire qui représente un rapport entre les deux tailles et qui peut être très utile lors de la conversion vers l'unité em.

Disons que j'ai une taille de police de base connue de 16px et une taille de titre connue de 24px, toutes deux cachées dans des variables, puis je souhaite attribuer une saveur particulière de titre avec la taille de police correcte, mais dans une unité em.

@fontsize-body    : 16px;
@fontsize-heading : 24px;

// ( ... and then somewhere else ... )

.heading {
  font-size : unit(@fontsize-body/@fontsize-heading, em);

  // Or if dividing compatible unit values is produces a unit-less scalar
  // value ( as it really _should_ -- mind you... ),  you could prefer:
  font-size : @fontsize-body/@fontsize-heading * 1em;
}

Et si vous devez prendre en charge la division d'unités compatibles en tant qu'expression mathématique, vous devrez continuer à prendre en charge un moyen de lever l'ambiguïté CSS à partir d'expressions mathématiques moins pour couvrir chaque moitié des cas.

Maintenant accordé, cela pourrait impliquer d'utiliser des parenthèses pour forcer une expression mathématique et de prendre un littéral CSS par défaut. Mais cela semble faux et sujet aux erreurs. Cela nécessite beaucoup de cas spéciaux pré-cuisinés tels que dans les raccourcis border-radius et font , et nécessite que Less se tienne continuellement à jour sur ces derniers. (Comme cela a été illustré par certaines des nouvelles propriétés de grille développant le même problème avec le signe de division.)

Alors...

Pourquoi ne pas inverser votre raisonnement ? Si quelque chose ressemble à une expression mathématique et qu'il a des unités compatibles, il sera traité comme une expression mathématique par défaut. Et si vous ne voulez pas que cela se produise... eh bien ; puis utilisez la trappe d'évacuation ~"..." . C'est exactement pour ça qu'il est là, après tout...

Ma vision actuelle de la proposition :

• Arrêtez de traiter / comme une division n'importe où, quelle que soit l'unité et quelles que soient les options (sauf si - facultativement - il est entouré de parenthèses redondantes comme avec -sm=on)
  Ainsi, seuls 1anything./3whatever et (éventuellement) (1anything/3whatever) sont évalués par Less.
• + , - et * restent inchangés
• calc sous-problème aucun arithmétique. expressions à l'intérieur de calc(...) (bien que, encore une fois, les parenthèses redondantes puissent aussi avoir leur effet).

@sept-phases-max

Le problème avec cela est que / est incroyablement enraciné en tant qu'opérateur de division. L'utilisation de tout autre symbole serait difficile à vendre aux utilisateurs. Vous prenez le cas d'utilisation général et le jetez pour le cas d'utilisation exceptionnel ( / en raccourci CSS) que presque personne n'utilise jamais.

@rjget

Le problème avec cela est que / est incroyablement enraciné en tant qu'opérateur de division.

Pas en CSS.

pour le cas d'utilisation exceptionnel (/ en abrégé CSS) que presque personne n'utilise jamais.

À l'heure actuelle, / est déjà beaucoup utilisé, et en comparaison, l'opération Less div est totalement beaucoup plus exceptionnelle que CSS / nos jours (contrairement à il y a quelques années à peine, où CSS / pouvaient être trouvés principalement dans font seulement).

@seven-phases-max Merci de rester au top. J'ai ajouté le bot Stale pour nous aider à gérer les problèmes et j'ai donné un temps assez généreux pour marquer l'obsolescence. J'ai également exempté deux étiquettes, "bug" et "up-for-grabs". Toutes les suggestions à ce sujet sont les bienvenues, telles que d'autres étiquettes à ajouter à la liste blanche. Le fichier est ici : https://github.com/less/less.js/blob/3.x/.github/stale.yml

Revenons au fil de discussion...

@rjget
Votre cas d'utilisation crée un problème arbitraire. L'argument est que c'est utile. Mais structurer vos variables de cette manière crée un problème évitable avec une syntaxe qui est, comme l'a souligné @seven-phases-max, ambiguë.

Même pris au pied de la lettre, avec CSS comme guide pour les principes Less, vous ne pouvez pas, en calc, diviser 12px par 30px. Le faire dans Less non seulement crée un problème d'ambiguïté, mais il rompt avec le modèle sans raison valable (autre qu'historique). L'une des choses qui manquent probablement à Less est juste un moyen d'extraire la valeur numérique d'une valeur unitaire afin que Less n'ait pas à faire cette magie mathématique pour la division.

Donc, la réponse simple est que votre exemple ressemblerait à quelque chose comme :

font-size : @fontsize-body/number(@fontsize-heading) * 1em

Mais je suis également d'accord avec la proposition de @seven-phases-max. Nous pourrions toujours évaluer _vars_ dans calc() , mais pas en maths. Et ne pas évaluer la division en dehors des parents. Je pense que c'est un bon compromis. Et, éventuellement, si vous vouliez conserver les mathématiques de division magique consistant à diviser une unité par une unité mais à conserver l'unité (ce qui est toujours étrange, mais c'est bien), cela pourrait se produire entre parenthèses.

Je sais qu'il y a quelques préférences différentes sur le sujet des mathématiques dans Less, mais je pense que ce serait vraiment génial si nous pouvions parvenir à un consensus sur quelque chose qui causait le moins d'effets secondaires et était le plus facile à raisonner sans causer un gros entretien ou le fardeau du développement.

Je pense que nous sommes tous sur la même longueur d'onde que l'approche actuelle (par défaut) des mathématiques dans Less est cassée. Et nous avions reçu des commentaires selon lesquels parens-tout par défaut était plus facile à raisonner, mais fastidieux. J'espère donc un bon compromis que nous pourrons bientôt mettre en place par défaut (probablement dans 4.0 ?)

Probablement l'une des choses qui manque à Less est juste un moyen d'extraire la valeur numérique d'une valeur unitaire

La fonction unit fait cela si vous ne spécifiez pas de deuxième paramètre. Mais c'est plus un effet secondaire du fait que les scalaires sont actuellement implémentés avec un type de nœud Dimension qui n'a pas d'unité définie.

Accordé; cela va loin, mais si vous voulez vraiment éviter de diviser les dimensions qui ont des unités compatibles, alors arracher l'unité fonctionnerait.

J'ajouterais également que je suis fortement contre toute supposition sur les "unités compatibles" (comme laisser a/b rester une division et b/c ne pas l'être) dans ce contexte particulier.
Simplement parce que:

• une manipulation exceptionnelle est la racine de tous les maux (par exemple # 3047 - voir ci-dessous, http://stackoverflow.com/questions/19705791- Je me souviens que je n'ai pas pu trouver la raison du problème SO jusqu'à ce que j'aie parcouru chacune des zillions de lignes du code Less impliqué dans un débogueur).
• et le plus important, ce n'est tout simplement pas à l'épreuve du temps, c'est-à-dire que si un changement majeur est inévitable, nous ferions mieux de nous assurer de le faire une fois (et idéalement pour toujours)... et pas comme s'ils ajoutaient une nouvelle fonctionnalité CSS impliquant a/b et c'est à nouveau cassé.

Donc, pour moi, les "unités compatibles" ressemblent plus à des choses totalement indépendantes et orthogonales (il pourrait y avoir des discussions sur les unités résultantes avec ou sans -su , mais c'est une autre histoire).

(hors sujet:)
Et d'ailleurs, en parlant des exemples ci-dessus :
@rjgotten si vous avez :

@fontsize-body/@fontsize-heading * 1em; 

quelque part dans votre code et l'une des deux variables est px vous utilisez réellement un bogue :)
Le bon code est :

1em * @fontsize-body/@fontsize-heading;

Cela donne toujours une unité bien définie par http://lesscss.org/features/#features -overview-feature-operations (en comptant #3047 à corriger, le bogue est encore une fois un exemple de bogue produit exactement par trop deviner le code autour des « unités compatibles » dans la base de code). Pas vraiment besoin de --su , number , unit bla-bla... Comportement actuel de -su comme "il suffit de lancer une erreur si vous voyez des unités incompatibles" , c'est-à-dire une simple validation, est plus que bien (pour moi). Je ne vois aucun besoin de 1px/2px->.5 et de 1px*2px->2px^2 de suringénierie mambo-jambo. Mais encore une fois, c'est une autre histoire sans rapport).

@sept-phases-max

en fait en utilisant un bug

Euh... ouais ; tu as raison, bien sur. Heureusement, je n'ai ce code en production nulle part. C'était juste un exemple rapide jeté ensemble pour illustrer le point.

J'ajouterais également que je suis fermement opposé à toute supposition sur les "unités compatibles" (comme laisser a/b rester une division et b/c ne pas l'être) dans ce contexte particulier.

Je pense que j'étais d'accord avec cela plus comme un rameau d'olivier pour ceux qui veulent des diviseurs nus. Mais je pense que votre commentaire [ ici ] est la proposition la plus réalisable. C'était l'intention initiale des « mathématiques strictes », d'éliminer l'ambiguïté. Je pense que la préoccupation est devenue des opérations au sein de mixin et des appels de fonction menant à toutes sortes de parenthèses dans les parenthèses. Mais, en général, je suis avec vous que les efforts pour rendre les mathématiques faciles dans Less ont également, ironiquement, rendu les choses très difficiles, en raison de l'ambiguïté accrue.

De plus, j'ai réalisé plus tard que font: 10px/3 est un raccourci valide. Il n'y a donc vraiment aucune solution algorithmique qui puisse y aider.

Pour revenir à votre question, @rjgotten...

Pourquoi ne pas inverser votre raisonnement ? Si quelque chose ressemble à une expression mathématique et qu'il a des unités compatibles, il sera traité comme une expression mathématique par défaut. Et si vous ne voulez pas que cela se produise... eh bien ; puis utilisez la ~"..." trappe d'évacuation. C'est exactement pour ça qu'il est là, après tout...

L'idée/la relation de Less à CSS est similaire à TypeScript à JavaScript. C'est-à-dire, renommez votre .css valide en .less et vous pouvez commencer à ajouter moins de fonctionnalités. Semblable à la façon dont vous pouvez renommer .js en .ts et commencer à ajouter des fonctionnalités TypeScript. Si vous n'ajoutez rien, vous devriez obtenir en sortie le même Less / JavaScript valide, car les langues sont des sur-ensembles de la langue de base.

Cependant, dans le cas de ces ratios ou d'autres diviseurs / en CSS, Less échoue déjà dès le départ, par défaut. Votre CSS normal devient arbitrairement une expression Less math avec un résultat différent, même si vous n'avez rien changé. Cela viole le contrat de la langue. Être capable de changer votre .less en une expression Less totalement différente afin de récupérer le CSS d'origine avec lequel vous avez commencé manque l'essentiel. Ce travail ne devrait jamais être exigé. Less ne devrait pas vous obliger à changer votre CSS valide en expressions Less compatibles afin de récupérer le CSS valide que vous aviez en premier lieu. C'est juste un modèle cassé.

Le même raisonnement s'applique à calc() . Oui, vous pouvez échapper vos expressions par chaîne, mais vous ne devriez pas avoir à le faire. .css renommé en .less devrait produire le même CSS efficace. Cela devrait être l'objectif de base du projet, ne pas interférer/écraser/surinterpréter la feuille de style d'origine. Tout le reste essaie de pousser le problème sur le développeur pour aucun autre péché que d'utiliser l'analyseur/langage en premier lieu.

Oui, vous pouvez échapper vos expressions par chaîne, mais vous ne devriez pas avoir à le faire. .css renommé en .less devrait produire le même CSS efficace. Cela devrait être l'objectif de base du projet, ne pas interférer/écraser/surinterpréter la feuille de style d'origine. Tout le reste essaie de pousser le problème sur le développeur pour aucun autre péché que d'utiliser l'analyseur/langage en premier lieu.

Cette.

LESS sait où le / est autorisé et où il n'est pas en css. Là où ce n'est pas le cas mais apparaît quand même, cela devrait supposer que les maths sont faites. De plus, lorsque les mathématiques sont entourées de parenthèses arrondies, où les parenthèses arrondies ne sont pas autorisées dans CSS, elles doivent être interprétées par LESS.

En d'autres termes, LESS devrait essayer d'interpréter le moins possible les mathématiques pour obtenir un css valide. Dès que la sortie est valide, arrêtez d'exécuter d'autres calculs.

@thany

Trop d'hypothèses sur ce que le compilateur sait (et certaines d'entre elles sont tout simplement fausses).
Quoi qu'il en soit, le mode "les parenthèses" est presque ce que fait --sm=on , alors utilisez-le et oubliez ce fil (probablement vous n'utilisez tout simplement pas de mathématiques dans vos projets à côté de calc des années après la conception de Less) afin que vous ne puissiez pas voir à quel point les parenthèses supplémentaires sont ennuyeuses. Mais d'autres le font.)

Pour le reste, voir https://github.com/less/less.js/issues/1880#issuecomment -345194431.

@seven-phases-max N'oubliez pas que le / également un sens dans les raccourcis background et border-radius , et peut-être d'autres auxquels je ne pense pas pour le moment. LESS les traitera volontiers comme une division. Avec ou sans mode mathématique strict, LESS devrait "savoir quand s'arrêter" de faire ses propres petits calculs.

@thany
LESS devrait « savoir quand s'arrêter » en faisant ses propres petits calculs.

Non, ça ne devrait pas. Il n'y a aucun moyen de savoir où les futurs raccourcis CSS avec la barre oblique de division vont apparaître. Le fait que le compilateur Less « sache » à ce sujet est une approche fondamentalement erronée et c'est précisément ce à quoi cette discussion tente de trouver une solution.

De plus, il existe deux choix raisonnables et prévisibles pour / tant qu'opérateur de division :

• Traitez-le toujours comme tel et exigez un échappement explicite pour d'autres utilisations.
  Cela brisera le comportement où Less syntax est un sur-ensemble strict de la syntaxe CSS.
• Ne le traitez jamais comme un opérateur de division, __à moins__ qu'il se trouve dans un contexte mathématique connu.
  Où le contexte mathématique connu pourrait/serait décidé comme dans le comportement actuel de --strict-math=on .

_{(Aussi ; veuillez noter que le nom Less n'est plus orthographié en majuscules.)}

N'oubliez pas que le / a aussi un sens en arrière-plan et en abréviation de rayon de bordure,

C'est essentiellement par cela que commence ce fil.
Et consultez le résumé des modifications proposées sur https://github.com/less/less.js/issues/1880#issuecomment -345194431 (sans aucune hypothèse sur ce que le compilateur devrait ou ne devrait pas savoir).

Non, ça ne devrait pas. Il n'y a aucun moyen de savoir où les futurs raccourcis CSS avec la barre oblique de division vont apparaître. Le fait que le compilateur Less « sache » à ce sujet est une approche fondamentalement erronée et c'est précisément ce à quoi cette discussion tente de trouver une solution.

Je suis entièrement d'accord avec cela. @thany Bien que vous soyez d'accord avec moi dans ce que vous avez cité de ce que j'ai écrit, vous arrivez à une conclusion différente de celle que je ferais. Moins ne devrait pas et ne peut pas savoir quand "arrêter de faire des maths". Ce que je dirais, c'est que le changement décisif devrait être que Less est plus conservateur au sujet de commencer les mathématiques (pour utiliser l'américain/canadianisme) en premier lieu.

@rjget

Ne le traitez jamais comme un opérateur de division, sauf s'il se trouve dans un contexte mathématique connu.
Où le contexte mathématique connu pourrait/serait décidé comme dans le comportement actuel --strict-math=on.

Juste pour clarifier, cette partie (avec laquelle je suis d'accord):

Ne le traitez jamais comme un opérateur de division, sauf s'il se trouve dans un contexte mathématique connu.

A en fait 4 solutions possibles, que je sais que vous connaissez, mais en résumant juste pour le fil:

1. Faites tous les calculs uniquement entre parenthèses . Cela a apparemment été rejeté par les communs, ce qui est bien, bien qu'il soit toujours disponible en tant que bascule facultative ( strictMath ).
2. Faites tous les calculs partout, mais divisez uniquement entre parenthèses.
3. Faites tous les calculs partout, mais divisez uniquement entre parenthèses. Sauf si l'opérateur de division est imprimé sous la forme ./
4. Faites tous les calculs partout, mais corrigez les calculs pour que 12px/4px n'entraîne pas de division. (Multiplication et division uniquement avec des valeurs sans unité.) En d'autres termes, division partout, mais avec des règles beaucoup plus conservatrices. Dans les cas où cela ne résout pas les choses, revenez à la fuite. Donc, pas une solution complète, mais toujours une amélioration (discutable) par rapport à la situation actuelle.

Du point de vue de la convivialité, j'aime rendre les mathématiques "plus intelligentes" comme dans #4 . Du point de vue de l'ingénierie et de la maintenance, et pour se protéger contre les futurs changements CSS, j'aime #3 comme la solution la plus robuste.

Cependant, je pense qu'en réalité, nous aurions besoin de faire à la fois #3 ET #4 afin de réparer calc() . À l'heure actuelle, moins ignorer toutes les unités lorsque vous faites des mathématiques est un vrai gâchis. 100vh - 12px ne doit jamais être touché par Less (parenthèses ou non). Mais l'OMI ne devrait pas non plus 12px/4px (parenthèses ou non), mais je suis peut-être minoritaire sur ce point.

Donc, je ne vois pas tant cela comme un problème de « mathématiques en conflit avec la syntaxe CSS » que de Less étant beaucoup trop agressif avec la résolution prématurée des équations mathématiques pour commencer.

Multiplication et division uniquement avec des valeurs sans unité.

ça ne va pas faire l'affaire puisqu'il y a des choses comme :

font: small-caps bold 24px/3 ...;
lost-column: 1/3;
// etc.

et ce ne sont pas des divs.

Cependant, je pense qu'en réalité, nous aurions besoin de faire à la fois #3 ET #4 afin de réparer calc()

calc() est une douleur. Ironiquement, il est _probablement_ mieux résolu en l'implémentant en tant que fonction Less réelle, qui prendrait idéalement son arbre d'expression analysé et tenterait de simplifier l'expression. C'est-à-dire : il doit pré-calculer et combiner des composants compatibles tels que 4px + 12px (ou 4px + @a lorsque @a est connu pour avoir une valeur de pixel) mais laisser des composants incompatibles, par exemple ceux avec des unités incompatibles, seul.

Par exemple

<strong i="17">@a</strong> : 4px;
<strong i="18">@b</strong> : 2;
width : calc(100%/<strong i="19">@b</strong> - 10px + @a);

devrait éventuellement rendre

width : calc(50% - 6px);

(en me répétant de https://github.com/less/less.js/issues/1880#issuecomment-345345735)
Et je ne vois aucun avantage à sur-engineering du compilateur afin d'optimiser les expressions à l'intérieur de calc . Si vous écrivez calc alors vous pouvez utiliser le navigateur pour faire le travail quelle que soit l'expression longue que vous avez là. Donc, comme déjà mentionné ci-dessus, je suis pour "ne touchez à rien à l'intérieur de calc " (= n'essayez pas d'être plus intelligent que ce qui est vraiment nécessaire) et laissez-le pour le navigateur ( ou pour un css-minifier depuis , si je me souviens bien, certains d'entre eux font déjà du bon travail sur l'optimisation des sous-expressions calc).

Le "comportement intelligent de l'unité mamabo-jambo" me rappelle les monstres min/max (pile gonflée de code non maintenable et jamais utilisé ) - à quel point je regrette de ne pas avoir crié contre les "unités mambo" à l'époque , oh (Je vais donc continuer à pleurnicher ici jusqu'à ce que l'idée même de "sémantique d'opérateur différente en fonction des unités d'opérande" soit totalement annihilée :P).

PS Dès que calc devient une fonction recevant une expression non évaluée arithmétiquement (il le devra de toute façon), on pourra écrire un plugin et le surcharger avec l'optimisation souhaitée.

@rjget
Avoir le compilateur Less « savoir » à ce sujet est une approche fondamentalement erronée

Je pense que c'est une approche fondamentalement correcte . LESS est un compilateur pour CSS, il est donc tout à fait logique que LESS sache sur quoi il compile.

@matthew-dean
Moins ne devrait pas et ne peut pas savoir quand "arrêter de faire des maths". Ce que je dirais, c'est que le changement décisif devrait être que Less est plus conservateur au sujet de commencer les mathématiques (pour utiliser l'américain/canadianisme) en premier lieu.

Intéressant que vous pensiez de l'autre côté, pour ainsi dire. Voici ce que je propose :

background: url(...) no-repeat 50% 50% / 40px + 10px 40px;

Ce que LESS devrait faire ici est évident pour moi :

background: url(...) no-repeat 50% 50% / (40px + 10px) 40px;

Résultant en:

background: url(...) no-repeat 50% 50% / 50px 40px;

Il ne devrait pas calculer la partie 50% / 50px , car (1) il ne devrait pas pouvoir le faire à cause d'unités incompatibles et (2) parce que c'est déjà assez loin pour une background . C'est donc là que ça va "arrêter de faire des maths".

C'est ce que je voulais dire par MOINS "savoir quand s'arrêter".

S'agissait-il d'une propriété différente comme celle-ci :

padding-left: 50% / 10px + 5px;

Il devrait rompre avec une erreur (unités incompatibles). Une sortie possible serait 50% / 15px qui n'est pas valide pour cette propriété. Un autre résultat pourrait être 5% ce qu'il fera actuellement, ce qui est tout simplement faux dans tous les sens.
Et:

padding-left: 50px / 10px + 5px;

Devrait se traduire par :

padding-left: 10px;

Comme prévu. Donc, dans ce cas, le / est invalide pour padding-left et est pris dans LESS et fait ses calculs.

@matthew-dean
A en fait 4 solutions possibles, que je sais que vous connaissez, mais en résumant juste pour le fil:

Un de plus:
5) Utilisez l'opérateur \ pour les divisions dans LESS, et dépréciez en utilisant / . MATLAB a quelque chose comme ça, et certaines versions de BASIC l'ont utilisé pour forcer la division entière. L'utilisation de la barre oblique inverse n'est donc pas complètement inconnue.

/Éditer
Nous pouvons également faire pression pour inclure une clé ÷ sur les claviers et l'utiliser comme opérateur de division. C'est celui que j'ai appris à l'école primaire :)

Ce que vous proposez a déjà été discuté plusieurs fois auparavant (n'hésitez pas à regarder les fils de discussion référencés ici). Voici donc juste des commentaires minuscules paresseux :

Utilisez l'opérateur \ pour les divisions dans LESS, et dépréciez en utilisant / .

https://github.com/less/less.js/issues/1872#issuecomment -35245890

assez pour un background ... est invalide pour padding-left

Rencontrez les "Les gars, mon navigateur/polyfill/whatever a juste ajouté/mis à jour/étendu la prise en charge d'une propriété fnord , voulez-vous s'il vous plaît publier une nouvelle version Less pour moi ?" publier.
Rencontrez le problème font .
etc.
Eh bien, @rjgotten a déjà

@sept-phases-max
La barre oblique inverse n'était qu'une suggestion. Vous pourriez aussi bien utiliser le ? pour la division. Cela n'a pas vraiment d'importance. Ce que je suggère, je suppose, c'est de ne pas utiliser un seul caractère ( / ) qui a des significations très différentes et ambiguës.

Rencontrez les "Les gars, mon navigateur/polyfill/whatever vient d'ajouter/mettre à jour/étendre la prise en charge d'une propriété fnord , voulez-vous s'il vous plaît publier une nouvelle version Less pour moi ?" publier.

CSS est une norme bien définie. Vous ne devez rien prendre en charge en dehors de la norme. C'est votre problème, je pense. Vous ne devez pas prendre en charge la propriété fnord , car elle ne fait partie d'aucune norme. Lorsque cette nouvelle propriété non spécifiée se produit, LESS peut revenir à son comportement par défaut, qui peut être le comportement actuel, ou nécessitant des parenthèses, ou quoi que ce soit d'autre tant qu'il n'est pas ambigu.

Rencontrez le problème de la police.

Le problème des polices prouve que le problème / existe depuis les débuts absolus de LESS. Pas seulement quand background eu la possibilité d'inclure une valeur pour background-size ou quand border-radius est apparu. Tbh, en énonçant le problème de police, vous venez de faire le meilleur argument contre vous-même :)

Tbh, en énonçant le problème de police, vous venez de faire le meilleur argument contre vous-même :)

Je pense que tu comprends mal quelque chose. C'est moi qui / tant qu'opérateur div. Donc, pour le reste des choses, je suppose que c'est le même problème si vous ne faites pas attention à ce que l'on vous répond.

CSS est une norme bien définie.

Si vous comptez vous en tenir aux pièces de spécification qui ont atteint leur pleine maturité au niveau TR, peut-être.
Autrement? Non ce n'est pas. Il existe des spécifications satellites de nouveaux « modules » CSS et des révisions de modules existants avec de nouveaux ajouts qui apparaissent mensuellement, voire hebdomadairement.

@sept-phases-max

ça ne va pas faire l'affaire puisqu'il y a des choses comme : font: small-caps bold 24px/3 ...

Non, je comprends. Mon point était exactement le suivant : seule la division/multiplication sans unité diminue le problème mais ne résout pas le problème.

Et je pense qu'en général, votre suggestion de ./ pour toutes les divisions semble toujours assez logique.

@thany Plutôt que de répondre à tous les exemples spécifiques, je dirai qu'en général, les efforts pour rendre Moins de maths plus intelligents se contenteront de lancer le ballon sur une ligne de yard différente. C'est toujours les mêmes problèmes, juste à un endroit différent. Comme @seven-phases-max l'a dit, rien de ce que vous avez suggéré n'a été discuté.

Et je ne vois aucun avantage à sur-engineering considérablement le compilateur afin d'optimiser les expressions à l'intérieur de calc. Si vous écrivez calc, le navigateur vous convient pour faire le travail, quelle que soit l'expression longue que vous avez là. Donc, comme déjà mentionné ci-dessus, je suis pour "ne touchez à rien à l'intérieur de calc" (= n'essayez pas d'être plus intelligent que ce qui est vraiment nécessaire) et laissez-le pour le navigateur (ou pour un css-minifier puisque, si je me souviens bien , certains d'entre eux font déjà du bon travail sur l'optimisation des sous-expressions calc).

Je suis entièrement d'accord avec cela. Nous éliminerions 99 % des nouveaux problèmes liés aux mathématiques si nous ajoutions simplement calc() à la liste blanche. Bien que j'aie suggéré quelques moyens pour Less de faire des maths plus intelligemment pour éviter AUSSI les problèmes de calc() (ce qui devrait peut-être être le cas), je m'excuse si cela a été interprété comme un argument contre cette idée. Je soutiens cela aussi.

La seule mise en garde (comme discuté ici/ailleurs) est qu'un développeur voudra inévitablement utiliser des variables dans calc() , nous devons donc faire attention à nous assurer de continuer à échanger des vars, mais ne le faites pas math. Je ne sais pas à quel point c'est difficile. Si nous parvenions à le faire, je soutiendrais un changement dans la gestion de calc() aujourd'hui.

@thany

Le problème de police prouve que le problème / existe depuis les débuts absolus de LESS.

C'est peut-être vrai et c'est juste, mais il existait de nombreuses solutions de contournement appropriées et ce n'était pas nécessairement une pratique courante à l'époque d'utiliser le raccourci de propriété font . C'est vraiment parce que plusieurs arrière-plans et calc() sont arrivés après le démarrage de Less que cela a rendu cela plus problématique, et maintenant la syntaxe CSS Grid signifie qu'il y a maintenant une tonne de conflits là où il n'y en avait initialement aucun dans la pratique quotidienne.

D'ailleurs, voici comment Sass résout le problème, illustré par cet exemple :

p {
  font: 10px/8px;             // Plain CSS, no division
  $width: 1000px;
  width: $width/2;            // Uses a variable, does division
  width: round(1.5)/2;        // Uses a function, does division
  height: (500px/2);          // Uses parentheses, does division
  margin-left: 5px + 8px/2px; // Uses +, does division
  font: (italic bold 10px/8px); // In a list, parentheses don't count
}

Ce n'est pas un un-à-un, puisque vous pouvez faire des mathématiques (actuellement) dans les arguments des fonctions Less, ET les fonctions Less peuvent renvoyer des valeurs de pixels (donc Less pourraient faire font: print10px()/8px , théoriquement ? non ?), donc je Je le colle simplement à titre illustratif, pas comme une sorte de suggestion. C'est juste intéressant de voir comment ils ont abordé le problème.

Personnellement, je pense que faire en sorte que les développeurs essaient de se rappeler dans quels cas les mathématiques se produiront en fonction de l'existence d'expressions magiques est un peu fou (comme être précédé d'un + ?), mais à chacun son propre .

Personnellement, je pense que faire en sorte que les développeurs essaient de se rappeler dans quels cas les mathématiques se produiront en fonction de l'existence d'expressions magiques est un peu fou

+1

_{Sans même compter que la "solution" ne résout lessc --sm . Et des résultats différents pour 1/2 et $var/2 c'est juste un résultat incroyablement brillant... ~stupidité~ "Bon débogage, les perdants !"}

@matthew-dean
D'ailleurs, voici comment Sass résout le problème, illustré par cet exemple :

C'est une solution brillante sans recourir à un opérateur différent.
Si l'expression est éventuellement un CSS valide, laissez-la.

Personnellement, je pense que faire en sorte que les développeurs essaient de se rappeler dans quels cas les mathématiques se produiront en fonction de l'existence d'expressions magiques est un peu fou

Être en désaccord. C'est un simple ensemble de règles, pas différent des autres ensembles de règles (fous ou non) dont vous devez vous souvenir.

Il y a quelques cas extrêmes où les mathématiques se produisent sans le vouloir, mais vous appliquez simplement des parenthèses et vous avez terminé.

Sans même compter que la "solution" ne résout aucun des problèmes discutés ici au-delà de ce que lessc --sm fait déjà. Pourquoi écrirais-je 0 + 1/2 au lieu de (1/2) alors que ce que je veux n'est qu'une division ? Et des résultats différents pour 1/2 et $var/2 sont juste une stupidité phénoménale... "Bon débogage, les perdants !" message.

Ha, oui, ça.

@thany

C'est une solution brillante sans recourir à un opérateur différent.
Si l'expression est éventuellement un CSS valide, laissez-la.

Pas pour entrer dans les mauvaises herbes, mais ça ne va pas marcher pour Less, pour des raisons syntaxiques et aussi de cohérence linguistique. C'est peut-être génial pour Sass, ce que je dirais est discutable, mais je ne suis pas personnellement impliqué dans ce projet du point de vue de la conception, alors qui peut le dire. Tout ce que je sais, c'est que les options sur la table sont le meilleur endroit pour commencer, et je suis convaincu que si vous passiez autant de temps à parcourir certains des fils de discussion liés à ce problème et passiez du temps avec la langue, vous viendrez à la même conclusion.

Une observation à laquelle nous ne pouvons pas échapper : si vous importez du CSS vanilla valide, sa sortie devrait être fonctionnellement identique. Donc, la seule conclusion que je peux tirer est que LESS ne devrait pas toucher aux expressions qui sont déjà éventuellement des CSS valides. Comment cela est fait, ne dépend pas de moi. Mais il n'en reste pas moins que l'importation de CSS vanilla n'est pas fiable, principalement en raison de l'exécution trop rapide des divisions par MOINS.

L'importation de CSS vanille dans Sass fonctionne pratiquement sans problème, car comme dit, Sass laisse l'opérateur / seul s'il n'indique pas au compilateur d'aller faire des choses, selon quelques règles de syntaxe simples. Ces règles de syntaxe décrivent des façons de forcer une division qui ne peut pas se produire dans un CSS vanille valide, et c'est pourquoi c'est génial.

Vous vous disputez toujours avec votre propre imagination et non avec ce qu'ils vous disent. Répondez à la question simple : "Comment 0 + 1/2 peut-il être meilleur que (1/2) ?". Si la compatibilité 100 % CSS est la seule chose qui vous importe, définissez le joli -sm et oubliez ce fil.

Une observation à laquelle nous ne pouvons pas échapper : si vous importez du CSS vanilla valide, sa sortie devrait être fonctionnellement identique. Donc, la seule conclusion que je peux tirer est que LESS ne devrait pas toucher aux expressions qui sont déjà éventuellement des CSS valides. Comment cela est fait, ne dépend pas de moi. Mais il n'en reste pas moins que l'importation de CSS vanilla n'est pas fiable, principalement en raison de l'exécution trop rapide des divisions par MOINS.

Cette partie, je suis essentiellement d'accord avec, et je pense que vous trouverez beaucoup d'accord dans ce fil sur ce point. La plupart des désaccords ont porté sur des solutions, chaque solution ayant divers effets secondaires.

Je serais d'accord pour faire ces changements de rupture en priorité :

1. maths en dehors des parenthèses nécessitant ./ au lieu d'un / nu. 12px./10px toujours l'air un peu bizarre.

@seven-phases-max - Je veux revoir la barre oblique inverse. À ce sujet, je sais que vous avez mentionné https://github.com/less/less.js/issues/1872#issuecomment -35245890, mais je ne vois aucun conflit pur et simple, car ces identifiants ne le sont pas et je pense qu'ils ne peuvent pas être partie des expressions mathématiques. Ou ai-je tort? Je suppose qu'il est possible de proposer un cas théorique comme un nom de fonction avec un caractère échappé dans le nom, mais cela ressemble plus à un exercice intellectuel qu'à un cas réel. Sélecteurs échappés, oui, ceux-ci sont couramment utilisés pour diverses raisons, mais dans les valeurs de propriété, il semble tout simplement peu probable ou, dans un cas limite, il est possible de rompre / contourner la solution de contournement historique (échapper simplement à ce texte).

Pouvons-nous explorer un peu plus le fait que l'utilisation d'une seule barre oblique inverse pour la division provoquerait des conflits dans le monde réel ? Mon instinct est que \ est moins problématique que la situation actuelle autour de / , et c'est plus convivial que ./ . Si nous avons fait la recherche et trouvé que c'était faisable, alors nous pourrions faire le changement radical pour l'utiliser partout, au lieu de changer de contexte autorisant / entre parenthèses. Et puis nous pourrions prendre en charge / avec un commutateur hérité.

1. (deuxième priorité) calc() étant dans une casse spéciale afin qu'il puisse effectuer un remplacement de variable mais n'évaluera aucune expression mathématique

Pouvons-nous explorer un peu plus le fait que l'utilisation d'une seule barre oblique inverse pour la division provoquerait des conflits dans le monde réel ?

Eh bien, le problème que \anycharacter est un CSS valide et a sa propre signification. Bien sûr, vous trouvez à peine un tel code dans de vrais projets (sauf peut-être les hacks de type \9 ), mais... voulons-nous nourrir ce lion ? Corriger un "uh-oh, mon CSS 100% valide ne compile pas" en introduisant un autre "uh-oh" du même semble un peu bizarre :)

En ce qui concerne calc je suppose que nous avons eu un consensus dès le début - il n'attend donc qu'un volontaire pour l'implémenter (j'estime que la solution rapide doit être effectuée en seulement 5 à 6 lignes de nouveau code - donc il ne s'agit vraiment que d'un homme courageux pour faire cela - les détails mineurs de mise en œuvre peuvent varier, mais je pense qu'ils peuvent être décidés en cours).

Eh bien, le problème que \anycharacter est un CSS valide et a sa propre signification. Bien sûr, vous trouvez à peine un tel code dans de vrais projets (sauf peut-être les hacks de type \9), mais... voulons-nous nourrir ce lion ? Corriger un "uh-oh, mon CSS 100% valide ne compile pas" en introduisant un autre "uh-oh" du même semble un peu bizarre :)

Je vous entends, c'est un compromis possible. Et oui, je sais que \anycharacter est un CSS valide. Je suppose que je me demande si c'est un meilleur ensemble de compromis. C'est juste que quand j'ai écrit 12px./10px ça me paraissait bizarre, syntaxiquement. J'ai l'impression que Less a essayé syntaxiquement de réutiliser CSS autant que possible sans créer de conflits.

Par exemple, ./ fournit une clarté de syntaxe et évite complètement les conflits, mais il en va de même pour l'application de parenthèses partout pour les mathématiques, c'est pourquoi je l'ai soutenue, mais il y a eu un contrecoup, et cela m'inquiète ici. Existe-t-il donc un cas légitime où nous confondrions 10px\10 avec l'intention du développeur d'échapper à \10 ? Je sais que c'est une théorie difficile, et votre point serait probablement que nous ne savons pas vraiment ..... C'est une question compliquée, et l'ajout d'une nouvelle syntaxe est toujours lourd, surtout avec Less car nous ne connaissons pas tous les CSS dans le CSS sauvage ni futur.

En ce qui concerne calc, je suppose que nous avons eu un consensus dès le début - il n'attend donc qu'un volontaire pour l'implémenter (j'estime que la solution rapide doit être effectuée en seulement 5 à 6 lignes de nouveau code - il ne s'agit donc vraiment que d'un brave homme de le faire - les détails mineurs de mise en œuvre peuvent varier, mais je pense qu'ils peuvent être décidés en cours).

Bon! Devrions-nous le suivre séparément pour augmenter la visibilité ?

@seven-phases-max :

Bien sûr, vous trouvez à peine un tel code dans de vrais projets (sauf peut-être les hacks de type \9 )

Exact . Oh ces "occidentaux" bosselés... :)

@sept-phases-max
Répondez à la question simple : « Comment 0 + 1/2 peut-il être meilleur que (1/2) ? »

Je ne vois pas où tu veux en venir. (1/2) doit être exécuté par LESS car il ne peut pas s'agir d'un CSS valide, il doit donc être considéré comme LESS. 0 + 1/2 devrait devenir 1/2 où LESS exécute la partie 0 + 1 car c'est la partie qui ne peut pas être un CSS valide. La partie 1/2 pourrait être valide, alors mieux vaut ne pas y toucher.

@thany
OK, réalisez maintenant que (1/2) fonctionne comme vous l'attendez dans Less et Sass..
Et 0 + 1/2 (ainsi que 1 * 1/2 etc.) est la partie de la solution que vous appelez brillante ci-dessus et le résultat "la solution brillante" est 0.5 .
Toujours aucune idée de ce qui se passe ici ?
Relisez tout (à partir de votre premier message) ci-dessus une fois de plus et essayez de vous répondre "De quoi exactement je me plains ?".

@sept-phases-max
Et 0 + 1/2 (ainsi que 1 * 1/2, etc.) est la partie de la solution que vous appelez brillante ci-dessus et le résultat "la solution brillante" est de 0,5.

Non, la solution serait 1/2 non 0.5 , car 1/2 pourrait être un CSS valide. Vous ne semblez pas vouloir que LESS sache quand une barre oblique est valide, alors supposez qu'elle pourrait toujours l'être. Par conséquent, 1/2 est le seul résultat logique. De la même manière, 2 * 1/2 donnerait 2/2 , car le * rendrait autrement le CSS invalide.

Toujours aucune idée de ce qui se passe ici ?

Je comprends parfaitement ce qui se passe ici. LESS exécute les divisions mathématiques avec empressement et ignore aveuglément les unités.

Relisez tout (à partir de votre premier message) ci-dessus une fois de plus et essayez de vous répondre "De quoi exactement je me plains ?".

Il n'y a pas besoin d'attaques personnelles.

LESS exécute les divisions mathématiques avec empressement et ignore aveuglément les unités.

C'est donc de cela que vous vous plaignez, n'est-ce pas ?

Il n'y a pas besoin d'attaques personnelles.

Alors que dois-je faire à la place ? Répéter les deux messages originaux encore et encore (et encore) ? Jusqu'à ce que vous compreniez :
@communauté :

utilisez l'option -sm

@thany :

alors il devrait être activé par défaut.

@seven-phases-max :

Cela ne peut pas être parce que cela briserait immédiatement des millions de projets. Donc, si vous traitez le comportement par défaut comme un problème, définissez simplement l'option documentée et terminez.

Donc vous répétez "ça devrait", "ça devrait", "ça devrait" en attendant quoi ? Je suppose que pour nous, il est plus facile de répondre simplement « Non, cela ne devrait pas » au lieu de perdre notre temps à essayer d'expliquer en détail pourquoi ce que vous suggérez ne fonctionnera pas ou n'a aucun sens en général (les explications que vous ne voulez pas non plus comprendre ou tout simplement pas).

Alors de quoi parle ce fil ? Il s'agit de « réaliser que bien qu'un éventuel changement radical consistant à créer un comportement par défaut de type -sm est inévitable, nous devons fournir des facilités pour une arithmétique plus confortable autre que l'effroyable : margin: (1/2) (3/4) (5/6) (7/8); pour ceux qui utilise beaucoup l'arithme".
Vos messages ici suggèrent quelque chose qui n'est pas du tout meilleur que (ou font exactement la même chose que) -sm comportement déjà existant ou argumentent avec quelque chose qui est hors de question dès le début (comme là ). En d'autres termes, juste un bruit aléatoire .

@seven-phases-max @thany Faisons

Je pense que la plupart des gens sont sur la même longueur d'onde que ces deux éléments ne sont idéalement pas interprétés par Less comme une expression mathématique :

font: 12px/10px;
width: calc(100% - 20px);

Donc, il y a surtout un accord sur ces points, et la plupart des arguments portent sur des solutions possibles. Le problème calc() semble avoir suffisamment de consensus pour aller de l'avant. Fondamentalement : ne touchez pas à calc et traitez les variables dans calc() comme une interpolation de chaîne. C'est à peu près comme cela que Sass procède, bien que cela nécessite la syntaxe d'interpolation dans calc() , dont je ne pense pas que nous ayons besoin.

Les solutions de la partie font deviennent beaucoup plus floues et les principales solutions ont été :

1. Exiger des parenthèses pour tout par défaut (première tentative - presque implémentée, mais la communauté a rejeté)
2. Retournez le commutateur strictMath (qui a été ajouté au lieu d'en faire la valeur par défaut, et la suggestion de @seven-phases-max), puis faites explicitement tous vos calculs. C'est, techniquement, une solution possible pour la plupart des gens à l'heure actuelle, mais... la question revient si souvent et nous savons, psychologiquement, qu'une personne nouvelle dans n'importe quel système conserve probablement les valeurs par défaut, donc c'est problématique. Et tous les développeurs ne peuvent pas modifier leurs paramètres de build, en particulier dans les équipes.
3. Changez essentiellement l'opérateur de division dans Less. Le principal concurrent dans le fil a été ./ , ce qui fonctionne mais est un peu étrange à regarder. \ est une inconnue à ce stade sans recherche. Pourrait fonctionner, pourrait provoquer des conflits inconnus avec l'échappement. C'est une syntaxe plus propre, à un risque (potentiellement, mais inconnu) plus élevé. Si quelqu'un prend le temps de démontrer que cela ne provoquera PAS de conflit, c'est-à-dire en fournissant des exemples d'échappement et de mathématiques entremêlés de manière à ce que l'analyseur puisse clairement distinguer les deux, alors c'est toujours une possibilité. Donc, il suffit de travailler. @thany , si vous ou quelqu'un d'autre êtes fan de cela, alors c'est le travail requis. La dernière chose que nous voulons, c'est simplement déplacer les pauses ailleurs.

Je pense que, pour simplifier ce fil, nous devrions, à partir de là, nous concentrer JUSTE sur #3 . J'ai posté l'exemple de Sass principalement par curiosité, mais je ne pense pas que ces solutions soient bonnes ou résolvent complètement le problème, et elles sont conceptuellement incompatibles avec Less. Débattre de la validité d'exiger 0 + 1/2 ne nous mènera nulle part.

Ainsi, avec une bonne solution sur la table pour calc() , ce qui nous permet d'

Si l'opérateur de division Less doit être modifié, en quoi doit-il être modifié ?

• ./ - est-ce aussi gênant que je le pense, ou les gens pensent-ils que c'est bien ?
• \ - sans recherche et preuves, et sans pseudo-code pour qu'un analyseur suive, cela n'avancera pas. Personnellement, je le préférerais, s'il peut être prouvé qu'il est sûr.
• D'autres remplaçants ?

Honnêtement, si nous modifions calc() et modifions / , je pense que nous atténuerions 99% du bruit autour des mathématiques dans Less.

Salut à tous, j'ai corrigé calc() - https://github.com/less/less.js/pull/3162

J'ai été un peu étonné quand j'ai trouvé une solution qui fonctionnait sans beaucoup de code complémentaire. Fondamentalement, nous avions déjà du code pour le commutateur strictMath et des expressions pour ne pas évaluer les mathématiques si elles étaient en dehors des parenthèses, j'ai donc juste ajouté un commutateur supplémentaire sur l'appel pour désactiver les mathématiques tout en évaluant le calc() args, puis de nouveau. Nous avions déjà toutes les pièces pour laisser les maths tranquilles, mais toujours remplacer vars. Hein.

Consultez https://github.com/less/less.js/pull/3162/files#diff -a94aaffd78b1d3c5eda7a42d5be1ca0d et https://github.com/less/less.js/pull/3162/files#diff -4e696271823c96903a91fff84983bab6

Les tests sont-ils suffisants ?

@matthew-dean :café:

Les tests sont-ils suffisants ?

par commentaires dans le PR, ajoutez s'il vous plaît un test comme :

foo: 1 + 2 calc(3 + 4) 5 + 6; // expected result: 3 calc(3 + 4) 11;

Et une petite remarque : ce correctif introduit évidemment le même problème qu'en #1627, c'est-à-dire

<strong i="13">@a</strong>: floor(1.1);
<strong i="14">@b</strong>: floor(1 + .1);

div {
    foo: calc(<strong i="15">@a</strong> + 20%); // ok
    bar: calc(<strong i="16">@b</strong> + 20%); // error: invalid floor arguments
    baz: @b;             // ok
}

Mais pour calc ça va, je suppose (après tout, il n'y a tout simplement pas d' autres moyens simples de le réparer sans refaire en profondeur le concept d'évaluation paresseuse). Je pense donc qu'il suffit de mettre un avis dans la documentation pour garder à l'esprit lazy-eval lors de l'utilisation de vars dans calc .

Et une petite remarque : ce correctif introduit évidemment le même problème que dans #1627

Bonne prise!

Changer la propriété de contexte mathOn par appel résout ce problème, similaire à votre commentaire dans le PR. J'ai ajouté un test pour float(1 + .1) qui passe !

La commutation de la propriété mathOn de contexte par appel résout ce problème, similaire à votre commentaire dans le PR. J'ai > ajouté un test pour float(1 + .1) qui passe !

:) Non, l'erreur "floor" doit être présente lorsque -sm: off . Voir mon nouveau commentaire dans le PR.
La restauration ne prend en charge que les choses de type 1 + 2 calc(3 + 4) 5 + 6 .

:) Non, l'erreur "floor" doit être présente lorsque -sm: off.

Pourquoi? Toutes les fonctions à l'intérieur d'un calc() devraient être des fonctions Moins. Même s'ils ne le sont pas, à ma connaissance, il n'y a pas de fonctions natives CSS dans calc() qui puissent prendre des expressions mathématiques brutes. Le résultat attendu serait d'évaluer les fonctions vars et Less, mais de laisser les fonctions brutes dans calc() seules.

Remarque : j'ai fait une expérience de branche en passant de / à \ tant qu'opérateur de division dans Less. Il y a déjà beaucoup de tests pour s'échapper (et j'en ai ajouté d'autres, à l'adresse : #3160), et ils fonctionnent toujours bien, et les mathématiques fonctionnent bien avec les opérateurs commutés. Je n'ai vu aucun conflit inhérent. La branche est ici sur mon fork : https://github.com/matthew-dean/less.js/commit/509d34fff7e234846afa150b099cd259755a39d0

Re : fonctions imbriquées

Pour ça:

div {
    bar: calc(floor(1 + .1) + 20%);
}

En tant que développeur, le résultat attendu doit être :

div {
    bar: calc(1 + 20%);
}

C'est exactement ce qui se passe maintenant (avec ces changements). Il ne devrait pas générer d'erreur.

@matthew-dean
Non, la façon dont vous l'avez écrit, ceci :

foo: unit(1/2, px);

avec -sm:on compilera vers :

foo: .5px;

^- faux.
Idem pour les fonctions imbriquées. De plus, le fait que la plupart des fonctions ne peuvent généralement pas prendre d'expressions arithmétiques comme argument n'est pas une raison pour violer -sm: on ;
Ainsi sous -sm: on deux lignes :

foo: floor(1 + .1);
bar: calc(floor(1 + .1) + 20%);`

doit générer une erreur (et c'est ce qui est cassé dans le commit).

De quoi parles-tu?

unit(1/2, px) avec -sm:on :

ERROR: error evaluating function `unit`: the first argument to unit must be a number. Have you forgotten parenthesis?

calc(floor(1 + .1) + 20%) avec -sm:on

ERROR: error evaluating function `floor`: argument must be a number

Découvrez la succursale. Essaye le.

Une chose qui pourrait être plus utile lors de la révision du code est que si vous n'êtes pas sûr que quelque chose produira une sortie incorrecte, veuillez le vérifier. Ou demandez-moi d'essayer une entrée spécifique pour vérifier qu'elle fonctionne comme prévu. Ou posez des questions si vous ne savez pas comment/pourquoi cela fonctionne. Appeler ça mal sans savoir si c'est pas utile.

Mes excuses. Je suppose que j'ai raté le contrôle indirect de cette partie .

Découvrez la succursale. Essaye le

Je ne peux pas, désolé.

Mes excuses. Je suppose que j'ai raté le contrôle indirect de cette partie.

Pas de soucis. Une fois cela réglé, cela semble-t-il fonctionner comme vous le souhaiteriez ?

Une fois cela réglé, cela semble-t-il fonctionner comme vous le souhaiteriez ?

Oui, jusqu'à présent, je ne peux pas imaginer d'autres choses suspectes là-bas.

@matthew-dean
Changez essentiellement l'opérateur de division dans Less. Le principal concurrent dans le fil a été ./, qui fonctionne mais est un peu étrange à regarder. \ est une inconnue à ce stade sans recherche [...] @thany , si vous ou quelqu'un d'autre êtes fan de cela, alors c'est le travail requis. La dernière chose que nous voulons, c'est simplement déplacer les pauses ailleurs.

Pas du tout en fait. J'ai suggéré l'opérateur \ en dernier recours après ne pas avoir réussi, en essayant de faire en sorte que LESS ne fasse que ses propres calculs. Si un nouvel opérateur de division est ce qu'il faut... Eh bien, calc() peut aussi faire des additions, des soustractions et des multiplications. De nouveaux opérateurs pour ceux-là ? Je pense que ce n'est pas pratique. Un nouvel opérateur de division peut être une solution pour des choses comme la police, l'arrière-plan et le rayon de bordure, mais ce n'est pas une solution pour les mathématiques CSS.

Je pense toujours que la vraie solution est que MOINS connaisse le contexte. Il devrait (oui, je recommence avec mon "devrait", quel autre mot dois-je utiliser?...) savoir que calc() est une fonction CSS et qu'il ne devrait évaluer que des mathématiques que CSS ne peut pas faire . Mais floor() n'existe pas dans CSS, de sorte qu'il devrait l'évaluer (entièrement) pour ne pas cracher de CSS invalide. Je pense que cela a déjà été mentionné, dans une formulation différente.

Je pense toujours que la vraie solution est que MOINS connaisse le contexte. Il devrait (oui, je recommence avec mon "devrait", quel autre mot dois-je utiliser?...) savoir que calc() est une fonction CSS et qu'il ne devrait évaluer que des mathématiques que CSS ne peut pas faire. Mais floor() n'existe pas dans CSS, il devrait donc l'évaluer (entièrement) pour ne pas cracher du CSS invalide. Je pense que cela a déjà été mentionné, dans une formulation différente.

Assez juste re: \ , mais en ce qui concerne le contexte, sur la base de vos autres messages, je peux garantir que c'est un problème beaucoup plus complexe que vous ne le pensez. Il faut vraiment se résumer à :

12px/10px  // Is this division, or not?
10px/1.5 // is this division, or not? 

Si vous voulez définitivement laisser / comme opérateur de division, pour imiter calc() , et qu'il ne soit pas ambigu, alors vous devez absolument vous assurer que le / est dans parenthèses (sauf exception calc() ). Cela fournirait un contexte prévisible.

Cette suggestion au début de ce fil est également toujours une possibilité et a reçu un solide soutien. Essentiellement, que le paramètre par défaut soit que toutes les mathématiques soient prises en charge en dehors des parenthèses SAUF la division (et encore une fois, sauf calc() , c'est maintenant le cas à partir de 3.0+). C'est peut-être la voie à suivre. Cela permettrait :

font: 10px/1.5;   // not division
font: (10px/10);  // division, result is 1px
font: 10px+15px/1.5;   // addition but not division, result is 25px/1.5
font: (10px+15px/1.5);  // result is 20px

Le fait est que le résultat pour 10px+15px/1.5 peut toujours être difficile à comprendre pour les développeurs, avec une expression qui semble être "à moitié évaluée" à moins qu'elle ne soit entre parenthèses. Si nous avions activé les mathématiques strictes par défaut, cela aurait probablement été bien. C'est encore moins ambigu. [haussement d'épaules] Quoi qu'il en soit, envelopper les mathématiques dans une sorte de contexte EST le moyen d'éliminer l'ambiguïté, et le seul moyen de division autre que de changer l'opérateur de division.

La communauté doit essentiellement décider de la direction. Il y a des options viables dans ce fil. Chacun a des inconvénients. Chacun a des points douloureux. Aucun n'aura un consensus complet. Mais l'OMI n'importe lequel d'entre eux est meilleur que le scénario actuel. Je dois juste avaler cette pilule.

Dernier appel pour une décision

Donc, dans un effort pour travailler l'impossible, j'aimerais proposer que nous fassions cela (en se référant aux commentaires d'il y a 3 ans.)

Donnez --strict-math 3 paramètres

1. désactivé
2. division
3. strict (alias on pour la rétrocompatibilité)

Pour régler le débat, permettez au commutateur --strict-math=division d'effectuer les opérations suivantes :

1. N'effectuez pas de division avec seulement le caractère / dehors des parenthèses. Par exemple border-radius: 55px / 25px; --> no-math (oui, c'est du CSS valide)
2. Autoriser la division avec deux méthodes différentes :
   une. . préfixe - border-radius: 55px ./ 25px;
   b. parenthèses - border-radius: (55px / 25px);
3. Les deux formes sont valides entre parenthèses - par exemple, border-radius: (55px ./ 25px); serait valide

Ainsi, en tant que développeur, si vous pensez qu'une version n'est pas votre préférence, vous pouvez utiliser l'autre. Certains peuvent préférer ne pas utiliser de parenthèses ; certains peuvent préférer ne pas utiliser un opérateur de division modifié. Quelque chose pour tout le monde. Et plus de mauvaises surprises pour ceux qui découvrent Less en utilisant ce qui est maintenant une syntaxe répandue en CSS, avec le / utilisé dans font , background , border-radius , @media requêtes, propriétés CSS Grid, et probablement plus à l'avenir.

Prochaines étapes

Je recommande que cela aille dans un PR en tant qu'option, puis, comme discuté, passe par défaut pour une future version majeure

@matthew-dean

C'est-à-dire que la période agit un peu comme l'inverse d'une séquence d'échappement ?
Pas une mauvaise idée, vraiment...

Et tout bien considéré, _probablement_ l'une des solutions les plus propres possibles.

@rjgotten a commencé ici : https://github.com/matthew-dean/less.js/tree/strict-math-division

J'obtiens toujours une erreur étrange lors de l'un des tests, où il semble transformer l'un des nœuds de dimension en nœud d'opération (et génère ensuite une erreur car il ne peut pas effectuer d'opération sur un nœud d'opération. Cela ne semble pas être un problème d'analyse, car un autre test ne s'exécutant pas sous strictMath: division fonctionne correctement. Voulez-vous le vérifier et voir si vous pouvez aider ?

Ce que j'aimerais faire, c'est fermer ce problème et créer de nouveaux problèmes qui traitent les questions de mathématiques restantes. Spécifiquement:

1. Division de la manutention, et la fonctionnalité strictMath: 'division' .
2. Gestion des mathématiques des unités mixtes. Voir : https://github.com/less/less.js/issues/3047