TL;DR : Une fois que vous avez essayé 1 ou 2 mots sur Sutom, allez sur cet outil, puis mettez le format du mot et renseignez les lettres à inclure ou à exclure.

Le format du mot à mettre est de la forme « A . . . ER. $ » où A est la première lettre, E une lettre bien placée, $ indique la fin du mot et les points sont des lettres à trouver.

Attention, les téléphones ont tendance à remplacer trois points par le caractère unique des points de suspension.

---

S’il y a bien un truc puissant en programmation, ce sont les expressions régulières, ou « regular expressions », Regex pour les intimes.

J’en avais déjà fait une petite introduction que je vous conseille de lire.

Aujourd’hui, voyons un usage à ces choses-là.
Depuis le début de l’année, le jeu Wordle (en anglais) et Sutom (en français) sont devenus viraux. Leur principe est celui du jeu télévisé « Motus ».

Sutom ?

Le principe du jeu est le suivant.

Le but est de deviner un mot.
La première lettre nous est toujours fournie. On connaît également la longueur du mot.
On a droit à 6 essais pour deviner le mot :

À chaque fois qu’on essaye un mot, on a des indices :

• les lettres bien placées sont en rouge
• les lettres présentes mais à leur mauvaise place sont en jaune
• les autres lettres ne figurent pas dans le mot

Dans cet exemple, celui du 21 janvier 2022, si j’essaye le mot « Diamètre », j’obtiens :

Je sais désormais que :
– Le mot fait 8 lettres (incluant le D au début)
– D et I sont bien placés
– E et R sont mal placés (mais présents).
– A, T et M sont exclus (grisés sur le clavier)

D’essai en essai, on accumule les indices et la solution nous apparaît plus ou moins facilement.
Motus était un jeu télévisé, mais sur ces petits jeux en ligne, il n’y a rien à gagner. Il y a un seul mot par jour.

Si vous trouvez, vous recevez un code rigolo à partager sur les réseaux sociaux qui représentent les couleurs des cases du tableau. Comme personne n’essaie les mêmes mots, il est généralement unique à vous pour ce jour-là. C’est amusant :).

Utiliser les Regex pour jouer à Sutom

Sutom demande deux choses qu’un ordinateur a :

• de la mémoire (du vocabulaire)
• de la logique

Il suffit d’une liste de mots connus suffisamment complète ainsi que quelques règles de base pour permettre à un ordinateur de jouer à Sutom.

On pourrait créer un solveur où l’on prend la grille en photo et il nous donne la réponse. Ce serait un exercice intéressant à plusieurs niveaux, mais ce n’est pas ce que je vais faire ici.

Je me contenterai ici d’utiliser une liste de mots et les Regex mentionnées plus haut pour trouver la solution grâce aux indices du jeu.

J’ai fait cette page : Rechercher un mot. Elle contient 340 000 mots et un champ de recherche.
L’intérêt est que la recherche fonctionne par Regex !

Le but de cet article est de créer une Regex puissante qui va très vite filtrer les mots et nous sortir le bon, généralement après 1 ou 2 essais seulement.

Pour l’exemple du 21 janvier 2022, le mot commence par D et fait 8 lettres.

On a donc cette Regex :

D.{7}$

Vous pouvez copier ça dans le champ de recherche de la page de recherche de mots.

La Regex signifie « un “D”, suivi de 7 lettres » (donc bien 8 au total). Le « $ » à la fin signifie que c’est la fin du mot après ça. Si on ne le met pas, il va nous sortir les mots de 8 lettres ou plus. Or nous ne voulons que les mots de 8 lettres.

À ce stade, ma page me sort 37 042 mots. On peut en utiliser un de la liste ou en poser un qu’on connaitrait déjà.

Dans mon cas, j’essaye « DIAMETRE ». J’obtiens les informations suivantes :
– D et I sont bien placés
– E et R sont mal placés (mais présents).
– A, T et M sont exclus (grisés sur le clavier)

Il faut donc un mot qui débute par DI, qui ne contienne pas A, T, M, mais qui contienne E, R. et dont la longueur totale fasse toujours 7 lettres.

Le début de la Regex est simple : le mot commence par DI.

La Regex débute donc tout naturellement par :

di

Ensuite, il faut dire que parmi tous les mots commençant par « DI », on veut ceux comportant E et R.

