Less.js: Comment gérer les mathématiques des unités mixtes

Honnêtement, je n'ai jamais été fan de pouvoir mélanger des unités dans Less. Cela n'a aucun sens d'un point de vue mathématique, et comme vous le faites remarquer, tout est basé sur l'ordre d'évaluation... ce qui n'a pas de sens non plus.

Cependant, lorsque j'ai regardé le code strictUnits , cela n'avait aucun sens pour moi. Cela ne semble pas non plus faire ce que je pensais qu'il ferait.

Alors, oui, c'est bizarre, mais je ne suis pas enclin à le voir corrigé. Je suis plus enclin à voir disparaître les mathématiques en unités mixtes. Mais c'est juste moi. Comme le résultat de 1px * 1px devrait être 1px^2 (pas utile, mais vrai). Et le résultat de 1px / 1px devrait être 1 . Sass est trop complexe à propos de certains types de mathématiques, mais il utilise des principes mathématiques de base pour faire des choses comme changer d'unités d'unités de mélange. Par exemple.

<strong i="13">@value</strong> / 1px * 1rem
Le calcul ici est 10px / 1px . Cela devrait produire 1 (pas dans Less, juste en principe, et le ferait dans Sass). 1 * 1rem = 1rem . N'en déplaise à Alexis dans les origines de cette fonctionnalité, mais choisir la première unité d'une expression est juste un peu étrange, difficile à évaluer et peut conduire à ces cas extrêmes.

Juste mon 0,02 $.

Je pense que ce qui devrait arriver, c'est que, comme les changements en mathématiques, il y a un changement dans les unités mixtes de sorte qu'il y ait une troisième option entre les deux :

1. strictUnits: false - essaie de faire des maths et des unités de coercition
2. strictUnits: ? - par exemple 1px / 1px // output 1 , 100vh - 10px // output 100vh - 10px c'est-à-dire avec des unités mixtes, laissez l'expression telle quelle et la sortie - utile pour les sous-expressions affectées à vars et utilisées dans calc() - défaut futur ?
3. strictUnits: true - génère une erreur (je ne vois pas en quoi cela est utile.)

Le problème ne concerne pas les opinions personnelles sur le traitement des unités/arithmes. Il s'agit du compilateur qui ne suit pas sa propre documentation. (Pour le reste voir par exemple https://github.com/less/less.js/issues/1366#issuecomment-342361948).

Le problème ne concerne pas les opinions personnelles sur le traitement des unités/arithmes. Il s'agit du compilateur qui ne suit pas sa propre documentation

Ouais, je comprends. Mais en fin de compte, il s'agit de savoir comment le "réparer", n'est-ce pas ? Donc, je dis juste de manière détournée que je ne pense pas que cela vaille la peine d'être corrigé, et qu'à la place, cela devrait avoir un comportement plus intuitif. Mais ouais, c'est juste mon avis, mec.

@seven-phases-max Juste une note: j'ai réécrit la plupart des méthodes d'exploitation pour les unités, et ils avaient en effet des acrobaties étranges pour déterminer l'unité finale. J'ai fait en sorte que ce soit beaucoup plus simple lorsque l'unité de gauche gagne lorsque l'option de forcer les unités est l'option transmise.

(Il y avait quelques fils où des opinions différentes sur d'éventuelles améliorations d'unités strictes mais comme cela était répandu dans tout le tracker (ou du moins je ne peux pas trouver un fil dédié rapidement) je suppose que je sonne simplement la partie clé de :)
Mon avis personnel sur

strictUnités : ? - par exemple 1px / 1px // sortie 1, 100vh - 10px // sortie 100vh - 10px

est quelque chose comme : n'en vaudrait pas la peine (à cause du rapport résultat/efforts). En d'autres termes, il n'y a rien à améliorer en fait (sauf juste corriger les bugs évidents comme ci-dessus).

Notez que pour l'avoir vraiment générique (par opposition au codage de ceux-ci et de ces valeurs / modèles d'opérations / exemples minimalistes), vous devrez gérer correctement toutes les égalités arithmétiques habituelles et ainsi introduire des unités "imaginaires" comme px² et similaire. Par exemple, pour a: 1px; b: 2px; c: 4px; un résultat attendu de a*b/c (en acceptant évidemment (a*b)/c = a*(b/c) ) serait .5px ce qui signifie que le résultat de a*b doit être 2px² (au moins en interne).

Il y a d'autres problèmes de mise en œuvre (évidemment, il semblerait étrange de compter également des choses comme 1/1hz = 1s etc. mais formellement...) Compter en cents : j'avais dit que CSS Units est tout simplement trop gros pour le pousser sans raison (" juste parce que quelque chose comme 1px/1px = 1 semble intuitif").

strictUnits: true - génère une erreur (je ne vois pas en quoi cela est utile.)

Fondamentalement, si l'on n'aime pas la propagation d'unités et/ou les unités mixtes, il peut introduire un style de codage plus strict ne permettant pas une telle arithmétique (ainsi le strictUnits: true actuel est fondamentalement une option pour forcer ce style de codage).