PROJET AUTOBLOG


le hollandais volant

Site original : le hollandais volant

⇐ retour index

#CSS : variables CSS et !important

samedi 18 décembre 2021 à 13:21

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

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 :

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 :

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 : Soutenez les dév dont vous utilisez le travail !

dimanche 12 décembre 2021 à 15:01

i
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 :

Les dépendances en informatique.
Le XKCD qui va bien (source) : « toute l’infrastructure informatique moderne » soutenue par « le petit projet maintenu gracieusement depuis 2003 par un inconnu au fin fond de nulle part ».

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.

Si votre architecture fonctionne comme ça : soutenez ceux qui vous permettent de bosser ! C’est la moindre des choses, en fait.

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 :

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.

Rien à foutre du baby-foot !

mercredi 24 novembre 2021 à 22:18

(Ça rime :D)

J'avais commencé de répondre jusqu'aux question bullshito-corporate qui ne veulent strictement rien dire, j’ai donc abandonné en cours de route.

Je vais donc mettre ici ce que je considère comme un poste de développeur idéal. C'est ma vision des choses ; si y'en a qui sont pas d'accord c'est leur droit et pas vraiment mon problème.

Je précise quand-même : je code aujourd'hui professionnellement comme personnellement, même si ce n'est pas mon activité principale.

Bref, voici mes critères (en dehors de la paye).

Pour commencer : un bureau FERMÉ.
Coder quoi que ce soit, c'est une activité intellectuelle et j'ai besoin d'être concentré.
Je peux rester assis à réfléchir 12 h de suite, ça me gêne pas. Par contre le moindre bruit, sonnerie de téléphone pour des broutilles, ou tocage à la porte peuvent faire perdre 5 h de réflexion, et à vous 5 h d'avancement sur la deadline. C'est vous qui voyez.

Un bon bureau, chaise, écran.
C'est notre matériel de travail, bon sang ! Pour la même raison qu'un mécano ne travaille pas avec des outils premier-prix de chez Lidl, si vous nous donnez une chaise en bois et une table bancale pour bosser sur un Médion de 2005 et son clavier en Qwertz, ça va pas le faire.
Je veux utiliser mon ordi. Ou en tout cas mon clavier et ma souris. Ainsi que si possible mon environnement de développement.

La plupart des développeurs font du dev également à titre perso et ont appris ça chez eux avec leur logiciels et ont leurs repères (raccourcis claviers, etc.). C'est comme ça qu'on est le plus efficace, et ces demandes ne sont pas pour vous faire chier, bien au contraire.

Des spec précises
Dîtes nous précisément ce que vous voulez qu'on code et pour quand et on le fait et vous aurez ce que vous voulez au moment fallu. Et passez le mot au client aussi.
Si les spec ne sont pas précises, je considère que le choix non précisés sont laissés à notre discrétion. On dit pas à un architecte « je veux une maison », mais « je veux cette maison », accompagnée d'une liste complète de critères à respecter ab-so-lu-ment.

Le dèv c'est pareil.

Trucs non-importants
Perso je me fiche et contre-fiche :

Certains aiment se sentir au jardin d’enfant pour bosser. Tant mieux pour eux, mais moi c'est pas mon cas. Je préfère l’ambiance « bibliothèque » en plein désert (et moins y a de monde, mieux j’y suis).

Et je distingue l’entreprise du reste de ma vie et j'ai envie de garder ça comme ça. Les soirées entreprise, si c’est plus d’une fois dans l’année, ça devient lourd, et si c’est pour en profiter pour parler boulot, sans moi merci. Revenez aux bons horaires.

D'ailleurs parlant de ça : les horaires et les congés flexibles c'est un gros point positif. Leur absence, un gros point négatif, sans être discriminant.

En résumé
Je suis dév : je travail en silence avec ma tête et mon ordi.
Il est donc normal d’être bien mentalement (au calme loin du bruit) et avec un bon ordi / chaise / souris.

Tout le reste, je m’en fiche : babyfoot & co, ce n’est pas un avantage pour moi (sauf s’il est loin loin loin au sous-sol).


PS : non, je ne recherche pas de poste de dév en ce moment.
J’ai juste tiqué sur un article d’un confrère blogueur.

Non mais ça va là, tranquille, les comparateurs en ligne ?

lundi 15 novembre 2021 à 17:27

Homme criant à un téléphone fixe.
Ce week-end j’ai fait une connerie.

J’ai voulu faire une simulation d’un crédit, en ligne.

Mon but n’est pas de faire le crédit, mais de voir si cette méthode de financement peut figurer dans mon éventail d’options pour un éventuel projet.

En gros : je souhaitais juste savoir si les banques accepteraient un dossier comme le mien, sachant que je n’ai jamais contracté de crédit de ma vie et que je ne sais donc pas trop sur quoi elles se basent pour dire oui ou pour dire non…
Ces simulateurs permettent d’avoir une première indication : si c’est « clairement non sale pauvre ! », je pense que je peux oublier. Si c’est « Oui, probablement (sale un peu moins pauvre) ! », j’investiguerais davantage, en allant voir directement une banque.

À ce stade de ma réflexion, je n’ai pas besoin de devis précis.

Bref, après avoir renseigné ma situation personnelle, mes revenus, etc. vient le moment de donner le numéro de téléphone et e-mail. Autant pour l’e-mail, je donne une adresse e-mail dédiée à ce genre de sites, autant pour le téléphone, j’ai pas trop le choix que de donner mon unique et seule ligne portable. J’aurais pu leur donner ma ligne fixe (ma ligne ADSL en fait) : elle n’est reliée à rien et je ne l’ai jamais utilisé de ma vie (bienvenue au XXIᵉ siècle), mais elle ne me sert tellement pas que je j’y ait pas pensé (et je n’y ais jamais pensé du tout, en fait).