Il s’agit d’utiliser une assertion positive avant (positive lookahead), pour dire « je veux un E et un R après le DI ». Il existe aussi des assertions arrière, pour vérifier ce qui se trouve avant, mais ça ne nous intéresse pas ici.
L’assertion positive est inclue dans notre Regex sous la forme (?=REGEX). Elle contient elle-même une sous-Regex.

Notre sous-Regex est la forme « une lettre suivie de E ou de R ». La regex est triviale, mais comme on veut un E et un R, qu’importe l’ordre mais il nous faut les deux, il nous faut deux assertions :

(?=.*e)(?=.*r)

Maintenant un peu de technique interne aux Regex.

Normalement quand on cherche « ABC », il cherche un « A » suivi d’un « B » suivi d’un « C ». La chaîne « A1B1C1 » ne marche pas, car les trois lettres ne se suivent pas.

Effectivement, après avoir matché le « A », le parseur se positionne après le A. Il regarde donc s’il y a un « B » juste après, et ainsi de suite, à chaque fois en venant avancer dans la chaîne. Ainsi, quand on matche notre « AB », on avance de deux lettres dans le mot.

Les assertions servent à matcher des trucs, mais ne font pas avancer dans notre Regex globale. Quand on utilise l’assertion, on va parcourir le reste du mot et renvoyer un TRUE si un E et un R sont trouvés, mais on vient se remettre juste après le DI.

À ce stade, la Regex entière a filtrée les mots débutant par DI et contenant un E et un R.

Il reste à filtrer les mots pour éliminer ceux avec A, T, M.

Pour ça, on veut exclure des lettres. On va utiliser une assertion négative avant (negative lookahead) pour dire « je ne veux pas de A, T, M après le “DI” ».

L’assertion négative se construit avec (?!REGEX). Elle est négative, car on retourne FALSE si la REGEX à l’intérieur de l’assertion retourne TRUE.

Dans notre cas, on veut refuser A, T et M. Une seule assertion suffit car on veut éliminer les mots contenant une ou plusieurs des lettres parmi A, T, M :
Ce qui donne :

(?!.*[atm])

Maintenant, il nous reste à dire qu’il nous faut 6 lettres.
Inutile de lister les lettres : on peut utiliser le simple « . ». Les assertions ont déjà filtré les lettres qui nous intéressent ou non. On a donc :

.{6}

Mis bout à bout, on a :

di(?=.*e)(?=.*r)(?!.*[atm]).{6}$

Le filtre me trouve 34 mots (sur 340 000). Pas mal, mais pas suffisant pour gagner au jeu. Il faut en essayer un au hasard. J’essaye donc le mot « DISPOSER ».

Qui donne :

J’apprends donc que le mot est de forme « DI...SER ». J’apprends également qu’on peut éliminer les lettres O et P, en plus de A, T, M.

On peut donc modifier notre assertion négative avant pour filtrer ces deux lettres supplémentaires. De plus, le E et le R sont bien placés : on sait où ils sont. Notre assertion positive avant devient inutile.

La Regex globale devient :

di(?!.*[atopm]).{3}ser$

Qui signifie :

• « di »
• puis « on ne veut pas de A, T, O, P, M »
• puis on revient après le « di », on met trois lettres n’importe lesquelles
• puis on met « ser »
• et c’est la fin du mot.

Et là, bim, mon outil de recherche ne me sort plus qu’un seul mot.

Il se trouve que c’est le bon :

SUTOM #14 3/6

🟥🟥🟦🟦🟡🟦🟡🟦
🟥🟥🟦🟦🟦🟥🟥🟥
🟥🟥🟥🟥🟥🟥🟥🟥

Bingo !
Ou plutôt « Motus » !
(ou Sutom)

Bien-sûr cela fonctionne, car tous les mots dans le dictionnaire utilisé par le jeu sont contenus dans le dictionnaire de ma page.

Ma page n’utilise pas le même dictionnaire. C’est volontaire, car je veux un dictionnaire plus large. Mais il arrive bien à filtrer des choses.

Notez que ma page permet de filtrer les accents et les tirets aussi. Sutom ne les affiche pas (ou plutôt il compte le É ou le È comme un E).

---

Enfin, j’ai aussi un outil de visualisation de Regex. Il est repris d’un code déjà existant (pas de moi) mais ça permet de visualiser ce que signifient les expressions assez compliquées de Regex.

