Bonjour.

Je pose ma question ici, ne sachant pas où la mettre…

J’utilise la fonction invert() de SASS pour passer mes variables de couleur en négatif :

$invertColor: true;
…
$colorThemeA02: if($invertColor, invert($colorThemeA02), $colorThemeA02);
…


Le problème est que mes variables de couleurs $colorThemeA0n ne sont pas toujours des couleurs définies, parfois elle doivent rester non renseignées. Dans ce cas je mets "null" à la place d’une valeur de couleur, mais invert(null) ne passe pas. Il y-a-til une solution pour contourner mon problème ? En précisant dans le code de passer outre les échecs ?
Non. Cela ne change rien. invert() n’accepte qu’une couleur (en hexa, rgb, rgba…). Le truc serait d’avoir une syntaxe qui soit inhibe le test de format ponctuellement, soit permette de faire quelque chose en cas d’échec sur le test de format.
Dans Sass, tu peux tester assez facilement le type de données (voir la doc)

Tu peux tenter quelque chose comme ça :
@if type-of( $macouleur ) = "color" {
    $macouleurinversee: invert( $macouleur );
  }


par exemple.

L'idée vient de la gestion des erreurs proposée par Hugo Giraudel.

Tu peux la mettre à ta sauce mais du coup, si ta variable n'est pas une couleur valide, rien ne se passera.
gc-nomade a écrit :
La piste d'un rgba() ou hsla() en base avec une opacité à 0 au lieu d'un null conviendrait-elle aussi ?

Vu quelques infos ici : http://robots.thoughtbot.com/controlling-color-with-sass-color-functions


En fait non. J’ai besoin que les variables soit valides ou null.

Le but est de faire un template générique en SASS exploitable par des personnes qui ne maîtriseront pas forcément le projet. Je ne vais pas rentrer dans le détail assez complexe de la mécanique, mais il faut que la personne qui voudra créer un nouveau template à partir du premier voit du premier coup d’œil les variables de couleurs utilisées et celle qui sont vide. Si je mets une couleur en opacité 0 pour une variable inutilisée, elle sera beaucoup moins repérable dans le code…

Merci quand même.
Modifié par Derwoed (02 Dec 2014 - 15:30)
Derwoed a écrit :
Merci !

A priori, c’est pil-poil ce qu’il me fallait !
Je vais tester ça…


Ba en fait, ce n’est pas si simple. Je n’ai pas pour l’instant les connaissances nécessaires en SASS pour implémenter ça et je n’ai pas non plus le temps de les acquérir… Smiley ohwell

Comme la fonctionnalité derrière n’est pas indispensable pour l’instant, je vais mettre ça sous le coude…
Si, justement. C'est si simple. Smiley smile

// Booléen forçant l'inversion des couleurs
$invertColor: true;

// Définition de toutes les variables
// soit selon des couleurs valides
// soit à `null`. 
$colorThemeA01: null !default;
$colorThemeA02: null !default;
// ...

// Plus loin, lors du besoin d'inversion des couleurs
// Test si effectivement `$invertColor` est à `true`,
// et si la couleur en question est éligible pour la manipulation. 
@if $invertColor and type-of($colorThemeA02) == "color" {
  $colorThemeA02: invert($colorThemeA02);
}


À ce niveau là, soit la variable vaut "null", soit elle vaut la sortie de fonction "invert".

Ceci étant dit — et je dis ça d'un avis tout à fait extérieur qui manque probablement de contexte sur le projet — l'idée générale me semble relativement bancale.

Si tu déclares initialement une palette de couleurs qui n'en sont pas vraiment, et que tu essayes par la suite de les utiliser, tu vas au devant de soucis pénibles.

À ce niveau là, ce qu'il faudrait envisager c'est forcer la création d'une palette de couleurs, avec gestion des erreurs par là suite si ce n'est pas fait. Ca permettrait de s'assurer d'avoir des couleurs en tout temps, qui sont nécessairement éligibles pour des fonctions de manipulation colorimetrique. De manière générale, ce n'est pas une bonne idée d'avoir une variable dont on ne connait pas le type, surtout dans un langage si simple que Sass.

Note : on utilise l'hyphenation plutôt que le camelCase en CSS.
Modifié par HugoGiraudel (22 Sep 2014 - 23:51)
Merci, cela fonctionne impec ! Et surtout, cela m’a permis d’en découvrir un peu plus sur le SCSS.

PS : pour ce qui est des conventions de nommage, j’ai la mienne, que j’ai mûrement réfléchi et qui me convient bien : un mélange d’hyphenation et de camelCase…