Less.js: Les propriétés personnalisées à l'intérieur des fonctions intégrées telles que `rgba()` renvoient une erreur

Il suffit de s'échapper .

J'ai mis l'étiquette "Demande de fonctionnalité" car cela devient définitivement un problème lorsque les propriétés personnalisées sont dans TR. C'est facile à corriger en désactivant toute détection d'erreur pour les fonctions CSS args (bien que ce soit assez triste car cela tue une partie importante du langage - c'est-à-dire que nous ne trouverons plus d'erreur avant le débogage dans un navigateur).

Les propriétés personnalisées sont prises en charge sur tous les navigateurs, à l'exception d'IE11. Ils vont probablement arriver dans le courant de l'année prochaine, donc je pense que le support devrait être mis en œuvre bientôt.

Moins, AFAIK, n'a pas non plus de tests pour la nature extrêmement permissive des valeurs de propriété personnalisées. Ils peuvent contenir à peu près n'importe quoi, même des points-virgules, tant qu'ils ne sont pas des jetons de niveau supérieur (non contenus dans des paires de crochets ou d'accolades). Voir : https://www.w3.org/TR/css-variables/#syntax

Étant donné que ce changement nécessite de toute façon une vérification n-of-args (pour conserver au moins une validation d'erreur dans les fonctions), il est également supposé que la nouvelle implémentation rgba prend également en charge la forme à deux arguments pour les valeurs de couleur ordinales, par exemple :

rgba(var(--some), .42); // -> rgba(var(--some), .42)
rgba(#010101, .42); // -> rgba(1, 1, 1, .42)

Comment devrions-nous gérer les propriétés personnalisées dans args en général ? Techniquement, vous pouvez utiliser var(--some-property) peu près n'importe où, et si Less essaie d'interpréter les arguments pour les fonctions CSS intégrées comme rgba() , c'est un problème. Bien que je ne sache pas pourquoi Less lance des erreurs de valeur strictes pour une fonction CSS intégrée? Juste pour soutenir les expressions ?

Je vois tout un tas de fonctions CSS intégrées sur https://github.com/less/less.js/blob/master/lib/less/functions/color.js#L34 , et l'IMO la plupart ne devraient pas Soyez là. Less n'est pas un linter, et ce ne sont pas des fonctions de Less. Si l'analyseur essaie de devenir super intelligent avec les fonctions CSS, il échouera. Je pense donc que c'est la source du problème, que Less est actuellement en train de patcher les fonctions de couleur CSS régulières plutôt que de les laisser passer.

Je ne sais pas si cela a été ajouté pour les navigateurs qui ne prennent pas encore en charge rgb() rgba() ? On dirait qu'il a été ajouté il y a 4 ans. Peut-être que la raison était d'ajouter un équilibre aux nouvelles fonctions de couleur qui ne sont pas encore prises en charge dans les navigateurs ? 🤔 @lukeapage es-tu toujours là pour répondre ?

Compte tenu de mon commentaire à #3214, pour ce problème, la solution rapide serait simplement : "if (nargs < 3/4) fallback to css string (en ne retournant rien)" dans les implémentations de fonctions correspondantes.

(Et une solution plus stricte consiste à vérifier chaque argument dans chaque fonction de ce type pour décider s'il est évaluable et à renvoyer un objet de couleur ou une chaîne CSS de secours).

Compte tenu de mon commentaire à #3214, pour ce problème, la solution rapide serait simplement : "if (nargs < 3/4) fallback to css string (en ne retournant rien)" dans les implémentations de fonctions correspondantes.

Et un chèque similaire de var() ?

darken(rgba(var(--red-value), 2, 3, .4), 5%)

C'est-à-dire : devons-nous procéder comme suit :

1. Autoriser la transmission des fonctions si elles ne correspondent pas aux n-args ? Je suppose que nous aurions besoin de signaler spécialement les fonctions car il n'y a rien de spécial dans le registre des fonctions (à moins que nous fassions quelque chose de fou comme toString() la fonction et que nous comptions littéralement les arguments avec regex -- AFAIK c'est le seul type de réflexion dans JS ; vous peut être capable de le faire avec TypeScript mais cela ne nous aide pas)
2. Lancer une erreur si une fonction non correspondante est utilisée dans une autre évaluation de la fonction Less.

C'est un problème intéressant car l'introduction de propriétés personnalisées a rendu les fonctions CSS insolubles au moment de la compilation. Dans une certaine mesure, nous sommes peut-être à la fin d'une ère de pré-traitement statique. Mais c'est une toute autre discussion.

C'est un problème intéressant car l'introduction de propriétés personnalisées a rendu les fonctions CSS insolubles au moment de la compilation.

Rien de nouveau vraiment. Toutes les facilités nécessaires pour gérer cela avec Less sont là depuis sa v1.x - voir ci-dessous. Le seul défi est de le coder de manière non gonflée.

Je suppose que nous aurions besoin de signaler spécialement les fonctions car il n'y a rien de spécial à propos du registre des fonctions

Non, les fonctions devraient simplement renvoyer undefined (ou null ) si elles constatent qu'elles ne peuvent pas évaluer leurs arguments : comme ceci (à moins qu'elles ne détectent également que les arguments sont 100 % erratiques et qu'il vaut mieux déclencher une erreur). .
Et la valeur de retour non définie oblige l'évaluateur de fonction à revenir à la représentation de chaîne initiale : Demo .

Et un chèque similaire de var()

De plus, non, il n'est pas nécessaire de vérifier var ou quoi que ce soit de spécifique (essentiellement des choses inconnues d'un futur CSS). C'est le but. Le code doit vérifier ce qui est possible d'évaluer (les choses connues) au lieu de ce qui n'est pas possible d'évaluer (les inconnues).
(bien que les détails puissent dépendre de la fonction spécifique - ce n'est pas si important).

Btw., notez que --var est également une fonction Less intégrée (ainsi que toute chose ident(...) ) qui n'est tout simplement pas implémentée explicitement (par conséquent, elle revient simplement à la représentation par chaîne de caractères ) parce que ce n'est pas nécessaire. Mais un plugin (par exemple) peut le remplacer par sa propre implémentation qui peut renvoyer une valeur potentiellement évaluable.

@seven-phases-max Oh d'accord, alors vous pensez que la solution simple consiste à ce que ces fonctions CSS/Less renvoient undefined plutôt que de générer une erreur (à rendre telles quelles) ? Cela semble raisonnable, alors si la fonction no. 2 (comme darken() ) ne peut pas interpréter un argument (qui à ce stade serait évalué à une valeur anonyme rgba() ?), il devrait quand même lancer ?

Me disputer avec moi-même :

De plus, non, il n'est pas nécessaire de vérifier var() ou quoi que ce soit de spécifique (essentiellement des choses inconnues d'un futur CSS).

En revanche, il ne serait pas gênant (et même tentant) de détecter spécifiquement var pour que la fonction puisse faire la distinction entre rgba(var(...), ...) et rgba(foo, ...) et toujours déclencher une erreur pour ce dernier, mais cela signifierait un problème similaire à soulever chaque fois qu'ils ajoutent quelque chose de nouveau à CSS.
(Les deux variantes sont bien je suppose, et il s'agit plus de trouver l'équilibre et/ou de prédire le moins de charge pour les mainteneurs...).

@matthew-dean

Cela semble raisonnable, alors si la fonction no. 2 (comme darken ()) ne peut pas interpréter un argument (qui à ce stade serait évalué en une valeur anonyme rgba () ?), il devrait quand même lancer ?

Oui, exactement - nous n'avons même pas besoin de nouveau code pour cela (bien qu'idéalement, ils (des fonctions comme darken ) devraient avoir des messages d'erreur plus conviviaux dans ce cas car les messages actuels de type "a.toHSL is not a function" sont assez déroutant).

Eh bien, l'autre chose qui n'est pas mentionnée est que quelque chose comme rgba(calc(1),1,1) est traité par les navigateurs comme valide (notez à la fois les arguments calc et 3 vs. 4), nous ne devrions donc probablement pas être trop intelligents à ce sujet. J'aime l'idée de simplement sortir tel quel en règle générale, si possible.

Oui, c'est ce que je veux dire avec

Le code doit vérifier ce qui est possible d'évaluer (les choses connues) au lieu de ce qui n'est pas possible d'évaluer (les inconnues).

Les seuls arguments valides pour Less rgba sont soit un nombre, soit un objet de couleur (si nous considérons également les formes de type "néo"-"CSS4" comme rgba(#123, .42) ).
Tout le reste est soit une erreur, soit une valeur CSS (inconnue mais potentiellement valide).

La syntaxe du contenu des propriétés personnalisées CSS est très permissive, mais cela pose des problèmes lors de l'utilisation de telles propriétés dans des fonctions intégrées telles que rgba()

Exemple:
Mon projet permet à l'utilisateur de définir la couleur d'accent sur laquelle repose l'ensemble de l'interface utilisateur de l'application et divers composants personnalisés. Et j'utilise le format RVB en raison de la nécessité de s'estomper à certains endroits et CSS ne fournit rien de tel que fade(<strong i="9">@color</strong>, 50%) en moins. De cette façon, je peux faire rgba( var(--color), 0.5 ) . Cela fonctionne dans Chrome et est pris en charge par le standard. Cependant, moins renvoie l'erreur suivante error evaluation function 'rgba': color functions take numbers as parameters .

Exemple de code :

:root {
  --color-accent: 169,57,255;
}
button:hover {
  background-color: rgba(var(--color-accent), 0.2);
  color: rgb(var(--color-accent));
}

Remarque : il s'agit d'une bibliothèque intégrée et je ne veux pas forcer les utilisateurs à ajouter une autre étape de génération dans leur flux de travail uniquement pour créer ma bibliothèque inférieure avec leurs couleurs. C'est pourquoi j'utilise les nouvelles propriétés personnalisées brillantes (et aussi en raison de sa capacité de portée).

BTW : Existe-t-il une solution de contournement temporaire qui éviterait une gestion aussi stricte et la créerait quand même ? Ce n'est pas comme s'il me manquait un crochet dans une règle imbriquée.

écris comme ça~

:root {
    --color-accent: 169,57,255;
}
button:hover {
    background-color: ~"rgba(var(--color-accent), 0.2)";
    color: ~"rgb(var(--color-accent))";
}

@weivea Sur la dernière version de Less 3.x, ce n'est pas nécessaire, il suffit d'écrire rgba(var(--color-accent))