Résultat :

i

5 fois.

Ils ont essayé de m’appeler 5 fois dans la journée (en plus de m’avoir déjà appelé ce week-end déjà, juste après la simulation).

Et ça c’est sans parler des SMS que j’ai reçus ainsi que des e-mails, disant qu’ils ont essayé de me joindre par téléphone (sans déconner ?).

Foutez-moi la paix !
Je viendrai vers vous quand ça sera le moment.
J’irais directement sur votre site, et je pourrais m’engager gratuitement en un seul clic et sur le champ, ou bien me rétracter après 3 lettres recommandés, 40 € de frais de dossier et 15 jours d’attente (c’est pas comme ça que ça se passe ?).

Généralement, les banques et les assurances sont injoignables : on tombe toujours sur des robots à la cons ou des types à l’autre bout du monde qu’on ne comprend pas. Par contre pour souscrire là c’est Paris qui appelle avec les petites fleurs, le champagne, les banderoles, prostituées et tout le tralala (oui c’est du Pérusse, merci François). Bah.

J’aurais au moins appris un truc : la prochaine fois que je souhaite les joindre pour déclarer un sinistre à l’assurance ou demander une information relative à un prélèvement sur mon compte en banque, je passerais par un simulateur en ligne. Au moins j’aurais une vraie personne au bout de la ligne en moins de temps qu’il n’en faut pour le dire.

ÉDIT : 6 fois ;-;

Image d’en-tête

Pourquoi vous ne verrez pas le Soleil à partir de ce soir ?

mercredi 3 novembre 2021 à 18:06

Photo de la Lune.
Ce soir, vers 18 heures environ, ça va être tout noir1.

La raison à cela a été inventée2 par Kepler3 en 1609 et provient de la rotation de la Terre sur elle-même face au Soleil. Cette dernière n’éclairera alors plus du tout nos contrées et nous passeront dans l’obscurité.

Vous avez bien lu : le Soleil ne sera plus visible ! Merde alors.

Ce phénomène provoquera alors ce qu’on appelle dans le jargon scientifique « la nuit ». Par chance cependant, cette nuit devrait normalement se terminer approximativement à 07h24 UTC+1 (grosso-modo) demain matin et alors le Soleil pourra à nouveau éclairer le ciel et être visible si la météo le permet et que vous n’êtes pas aveugle.

En attendant, profitez-en pour rentrer chez vous, vous mettre à l’abri et peut-être dormir (c’est-à-dire vous allonger et rester ainsi de façon inconsciente durant 7-8 heures dans un lit) pour vous reposer.

Notes :


Pourquoi cet article stupide ?

Parce que si RTL se permet de le faire, et en disant beaucoup de conneries aussi : Nouvelle Lune : pourquoi vous ne verrez pas la Lune le 4 novembre (via Twitter).

Alors qu’on soit d’accord : je plussoie la vulgarisation scientifique.

Mais là on parle de RTL, une station de radio/télé généraliste francophone, pas de Dora l’Exploratrice ou des leçons de Monsieur Patate ! Les phases de la Lune c’est du niveau quoi… CP ? CE1 ? En tout cas pas exactement le genre de choses — à mon avis — que des adultes découvrent en écoutant la radio en allant au travail le matin. Ou alors le niveau en science en France est à un niveau particulièrement alarmant.

De plus, et c’est peut-être le pire dans tout ça : l’article parle d’une « Lune Noire ». Or il n’y aura pas de Lune noire ce mois-ci.

« Lune noire » n’est pas un terme scientifique, mais désigne bien quelque chose : c’est quand, au cours d’un même mois calendaire, on observe une deuxième nouvelle Lune. Le cycle lunaire dure 29,5 jours et il y a donc de la place d’en commencer un deuxième si le premier a début tout au début du mois. D’un point de vue astronomique, ceci n’a cependant aucune signification particulière. C’est juste un hasard du calendrier.

Ceci est loin d’être systématique : la prochaine sera en avril 2022 seulement : il y aura une nouvelle lune le 1ᵉʳ avril et une autre nouvelle lune le 30 avril ; cette seconde nouvelle lune porte alors le nom de Lune Noire. Pour la suivante il faudra ensuite attendre décembre 2024 !

Dans tous les cas, ce 4 novembre-ci ne marquera, en aucun cas, un tel phénomène. Dire le contraire est faux.

De la même façon, si un mois voit deux pleines Lunes, la seconde est appelée « Lune bleue ». Là également cela est un hasard du calendrier et le « bleu » ne réfère pas du tout à sa couleur. C’est plutôt une traduction contemporaine d’une déformation de l’expression « double lune », qui aurait donné « blue moon » en anglais.

Lune bleue ou lune noire… est-ce qu’on peut parler de phénomène rare ? Pas vraiment : elles se produisent chacun environ tous les 3 ans, ce qui est moins rare que les jeux olympiques ou une coupe du monde de football. Or personne ne parle des « rares jeux olympiques »…

Donc, @RTL : que vous fassiez de la vulgarisation sur des trivialités, ok, pourquoi pas. Quitte à remonter le niveau, autant commencer par le bas, et finalement c’est peut-être pas bête.
Mais alors remontez-le effectivement et ne racontez pas n’importe quoi.

Si vous racontez de la merde sur les phases de la Lune, arrêtez immédiatement, ça vaut mieux pour vous. Car le jour où vous allez parler des Kugelblitz ou du processus de Blandford–Znajek, ça va être un carnage.

(Par contre vous pouvez toujours demander de l’aide, si c’est votre projet).

image d’en-tête de Luke Stackpoole