Petite digression sur cet article :

• I won't let you pay me for my open source

Je commente juste ce passage, lié à la licence MIT car je suis totalement d’accord avec :

The MIT license to a large extent is the anti-license. The utopia of socialized programs, one that embraces the lack of marginal cost for software goods.

It’s an explicit rejection of the strong-property rights approach taken by both Gates and Stallman at their respective ends of the libertarian spectrum.

It’s the language of giving without expecting anything in return. It’s the language of sincere charity. A charity without strings attached, neither commercial nor reciprocal. With the risk of sounding sanctimonious, I read it as a pure projection of altruism.

[…]
That to me is freedom.

Car non, même si je considère que GPL et consorts sont nécessaires, ce n’est pas pour moi une licence libre.

La liberté, c’est quand je fais ce que j’ai envie de faire, et comment j’ai envie de le faire (je caricature évidemment).

Est-ce que la licence GNU me permet de faire ce que je veux ? Non. Je ne peux pas, par exemple, faire un logiciel propriétaire avec un code d’origine libre (pour ça, il y a d’autres licences qui sont apparues).

La liberté va de paire avec des devoirs, je suis absolument d’accord avec ça. Mais précisément : il faut bien distinguer les deux.

Ainsi, je vois les licences comme suit :

• MIT est la liberté : je fais ce que je veux.
• Une licence propriétaire, n’a que des devoirs (ou des interdits, qui ne sont que des devoirs négatifs ; en tout cas le contraire d’une liberté). Je ne fais rien comme je veux.
• GNU/GPL essaye de concilier les deux : en donnant une liberté associée à des devoirs. Je fais ce que je veux, mais sous certaines conditions.

Parfois, souvent même, c’est utile et nécessaire de poser quelques limites. Mais dans autant de cas, une permissivité totale est également nécessaire.

Prenons l’exemple de la loi, car c’est ça qui détermine nos vies en société.

La loi, la constitution, posent des libertés et des devoirs pour chaque personne. Ainsi, par exemple, pour utiliser l’espace public, on ne doit pas être ivre. Il en va de la tranquillité de la société, sachant que l’alcool est une drogue, qu’elle rend violent et incapacitant : une personne ivre est un danger pour elle-même et les autres et il est mieux d’éviter ça.

Pourtant, il est tout à fait autorisé d’être ivre.
Il est tout à fait autorisé de boire quand on est mineur.
Et il est aussi tout à fait autorisé d’être ivre quand on est mineur.

Juste, chez soi.

Chez soi y a pas de problème.
Chez soi, la permissivité est très très large.

Encore heureux.

Stallman avec GPL, n’a pas fait une permissivité totale pour chez soi. Ce qu’il a fait, c’est un espace public : à la fois ouverte sur des libertés et délimité par des devoirs. La licence MIT, elle, c’est chez soi. Une licence propriétaire, en revanche, c’est chez les autres : on fait ce qu’on nous autorise de faire, car on n’est pas chez soi.

Quand je suis chez moi, je n’ai pas envie qu’on vienne me dire ce que j’ai le droit de faire ou non. Ni Bill Gates, qui vient me harceler parce que j’ai modifié Windows ; ni Richard Stallman qui exige le code source d’une modif que j’aurais commise (dans le cas de la AGPL, cette exigence est imposée même sans que le code ne soit redistribué).

Gates et Stallman ont beau être chacun à l’opposé d’une échelle assimilable à la droite et à la gauche en politique, cette échelle binaire, je la vois plutôt comme un polygone à trois sommets : Gates (tout interdit) à un bout, Stallman (des libertés ET des devoirs) à un autre, et les licences totalement libres telles que MIT, Apache, WTFPL au troisième (que des libertés).

Ces trois « pôles » défendent donc des intérêts différents à chaque fois : celui de l’utilisateur, du créateur, ou de la société (et on peut très bien en imaginer d’autres).

En fait, en rédigeant ce post, je viens de me mettre une image mentale sur pourquoi je n’ai jamais considéré les licences GPL comme libre, tout en étant fondamentalement convaincu de leur utilité. L’un n’empêche pas l’autre en fait.

Et le seul problème, c’est qu’on assimile GPL ou GNU à la liberté, alors qu’en réalité on devrait l’associer à une chose publique. (je n’emploie volontaire pas l’expression « domaine public », car ce vocabulaire signifie déjà quelque chose, même si le terme approprié serait bien « domaine public »). La GPL s’appelle d’ailleurs « General Public Licence », pas « General Free Licence ». C’est peut-être pas sans raison.

Car ce qui est public est accessible à tous sans appartenir à qui que ce soit.
Le bus est un transport public : pourtant je ne peux pas virer le conducteur et voler le bus pour rentrer directement jusque chez moi. Ni sortir dans un parc et couper les fleurs. Ni ramasser un banc pour mettre dans mon jardin.

Alors que ce qui est libre, je peux le prendre et en faire ce que je veux. Si y a un panier de pommes dehors où c’est écrit « Gratuit, servez-vous », je peux prendre une pomme et elle devient la mienne. Je peux la manger, la rapporter à la maison, en faire de la compote ou la jeter aux poules : j’ai le droit. C’est libre.

Quand j’ai commencé à utiliser un ordinateur, j’adorais bidouiller. J’étais encore petit, mais je m’amusais à modifier tous les paramètres possibles et voir ce qui se passait. C’était sous un système Windows. J’essayais aussi de supprimer ou déplacer des fichiers, toujours pour voir. Là, forcément ça plantait et il fallait réparer.

Avec le temps et au fil des bidouilles, on comprend quel programme fait quoi et ce qu’il ne faut pas faire ou alors seulement en connaissances de cause.

C’est un bon moyen d’apprendre.

Au fil du temps, je me suis lassé et j’ai voulu découvrir d’autres trucs. J’ai essayé GNU/Linux (Ubuntu). J’ai pu découvrir un autre système, d’autres manières de fonctionner, d’autres paramètres à bidouiller, à casser et à réparer, d’autres fichiers dans lesquels gratter, etc.
J’utilise toujours du Linux aujourd’hui, sur mon système personnel de façon courante.

Mais j’ai l’impression que tout ça c’était avant. Aujourd’hui je ne bidouille plus comme ça.

Aujourd’hui, si je bidouille mon système, c’est pour qu’après ça marche. J’édite d’obscurs fichiers de config, j’installe des outils étranges et je fais des scripts bizarres, mais tout ça est devenu purement fonctionnel.

J’ai plus le temps ni l’envie de bidouiller pour m’amuser : la fin n’est plus l’excitation de découvrir, casser puis réparer un ordinateur. Pas que je ne suis plus curieux, mais parce qu’une fois qu’on a découvert, on ne peut plus redécouvrir. Mon intérêt s’est porté sur autre chose.

La fin est devenue d’avoir un ordinateur qui fonctionne comme je le veux. Et c’est bien ce que j’ai : j’ai passé plusieurs années étudier le fonctionnement, afin de voir ce qu’on pouvait modifier et comment, pour pouvoir avoir enfin un système qui fonctionne comme je veux.

Ça ne me dérange pas de lancer des lignes de commandes trouvées sur la dernière page de l’internet, mais ça doit avoir un but et ça doit fonctionner. C’est d’ailleurs la raison de mes checklists Linux/Windows : avoir mes commandes à porté de main et pouvoir les appliquer rapidement en cas d’installation d’un nouveau système (mise à niveau complet, changement de PC…).

Pourquoi avoir un PC qui marche ?

Avant je bidouillais pour bidouiller. Maintenant je bidouille pour que ça marche. Car si ça marche, je peux produire et créer : faire des choses constructives.

L’informatique a pris une grande place dans mon quotidien et j’aime avoir les outils pour l’exploiter correctement. Et si un outil n’existe pas (ou n’est pas à mon goût), je sais le créer.

Tout le temps passer à regarder le fonctionnement d’un ordinateur m’a permis de découvrir l’univers des possibles en informatique (car oui, un ordinateur peut faire autre chose que ses courses en ligne ou regarder Netflix).

Du coup, maintenant, je crée des outils qui me servent au quotidien dans ce que je fais. Ma page des outils en ligne est dans cette veine-là.

Je pense que c’est un peu comme quand on évolue de lecteur à écrivain : on regarde, on apprend, puis on construit des choses différentes de ce qu’on a vu grâce à ce qu’on a appris.

Peu de monde va aussi loin dans cette démarche. La plupart des gens, face à un ordinateur, n’y voient qu’un écran interactif, bien loin de se douter qu’avec les bons outils et les bonnes connaissances on peut utiliser son PC pour faire à peu près n’importe quoi.

Et aujourd’hui, c’est là que je me dirige, plus que vers le simple bidouillage.

Ça en est à un point où, parfois, les systèmes trop configurables me font chier. KDE, un environnement Linux axé sur la personnalisation, est très joli mais ne m’attire pas. Je préfère Mate (Gnome) qui a autant d’options (juste elles sont cachées) mais qui à l’utilisation n’est pas encombrante.

C’est un peu ce que je reproche à Android de plus en plus. Il y a des tas d’options partout, à tel point que celle que l’on cherche est introuvable 90 % du temps. Sur ce plan, et bien que ça ne soit pas la seule raison, je songe de plus en plus à passer sur iOS/iPhone. Un système qui tourne et qui ne traîne pas dans mes pattes, quitte à avoir moins d’options : c’est ça que je veux.

Voici une magnifique subtilité du CSS, mais parfaitement logique quand-même :

• The surprising behavior of !important in CSS custom property values

Que se passe-t-il si on met !important dans une variable ?

Voyons ça :

div {
  --color: red !important;
  color: var(--color);
  color: yellow;
}

À votre avis ça donne quoi ça en CSS ? Le point litigieux, c’est bien-sûr la présence du !important
Sauf qu’il est à savoir que le !important n’est pas sur une déclaration de propriété, mais sur une déclaration de variable CSS.

Or, une variable ne peut contenir qu’une valeur. La valeur contenue dans --color est donc red. Il faut savoir que le !important ne fait pas partie de la valeur : il s’agit d’un élément de langage qui permet de jouer sur la spécificité, comme un drapeau (un flag).

Résultat : la couleur finale du texte sera décidée par le vainqueur des deux déclarations de color juste en dessous. Comme celle-ci ont la même spécificité, c’est la dernière qui gagne.

Conclusion : le texte est en jaune.

!important n’est pas sans effet !

Maintenant, utiliser un !important dans les variables CSS n’est pas sans effet pour autant.
Regardons :

div {
  --color: red !important;
  --color: blue;
  color: var(--color);
}

Ici, aucune ambiguïté sur la déclaration de la couleur, puisqu’il n’y en a qu’une seule : color prendra la valeur contenue dans la variable --color. Oui mais laquelle ?

Réponse : celle dont la déclaration a la spécificité la plus grande ! Autrement dit, la première.
Conclusion : ça donnera du rouge.

Il convient donc de distinguer deux cas de figure :

div {
  --color: red !important;
  color: var(--color);
  color: blue;
}

div {
  --color: red;
  color: var(--color) !important;
  color: blue;
}

Dans le premier cas, les deux déclarations de couleur ont la même spécificité. C’est donc la dernière qui gagne : le texte sera bleu.
Dans le second cas, c’est la première déclaration qui a la plus grande spécificité (à cause du !important).

Peu importe qu’elle ait une variable ou non, c’est elle qui gagne : cela donnera du rouge.

Le conflit ? Quel conflit ?

Dans sa conclusion, l’article dit qu’il y a deux niveaux de « scope » (traduction ?) sur lesquelles sont appliqués le !important. Une sur les variables, et une sur les propriétés. Je ne suis pas d’accord avec ça : pour moi il n’y a en a qu’une seule. En revanche, il a deux déclarations différentes à considérer : une sur une variable, et une sur une propriété.
Maintenant, dans les deux cas, on peut ajouter un !important si l’on veut. Et comme ce sont deux choses différentes, elles n’entreront pas en conflit.

Appliquer deux !important à deux propriétés différentes n’est pas un problème :

div {
  font-weight: bold !important;
  color: red !important;
}

Ces deux choses n’entrent pas en conflit.
Par conséquent, les deux choses suivantes non plus :

div {
  --color: bleu !important;
  color: red !important;
}

Notez que ci-dessus, la variable --color est déclarée, mais jamais utilisée, donc aucun conflit à l’horizon.

Dans ce qui suit, toujours aucun conflit :

div {
  --color: bleu !important;
  color: var(--color) !important;
}

Tout est clair : la variable reçoit du bleu. La couleur reçoit la variable. Donc la couleur finale est bleue.

Et même s’il y avait plusieurs déclarations de la variable, celle qui gagne est celle de la plus grande spécificité. Ensuite, c’est la déclaration de la couleur avec la plus grande spécificité qui gagne. Ainsi l’exemple suivant donnera du rouge :

div {
  --color: red !important;
  --color: blue;
  color: var(--color) !important;
  color: green;
}

Parmi les variables, c’est le rouge qui gagne sur le bleu.
Parmi les propriétés, c’est celui avec le var() qui gagne sur celui avec le vert. Or la variable contient du rouge. Donc le texte sera rouge.

Applications à un contexte plus large

Tout ceci est évidemment à mettre dans un contexte plus global avec des déclarations sur des sélecteurs de spécificité différente.

div {
  --color: blue !important;
  color: var(--color);
}

div#foo {
  --color: orange;
  color: var(--color);
}

Ici ça sera… Bleu !

Regardons la couleur pour commencer. La couleur reçoit ce que contient la variable. Aucune ambiguïté. Et la règle qui s’applique est celle dans le second bloc. Pourquoi ? Parce que le sélecteur y est plus spécifique.

Maintenant que contient cette variable ? Cette variable est celle qui est la plus spécifique. Donc celle avec le !important. Donc le bleu.

En effet, même s’il y a un #id sur le sélecteur du second bloc, la variable --color ne contient pas de l’orange, mais du rouge : le !important sur une propriété est plus spécifique que la même propriété placée sur un ID (Spécificité de 1-0-0-0-1 au lieu de 0-1-0-0-1).

Par contre, il en est différent si le !important sous le deuxième bloc avait été sur la variable au lieu de la propriété :

div {
  --color: blue;
  color: var(--color)!important;
}

div#foo {
  --color: orange;
  color: var(--color);
}

Dans ce cas, la variable qui s’applique est l’orange dans le second bloc (car cette variable est plus spécifique à cause de l’ID dans le sélecteur). Le texte est donc orange.

Notons de façon anecdotique que la propriété qui s’applique est bien celle du premier bloc (car cette propriété a un !important).

Le vocabulaire est important : la propriété et la variable sont deux déclarations différentes. Elles ont chacune leur spécificité (au sens de « priorité CSS »).

Si je ne conserve que les éléments qui s’appliquent réellement, ça donne ceci :

div {

  color: var(--color) !important;
}

div#foo {
  --color: orange !important;

}

La couleur reçoit une variable, comme indiqué dans le premier bloc. Mais cette variable a une valeur assignée dans le second bloc seulement.

Ça vous semble casse gueule ? Attendez la suite.

Cas des sélecteurs enfants

Jusqu’à maintenant, même si on utilise deux sélecteurs différents, ils ciblent le même élément HTML.
Poursuivons les complications par quelques exemples pour montrer ce qui se passe avec avec des sélecteurs enfants.

Voyons :

div {
  --color: red !important;
  color: var(--color) !important;
}

div a {
  --color: orange;
  color: black;
}

La question : quelle est la couleur du lien ?
Réponse : noire.

Noire ? Oui, noire. La déclaration tout à la fin.

En effet, le premier bloc a beau avoir des !important sur toutes les propriétés, ils s’appliquent au div, tout comme leur spécificité.
Or, la spécificité n’est héritée que si la valeur sur laquelle elle s’applique est également héritée. En réalité, seule la propriété la plus spécifique est alors héritée (et la spécificité devient inutile).

Ainsi, pour savoir ce qui s’applique à notre a, on regarde le code destiné au a. C’est alors lui qui s’appliquera, s’il y en a. Et le a possède une déclaration de couleur : color: black;.
L’hérédité ne s’applique donc plus : on applique le color: black;, point barre.

L’hérédité ne s’applique qu’en l’absence de déclaration.

Ainsi, si on avait mis :

div {
  --color: red !important;
  color: var(--color) !important;
}
div a {
  --color: orange;
}

Alors, le texte serait rouge. La couleur du a serait héritée du div, et contiendra var(--color), qui, dans le contexte du div (le contexte hérité, donc), est rouge.

Pas orange ?

Non : l’orange est du contexte de a. Or la propriété de couleur est héritée du contexte de div, et là, dans son contexte, c’est bien du rouge que contient la variable. Ce qui est héritée, c’est la propriété et sa valeur.

On aurait même pu mettre un !important dans le second bloc, cela ne changera rien :

div {
  --color: red !important;
  color: var(--color) !important;
}
div a {
  --color: orange!important;
}

Cela rester rouge, pour la même raison : la couleur est héritée, même si elle provient d’une variable.

Si l’on voulait du orange, on doit ajouter un color: var(--color) dans le second bloc. Comme ça, la couleur du a est déclarée et non-héritée. Mais il faut bien conserver la déclaration de la variable dans le a, sinon la variable n’est plus déclarée et elle hérite.

Il faut retenir que la variable s’applique sur les propriétés du même contexte. Le parent transmet une propriété ? D’accord, mais sa valeur est également transmise, même si c’est une variable.

Par contre, dans le code suivant, la variable est bien héritée :

div {
  --color: red !important;
}
div a {
  color: var(--color);
}

Le a sera rouge. Ici, l’on ne déclare pas la variable --color dans le a. Elle est donc héritée. Or son parent lui dit que la variable contient du rouge. Donc le texte est en rouge.

Et avec des variables partagées sur plusieurs propriétés ?

La blague n’est pas terminée !
On arrive ici à quelque chose de très drôle : quid des variables appliquées à plusieurs propriétés, l’une déclarée et l’autre héritée ?

div {
  --color: white;
  color: var(--color);
}
div a {
  --color: black;
  background-color: var(--color);
}

Ça va donner quoi ?
Ici le texte dans le a sera bien en blanc sur fond noir !

Décomposons :

• La couleur du texte : la couleur n’est pas déclarée sur le a. Elle est donc héritée. Et l’héritage contient du blanc : c’est donc du blanc.
• Le couleur du fond : le fond est déclaré sur le a. Le fond contient var(--color). Et --color, dans ce contexte, contient du noir. Le fond est donc noir.

Si l’on n’avait pas déclaré le --color: black;, alors la variable aurait été héritée, et on aurait eu du blanc sur fond blanc. Mais comme on l’a redéfini dans le contexte du a, elle prend une nouvelle valeur… dans son contexte seulement.

Notez que dans ce dernier exemple on n’a mis aucun !important : normal, car la spécificité n’est pas héritée si la propriété sur laquelle elle est appliquée n’est pas elle-même héritée.

On aurait pu en mettre partout dans le premier bloc, on aurait tout de même eu du blanc sur du noir.

Conclusion

Pour moi tout est logique, même si c’est parfois compliqué.
Il faut retenir :

• !important s’applique à la déclaration de la variable. Mais elle n’est pas dans la valeur assignée à la variable.
• une variable CSS peut être déclarée plusieurs fois. Tout comme on peut déclarer plusieurs fois une couleur. Dans ces conditions, c’est la déclaration la plus spécifique qui est retenue. Si toutes ont la même spécificité, la dernière est retenue. C’est du CSS de base.
• concernant l’hérédité, rien n’est nouveau là non plus : les valeurs, même avec un !important ne sont transmis aux éléments enfants que si ces derniers ne les redéclarent pas. Ça vaut pour les variables comme pour les propriétés CSS.

Bref, c’est compliqué, un peu curieux, parfois casse-gueule, mais rien de nouveau.

Et rien de différent d’autre langages de prog non plus : les variables ont leur contexte et peuvent être redéfinies dans des boucles imbriquées d’où elles ne sortent pas (pensez au let en JS par exemple : deux variables redéclarées avec le même nom auront leur propre contexte :

let a = "bar";

function newScope() {
    let a = "foo";
    console.log(a); // "foo"
}

console.log(a); // "bar"

Ah et : ici on ne parle que de la propriété color. Je vous laisse imaginer ce que ça donne si l’on utilise des variables dans display, flex ou position, le tout assaisonnée de sélecteurs comme a ~ a et de pseudo-classes :not() ou :placeholder-shown. Ça promet, non ?

Log4Shell est une nouvelle de ces failles informatique qui touchent des milliards d’appareils, et qui permettent potentiellement à n’importe qui d’en prendre le contrôle. Elle est décrite comme « la plus grosse et la plus critique des failles unique de la décennie » (« the single biggest, most critical vulnerability of the last decade »). La CISA et la BSI (respectivement les ANSSI américaines et allemandes) l’ont qualifié de « extrêmement critique ». Le gouvernement Canadien a lui décidé de fermer tous ses sites du service publics en attendant que ça soit corrigé.

Cette faille peut affecter non seulement un ordinateur ou un SI d’entreprise, mais aussi votre téléphone, imprimante connectée, ou de plus en plus votre frigo, télé, voiture, porte de garage ou four à micro-ondes connecté.

Pour comprendre la faille, je vous renvoie à ce thread sur Twitter.

Si je devais résumer : cela concerne un module utilisé par les outils de gestion des journaux système d’une installation informatique (les « logs »).
Beaucoup de programmes utilisent les logs (tous en fait, plus ou moins). Certains peuvent alors y mettre des variables, comme ${date}, qui seront alors remplacés par l’outil qui gère le journal (en l’occurrence, ${date} sera remplacé par la date courante au moment de l’accès au journal).

Or il se trouve que certaines variables sont renvoyées en cascade vers d’autres modules qui peuvent y placer d’autres informations. En particulier, ici un module (JNDI) qui vient remplacer une des variables par des données arbitraires… Par exemple une URL au bout de laquelle n’importe qui peut placer du code malicieux.

Ce problème est signalé depuis 2016.

Le module, utilisé par toutes les big-tech (Microsoft, Apple, Google, Tesla…) est maintenu par… Trois gus qui font ça sur leur temps libre :

Ces trois personnes n’y sont pour rien : les erreurs arrivent et ils vont sûrement corriger ça très vite. Le problème que je vois surtout, c’est que des sociétés dont la valorisation cumulée doit bien dépasser 5 trillions de dollars, n’ont pas gratifié ces dév ne serait-ce que de 1 000 $ durant du tout ce temps.

Ce manque de reconnaissance est à vomir.

D’ailleurs je n’aurais qu’une chose à dire : si votre architecture fonctionne comme ça : soutenez ceux qui vous permettent de bosser ! C’est la moindre des choses.

Il ne fait pas beaucoup de doutes que quelqu’un qu’on paye pour s’occuper de quelque chose à temps plein sera plus efficace pour corriger les bugs que quelqu’un qu’on laisse bosser sur son seul temps libre de temps en temps.

Je vois deux choses à retenir ici :

• en profitant du boulot des autres, on hérite aussi de leurs erreurs. Ce n’est pas grave, mais faut en être conscient : on est dépendant d’eux ;
• en abusant des lib et outils sans prodiguer ne serait-ce qu’un simplement soutien ponctuel, faut pas s’étonner que le module reste du boulot fait irrégulièrement et sur du temps libre.

Qu’on soit clair : le boulot d’un amateur sur son temps libre peut être très bon. Ce que je veux dire en vrai, c’est que si l’on construit son empire sur ce boulot, il faut peut-être s’assurer que ce code « amateur » soit solide. Et en l’occurrence, ça passe par un soutien suffisant à celui qui s’occupe de ce code ou de son audit.

Les dév mangent aussi (je vous jure !), et le temps qu’ils passent à bosser ailleurs pour pouvoir manger, ils ne le passeront pas à corriger l’outil qui maintient votre empire en place. Tout simplement parce que votre empire, il s’en fout autant que vous vous foutez de lui en ne donnant pas ne serait-ce qu’un micro-pourcent de ce que vous distribuez aux actionnaires chaque année. Et c’est bien normal.

Or, n’importe quel appareil numérique aujourd’hui fonctionne grâce à des dizaines, des centaines de ces modules développées par des passionnés et des bénévoles. Ouvrez n’importe programme ou n’importe quelle application et allez dans les « crédits » ou les « à propos ». Vous y verrez le nom des personnes qui vous rendent la vie plus simple, chaque jour, y compris, si c’est fait correctement, les outils qui permettent à ces applications de fonctionner, et leurs auteurs.

Et les exemples où l’industrie se fiche de remercier ces gens et s’en retrouve à genoux également : on se souviendra de Heartbleed, la faille de 2014 qui avait fait un grand bruit parce qu’il touchait tous les sites sécurisés (SSL) et tous les outils, y compris ceux des Gafam, et avait mis en lumière le manque de moyens de la fondation OpenSSL qui s’occupe de ça. Quelques années après, OpenSSL ne tourne toujours qu’avec environ 50 000 $ par an…

ÉDIT : ah oui… Ceci est aussi à mettre en perspective avec cet article de ce journaleux qui demande aux dév d’arrêter de vouloir être payés un salaire à la hauteur de leur compétences.