Intro

Ce sujet n'arrête pas de revenir un peu partout et en particulier sur les réseaux sociaux (enfin, Twitter).

Mon intuition aurait été de dire que... Ben on s'en fout. Pourtant constate-je (??) que certains gens sont fortement investis sur la question à un point que ça en devient bizarre, comme si les défenseurs du camp "HTML et/ou CSS sont des langages de programmation!" menaient une croisade éternelle pour rétablir la justice de l'injustice qui doit forcément exister quelque part. Non?

Bon en fait je comprends pas très bien pourquoi cette question est si importante alors j'ai décidé de mettre mes gants, les beurrer, puis étudier les définitions dans les moindres détails d'élongation capilaire à outrance d'inutilité à l'instar des gens qui ont vraiment rien de mieux à faire mais que c'est quand même mieux que de passer toute sa journée sur les réseaux sociaux à intéragir avec les mêmes vieux trucs moisis depuis 2 ans, toutes les demi-heures, avec un faux pseudo genre "le pharmacien" ou "l'infirmier" qui me laisse d'ailleurs penser que ça pourrait être la même personne et que du coup c'est encore pire mais je m'égarre ça m'arrive parfois.

Je ne peux pas vous promettre une analyse ferme et complète et totalement objective. Après tout, je n'ai toujours pas réussi à expliquer raisonnablement pourquoi certains hôtels n'ont pas de brosses à chiottes dans leurs chambres, mais peut-être que vous pourrez construire autre chose sur certaines de mes bases et trouver d'autres théories ou me dire que j'ai TORT dans les commentaires en bas de l'article.

C'est quoi un langage de programmation?

C'est bien simple, une grande part de l'absurdité de la discussion vient du flou artistique autour de la définition d'un langage de programmation.

Je parle d'absurdité dans le sens où "tout le monde a raison" mais personne ne le sait. Il faudra peut-être relire cette phrase deux ou trois fois.

Pour les ultra-partisans du camp "HTML n'est pas un langage de programmation", ce sera sans doute une surprise de découvrir que:

Si on pose bien à plat certaines définitions dictionnaire les plus basiques, HTML et/ou CSS sont des langages de programmation.

Et quand bien même on étofferait la définition, il est également possible de tirer le pseudo-intellectualisme suffisamment loin pour que HTML et/ou CSS correspondent à la dite définition.

Mais alors ça veut dire que ceusse qui disent que HTML/CSS = pas un language de progammation, que j'abrévie désormais LP parce que j'en ai marre de l'écrire, ils ont tort?

Pas tout a fait, certains sont très certainement un peu trop sûrs d'eux mais d'autres de l'autre côté sont pas assez sûrs d'eux et ça fait des chocapics en fusion.

Examinons quelques définitions

Les définitions dictionnaire sont plutôt sommaires. On a pas trop la place pour y balancer tout un exposé.

Le Larousse présente un encart pour la programmation au mot "langage" que j'ai isolé ici pour vous:

Si je distille le truc:

• Il faut que ça implique des caractères. Genre du texte quoi, le truc qui est venu avec l'invention de l'écriture par l'humanité;
• Il faut que ce texte soit utilisé pour donner des instructions à un ordinateur.

Si on essaye d'appliquer cette définition à HTML ou CSS, oh surprise, ça passe comme du lait à la poste.

Vous allez me dire, attends une minute, HTML ou CSS ne donnent pas d'instruction "machine" à un ordinateur en direct, ils servent surtout à parler au moteur de rendu de logiciels très particuliers (les navigateurs, comme NETSCAPE).

C'est vrai mais pourquoi il faudrait que "donner des instructions à l'ordinateur" ça soit d'office donner des instructions au microprocesseur? Surtout que de toutes façons pratiquement tout passe par le microprocesseur et sa mémoire un moment ou l'autre.

Je rappelle que quand on programme en JavaScript, langage largement admis à raison comme "langage de programmation officiellement approuvé par Reddit et Twitter", tout doit aussi passer par le navigateur qui produira du langage machine selon ses propres règles après des transformations assez complexes.

Alors, oui, le champ du possible de qu'est-ce qu'on peut faire est bien plus vaste en JavaScript qu'en HTML+CSS (oui, même en les additionnant (ils devraient toujours être associés mais c'est une autre discussion)), je suis d'accord. Le soucis c'est que la définition, ici, s'en contrefiche le pantacourt de ce que le candidat LP est capable d'accomplir ou pas.

Déjà, Robert le dictionnaire parle de signes plutôt que de caractères et puis m'embrouille avec langage machine qui pour moi est totalement ancré comme étant les instructions que le microprocesseur comprends, par ex. "MET CE TRUC A CET EMPLACEMENT MEMOIRE LOL" ou "INCREMENTE DE 1 CET EMPLACEMENT MEMOIRE LOL".

Je suis biaisé (quelle surprise), j'ai déjà ma propre définition assez précise de langage machine alors que d'autres gens pourraient tout à fait avoir une définition beaucoup plus lâche et en soi ils ont pas tort.

Je tenterai d'expliquer plus tard qu'avoir une définition trop générale a moins d'utilité que quelque chose d'à a fois plus précis et usuel quand il s'agit d'expliquer des concepts à d'autres gens (CE A QUOI SERT UNE LANGUE ET SON VOCABULAIRE J'ANNONCE DEJA).

Sinon, la définition Robert est à peu près identique à celle du Larousse, on écrit des trucs et biduloïdes pour donner des instructions à un ordinateur.

Pour ceux qui sont en train de se dire "mais que dit Wikipedia!" — Leur premier paragraphe dit essentiellement la même chose avec un petit ajout non négligeable (OUUH l'horrible prise de positionnnnn) sur l'article anglophone:

Ce qu'on peut traduire en:

Un langage de programmation est un langage formel comprenant un ensemble de caractères qui produit différents types de code machine en sortie. Les langages de programmation sont un type de langage informatique, et sont utilisés dans la programmation informatique, pour implémenter des algorithmes.

Ils introduisent l'idée que les langage de programmation feraient partie d'une catégorie plus large de langages informatiques, et seraient une forme spécialisée de ces langage déterminée à implémenter des ALGoRiTHmEs.

C'est l'autre type de définition, qui cette fois n'inclus ni HTML ni CSS à moins de tirer sur l'argumentation très, très fort. Je tenterai de me commettre l'avocat de ce tirage un peu plus loin.

Pour être complets, sortons aussi le premier paragraphe de l'article Wiki en Français:

L'histoire des "langages informatique" n'est pas évoquée, pourtant on parle bien d'une finalité à formuler des algorithmes et produire des programmes qui les appliquent.

Un algorithme étant une certaine suite d'opérations qui permet de produire un résultat utile (dit aussi "résoudre des problèmes" même si c'est des problèmes qu'on a inventé parce que les humains sont un peu bizarres).

Ils utilisent générallement des données d'entrée, font des trucs et des machins avec puis sortent un ou plusieurs bidules hypothétiquement utiles en sortie.

Par exemple, Facebook peut prendre en entrée absolument tous les commentaires que vous avez postés et toutes les publications sur lesquelles votre souris a traîné plus d'une seconde (ce sont les données entrée) compter ensuite les mots qui reviennent le plus souvent dans ces contenus (opération sur les données d'entrée) et sortir le mot qui a été le plus vu, de sorte à pouvoir l'utiliser pour rechercher des pubs qui le contiennent à vous afficher.

Cet exemple est évidemment un tantinet simplifié. Quoique, l'intelligence artificielle c'est souvent juste un vieil algorithme très stupide mais ça c'est un autre débat.

Nous verrons plus loin qu'HTML+CSS sont, contre toute attente, capables de réaliser certains algorithmes sans avoir à invoquer un triple doctorat en mathématiques de chirugie philosophique (ce sera pour plus tard dans l'article).

Par contre, ces langages sont assez limités dans le type d'algorithmes qu'ils peuvent implémenter, là où un langage de programmation comme JavaScript ou Ruby peut implémenter n'importe quel algorithme bien que son exécution reste toujours bornée dans le cadre des limitations du monde réel (temps pas infini parce qu'on est des pauvres mortels, énergie pas infinie, mémoire limitée).

Tant qu'on y est, retenons bien le choix d'exemple des deux articles wiki sur les LP parce que peut-être que ça indique quelque chose d'intéressant:

Mais bon... C'est peut-être juste BIGWIKI qui révèle enfin son agenda anti-HTML/CSS.

Et la programmation c'est quoi?

Sortons à nouveau quelques définitions! Parce que moi ça me semble un peu logique qu'un langage de programmation ait quelque chose à voir avec la programmation informatique. Vous pensez que c'est raisonnable? M'en fous tfaçon.

Le Larousse parle d'écritude de programmes informatiques:

T'en a d'autres qui disent qu'en gros ben c'est quand-ce-que tu fais un programme quoi:

Plus intéressant, Le Robert cite des exemples de LP, j'espère qu'il y aura HTML et CSS dedans!

Faut qu'on parle de Turing-complétude

Avant de vous faire fermer cet article à cause de cette section, il faut que je vous confie que la Turing-complétude n'est pas considérée nécessaire pour qualifier un langage de programmation.

Pourquoi? Vous avez pas lu les définitions juste avant ou quoi?

Même si on utilise les définitions qui parlent d'implémenter des algorithmes, la Turing-complétude, qualité des langages dit Turing-complets, n'est pas nécessaire pour qualifier un LP.

En effet, être Turing-complet implique que ce langage/dispositif est capable d'implémenter n'importe quel algorithme (hors réalité du temps qu'il nous reste sur terre, de la mémoire etc.).

Moi je trouve personnellement qu'un LP est censé pouvoir implémenter n'importe quel algorithme, mais pour l'instant c'est une opinion que je n'ai pas encore pu défendre (CA VA VENIR JE SUIS SÛR VOUS AVEZ TROP HÂTE).

Déjà, premier soucis avec les démonstrations de Turing-complétude: le sujet est démontré capable d'implémenter n'importe quel algorithme mais il n'y a aucune considération pratique, ça pourrait vous prendre 30 ans pour créer un jeu de pendu en binaire qui doit se jouer avec 2h de traduction à chaque tour dans un système chelou qui a été prouvé Turing-complet.

Du coup ne soyez pas surpris de découvrir que énormément de programmes (dont Powerpoint, bien entendu) et langages sont Turing-complets. Ils sont capables d'implémenter n'importe quel algorithme tout comme un slip peut servir de bonnet, vous avez juste l'air con et c'est pas très chaud, quoi.

D'où ça vient ces concepts Turing-machin?

Le nom vient d'Alan Turing, mathématicien philosophe (non, je rigole pas) qui a inventé toutes sortes de théories autour des années 1930 qui traitent du concept de décidabilité (computability, c'est un Anglais ce monsieur).

Si vous avez déjà mal de tête, c'est normal.

On lui accorde l'invention du concept d'un programme et de la programmation de machines mécaniques capables de résoudre des problèmes.

Son expérience de pensée la plus connue est probablement la Machine de Turing (machine imaginaire, je précise), qu'il démontre (je pense qu'il le démontre, en vrai j'ai rien compris) être capable d'implémenter n'importe quel algorithme.

C'est quoi une machine de Turing

C'est une bande magique infinie découpée en section de longueurs égales sur lesquelles on peut inscrire ou non un symbole tiré d'un alphabet à définir. On peut aussi présenter ça autrement en disant qu'il y a toujours un symbole mais que l'alphabet peut contenir l'équivalent d'un symbole vide. Mais on va pas déjà chipoter hein.

La machine en elle-même peut se trouver dans différents états à définir (A, B, C, D, ou encore "tout nu", "habillé", ce genre de choses).

Lorsque la machine tourne, une tête de lecture est capable de lire la bande puis utilise une table de vérité pour décider de ce qu'elle doit faire, ce qui implique une ou plusieurs actions à entreprendre selon le symbole lu et l'état actuel de la machine.

Ces actions pouvant être:

• Effacer ou modifier le symbole;
• Déplacer la bande vers la gauche ou la droite (d'un nombre à définir de pas);
• Changer l'état de la machine.

Un des états peut correspondre à l'arrêt de la machine.

Important: cette machine-là n'est pas Turing-complète parce qu'elle a un jeu particulier de paramètres (l'alphabet, les états, la table de vérité).

Une machine de Turing universelle est Turing-complète parce qu'elle est capable d'émuler n'importe quelle autre machine de Turing, quelqu'en soient les paramètres (càd l'alphabet, etc.).

Je répète que ce concept est abstrait bien qu'il existe des implémentations de machines de Turing particulières. Je mets pas de photo parce qu'on s'en fout et c'est moche.

A retenir donc: si quelque chose est Turing-complet, ça signifie que cette "chose" est capable d'émuler une machine de Turing universelle.

Zavez compris? Je vous crois pas. On continue.

Quelques exemples

Juste d'emblée là, comme ça, je peux vous sortir tout un tas d'exemples de trucs qui sont Turing-compelts:

• Tous les langages du genre C, Java, JavaScript, Python, Scratch, Perl, Pascal, Go, Rust, Ruby, PHP, ... Je sais pas trop comment on a le droit de les appeler c'est un peu le sujet de l'article;
• Le jeu de démineur (uniquement si le plan de jeu est infini - Ouais du coup bof quoi);
• PowerPoint (ben ouais);
• LaTeX;
• Excel;
• Minecraft;
• Le jeu de cartes Magic the Gathering;
• HABBO HOTEL (si t'as moins de 30 ans tu sais probablement pas ce que c'est et c'est pas grave).

Si vous avez une carrière académique en math ou algorithmique, démontrer que [INSERER PRATIQUEMENT N'IMPORTE QUOI ICI] est Turing-complet ça passe toujours comme travail pratique ou de fin d'année.

C'est à dire que pratiquement tout est Turing-complet si on en a vraiment très fort envie et qu'on ajoute deux ou trois acteurs si nécessaire. Par ex. deux chimpanzées qui jouent au Uno c'est sûrement Turing-complet. Est-ce qu'on va l'exploiter pour créer une nouvelle crypto-monnaire? Probablement pas.

Le cas HTML+CSS

Il se trouve que, HTML + CSS + UN-HUMAIN_QUI_CLIQUE-SUR_KESKON_LUI_DIT (ben oui vous avez pas ça chez vous?) est Turing-complet. La classe hein?

L'implication serait donc qu'il est possible d'exécuter n'importer quel algorithme en utilisant juste HTML, CSS et un humain-qui-clique (je plaisante pas, c'est essentiel).

Etant donné que tous les langages du type C, Java, Python etc. sont Turing-complets, cela voudrait dire qu'HTML+CSS (+humain_qui_click mais on peut faire semblant de l'oublier) est équivalent à ces langages. Non? Je crois?

C'est l'implication en tous cas et ça signifie que si quelqu'un voulait limiter le concept de langage de programmation aux langages Turing-complets, ben HTML+CSS (+humain_qui_fait_ce_qu'on_lui_demande) sont aussi conformes à cette définition.

Mince alors...

Démonstrations

Cette section va être un peu brutale mais je pense que c'est important d'intégrer la magistrale ampleur du musée du Louvre en allumettes grandeur nature qu'il s'agit de construire pour prouver la Turing-complétude (oui c'est comme ça qu'on dit) de quelque chose qui est pas trop prévu pour être utilisé comme calculatrice.

Je rappelle qu'une machine de Turing universelle — Concept abstrait basé sur un autre concept abstrait à base de bande inscriptible infinie — est capable d'émuler n'importe quelle machine de Turing et est Turing-complète.

Par conséquent, il "suffit" que l'objet d'étude soit capable d'émuler une machine de Turing universelle pour être Turing complet.

Reste qu'une machine de Turing c'est un truc assez complexe mine de rien, et puis ça existe pas aussi.

L'aubaine c'est que les mathématiciens ont trouvé un plan B qui consiste à démontrer que l'objet est capable d'émuler un SYSTEME DE TAGUE qui est un autre bidule théorique à base de bande inscriptible inventé en 1943 par Emil Leon Post.

L'ensemble de ces systèmes est Turing-complet en cela qu'il est possible de représenter toute fonction calculable par un système de tague.

C'est quoi un système de tague?

Il y a de nouveau une bande avec des symboles, lesquelles sont tirés d'un alphabet donné.

Le fonctionnement est par contre plus simple et systématique qu'une machine de Turing:

1. La machine lit le prochain symbole sur la bande;
2. Le symbole passe dans une moulinette/fonction/jeu de règle;
3. L'étape précédente détermine une séquence de symboles à ajouter à la fin de la bande;
4. Le système supprime ensuite les m (m est constant) premiers symboles de la bande.

Les paramètres du système de tague sont:

• m — Le nombre de symboles à effacer du début de la bande à chaque itération. Les modèles les plus courants utilisent m=2. C'est considéré comme le paramètre principal du système de tague;
• A — L'alphabet fini qui contient l'ensemble des symboles possible que l'on puisse trouver sur la bande initiallement ou après;
• P(x ϵ A) - Ensemble de fonctions (règles de reécriture), une par élément de l'alphabet, qui déterminent ce qu'il faut ajouter à la fin de la bande lors de la lecture du symbole "x";
• L'état initial de la bande.

L'exemple bateau c'est un système de tague qui permet de déterminer si un nombre est pair ou impair:

• m = 2
• A = P, I, X
• Règles de remplacement:
  • X → Chaîne vide (rien quoi)
  • P → P
  • I → PI

On initialise la bande avec deux "I" suivis d'un certain nombre de "X" qui correspond au nombre dont on cherche à déterminer la parité. Ou la non parité. L'imparité? La paparité.

Prenons tout de suite un chiffre difficile: 3. A chaque itération on lit le premier symbole, regarde dans les règles de remplacement et on ajoute le ou les caractères mentionnés à la fin de la séquence, puis on efface les deux premiers symboles (puisque m=2). Voici toutes les itérations, une par ligne:

IIXXX
  XXXPI
    XPI
      I

Et voilà quoi, s'il reste "I" c'est que c'est impair. Vous pouvez essayer avec un chiffre pair il devrait rester "P".

Mais attends une minute là, avec HTML+CSS et un sélecteur de type nth-child on peut "coder" un truc qui détermine si un certain nombre de DIV (désolé je devais choisir un tag) est pair ou impair.

Oui, on peut. Ceci dit, avec les systèmes de tague on peut "coder" n'importe quoi si on en a vraiment (fort) envie.

Le système retire un nombre constant de caractères à chaque intération, mais peut ajouter (ou non) une quantité arbitraire de symboles à la fin de la bande. Si les symboles sont 0 et 1 on peut même réaliser toutes sortes de bidules en binaire.

Si vous voulez en savoir plus (on sait jamais hein lol), cet article est très complet et pas trop compliqué pour ce qui est d'expliquer la démarche de démonstration de Turing-complétude.

HTML+CSS+HUMAIN QUI CLICK est Turing-complet

Pour le démontrer, la démarche habituelle serait de prouver qu'HTML et ses copains (sauf JavaScript qui est puni on sait pas trop pourquoi en fait c'est un peu le sujet de l'article que c'est totalement absurde qu'on a pas le droit de mentionner JavaScript) sont capables d'émuler n'importe quel système de tague.

Et c'est ce qui est proposé sauf qu'il faut absolument invoquer un niveau de plus de profondeur de tirage capilaire.

La majorité du "pouvoir algorithmique" (oui je viens d'inventer ce concept) de HTML+CSS provient de l'interactivité des éléments input de type checkbox ou radio.

En effet, ils sont capables de maintenir un état binaire (je suis coché ou pas?) et le CSS peut appliquer ou non des règles selon cet état. Et voilà, toutes les démos de Turing-complétude HTML/CSS sont basées sur ça.

Pour être honnête ça m'avait épaté qu'on pouvait utiliser ces concepts pour, par exemple, réaliser un menu de navigation animé à afficher ou cacher sans aucun JavaScript, et je l'utilise un peu partout.

Je vous ai fait une "démo" (ouais c'est pas très clair) ici, où on sent mon amour du CSS transpirer des ports de votre navigateur:

L'astuce (sacrée astuce) consiste à utiliser les boutons radios ou checkbox et des sélecteurs CSS relativement complexes de sorte à créer un automate cellulaire car certains d'entre-eux sont capables d'émuler un système de tague et par conséquent une machine de Turing et par sur-conséquence conséquente, sont Turing-complets (je vous avais dit qu'il allait falloir creuser).

- C'est quoi cette affaire d'automates cellulaires maintenant là dis moi t'es sérieux?

Ce sont des grilles en 1 ou plusieurs dimensions (les plus connus sont en 2D) où chaque "cellule" de cette grille sont dans un état donné parmi un ensemble fini. A chaque itération (simule le temps qui passe), les états des cellules peuvent évoluer selon des règles qui impliquent générallement l'état des cellules voisines.

C'est un truc un peu bizarre mais fascinant, et qui sort aussi vaguement des bornes de cet article qui a déjà des drôles de bornes en ce moment.

Comme exemple, on peut citer le fameux Game of life, automate en deux dimensions qui peut ressembler à cette image que je viens de voler sur Wikipedia:

Selon l'état initial de la grille, le "Game of Life" peut évoluer de manière totalement chaotique ou se stabiliser, voire créer des motifs qui se répètent (comme sur l'illustration) et/ou se déplacent - on les appelle alors les VAISSEAUX SPATIAUX parce que c'est l'automate qui se casse de sa grille pour découvrir l'univers (possible que ça soit juste le Jef Bezos de l'écosystème qui se casse de ce monde de merde en fusée en forme de courgette avec des veines).

Il existe un automate cellulaire très particulier, en une dimension, qui s'appelle la "règle 110".

Partout sur les images et les "simulations" on le représente en 2D, mais cette représentation montre en réalité une itération de temps par ligne. On y voit donc l'évolution dans le temps ligne par ligne de haut en bas.

Les cellules de rule 110 peuvent présenter deux états: 0 ou 1. Comme les éléments input (checkbox ou radio) en HTML, ça tombe bien!

Un bonhomme nommé Matthew Cook démontre dans ce document que Rule 110 est Turing-complet, en utilisant la méthode classique c'est à dire émuler un système de tague avec.

Enfin, la méthode classique... Faut le dire vite. Je vous conseille pas d'essayer de lire le document à moins d'être prêts à sérieusement reconsidérer le sens de la vie, et je dis pas ça uniquement parce que ça parle de vaisseau spatial.

Reste plus qu'à réussir à créer un "automate" (ce sera très moyennement automatique parce qu'on a besoin de quelqu'un pour cliquer sur les checkboxes comme j'ai dû déjà le mentionner deux ou trois fois) rule 110 en HTML et CSS.

L'exemple le plus souvent cité est normalement à cet endroit, et je pense que c'est lié à ce repo si jamais le site est down.

Sauf que euh... Chez moi il se passe rien du tout:

Je comprends bien que l'idée c'est de sélectionner un élément avec tab puis utiliser la barre d'espace pour l'activer (ou pas) sauf que là j'y arrive vraiment pas (avec Chromium ou Firefox). Peut-être la faute à mon Linux?

Je vois bien les fantastiques sélecteurs CSS tout à fait usuels que tout le monde reconnaîtra:

input:not(:checked) +*+*+*+ input:checked +*+*+*+ input:checked + label + input.B:focus {
  display: block;
}

Où on sélectionne les éléments input qui ont le focus et qui sont voisins d'un label qui est voisin d'un input coché qui est voisin de n'importe quoi qui est voisin de n'importe quoi qui est voisin de n'importe quoi qui est voisin d'un input coché qui est... Ouais vous voyez le truc. Ou peut-être pas. On s'en fout (je rappelle que même l'auteur a mis stupid dans le nom du repo).

Bon du coup pour la démo "officielle" c'est pas trop ça.

Les démos qui fonctionnent demandent de préparer une première ligne comme on la souhaite, puis il suffit de cliquer sur toutes les cases oranges de la ligne suivant sans réfléchir, et ainsi de suite:

Je vous montre trois itérations ci-dessous, il faudrait cliquer sur les cases oranges pour avoir la 4ème (enfin je pense lol).

Evidemment si vous devez "écrire un programme" par le biais d'un automate rule 110, par ex. une conversion de X degrés celcius en fahrenheit, ça risque d'être un challenge plus complexe que faire pousser une vessie dans une marmite ou de fabriquer un slip en miel.

Alors que bon, avec JavaScript qui, je le rappelle, est juste dispo dans le navigateur au même titre que CSS et HTML, on crée un convertisseur degrés celcius vers farhenheit en 3 lignes de code.

Ceci dit certaines choses assez surprenantes peuvent fonctionner sans aucun JavaScript. J'ai djà cité l'exemple du menu de navigation plus haut, c'est aussi possible de créer un jeu de Tic Tac Toe (dit aussi OXO) sans aucun JavaScript (de nouveau à base d'éléments input, évidemment, c'est un peu le point commun de tous ces exemples):

https://codepen.io/uryelah/pen/MWWeLwP

Conclusion

C'est bien d'avoir la possiblité théorique d'exécuter n'importe quel algorithme mais si en pratique ça prend 3 ans, une dépression et un doctorat en maths je vois pas trop l'intérêt.

Utiliser la Turing-complétude seule pour définir un LP ça sert à rien. Juste que si quelque chose n'est pas Turing-complet, ce n'est probablement pas un LP.

Alors, finalement, quel est le verdict?

Est-ce qu'on pourrait-y enfin savoir si HTML et/ou CSS sont des langages de programmation? Hein? Il serait peut-être temps là?

Hah! Si vous êtes arrivés jusque ici vous avez une petite idée que peut-être c'est pas si simple.

Si on s'en réfère à certaines définitions du type "dictionnaire", HTML ou CSS sont des LP. Idem si on ajoute que la Turing-complétude — càd la capacité à pouvoir exécuter n'importe quel algorithme — est nécessaire. Bon sauf qu'il faut ajouter un humain-qui-clique mais on est pas à ça près hein.

Alors on dit que c'est des LP et on arrête l'article?

... Genre ça allait être si simple ou quoi.

Concepts récents, changements, environnement

Le concept de LP est relativement récent. Même les travaux de Turing datent d'un peu avant la seconde guerre mondiale et les premiers ordinateurs dit PéCés sont apparus bien plus tard.

Par conséquent, certaines idées ne sont pas nécessairement bien poncées au niveau langue qui est un truc vivant qui évolue, qu'on le veuille ou non, un peu comme la culture, les virus, toussa toussa.

Déjà juste ça, ça nous crée un fossé automatique parce qu'il y a toute une classe de gens qui détestent que les choses changent et qui est en éternel conflit avec les gens qui veulent que tout changer tout de suite et peu importe les effets de bord, c'est un devoir moral!

Oui ce sont en gros les conservateurs et progressistes.

A force d'observer les humains vous aurez sans doute remarqué qu'on a tous une tendance légèrement renforcée d'un côté ou de l'autre.

Parfois c'est pas mal d'essayer de voir les choses comme un ultra-conservateur ou ultra-progressiste alternativement de temps en temps histoire de comprendre leurs motivations et raisonnements. Bien évidemment, absolument personne ne fait ça et on préfère renforcer le fossé en devenant le plus borné possible à coup de désinformation et de chambres d'echo.

On en est arrivés à un tel point que certains réseaux sociaux comme Twitter mettent ces gens ensembles dans des genre de ghetto, cachent toutes leurs réponses aux gens "normaux" (désolé) pendant qu'eux se likent/retweet/follow non stop et ne voient plus que la même désinformation, H24, toute l'année.

Bon faut bien avouer que la désinfo "de droite" est en ce moment bien plus dangereuse que celle de gauche, en général. Par ex., dire que les vaccins covid sont totalement inefficaces est bien plus dangereux en terme de dégats que dire qu'un seul milliardaire peut "arrêter" la faim dans le monde, même si les deux sont de la désinformation.

Comment j'ai fait pour m'égarer comme ça moi? Le fait est que, c'est simple d'avoir une définition unique, formelle et exhaustive sur laquelle absolument tout le monde s'accord (ou a tort) pour un théorème de math. En dehors des maths par contre, c'est CHAUD.

Utiliser le dictionnaire comme défense est moyennement valide, puisqu'il y a plusieurs dictionnaires qui sont parfois en désaccord et que les définitions évoluent avec le temps.

Qu'est ce que moi j'en pense

Je pense que les définitions doivent être utiles.

La langue sert à communiquer des idées et concepts, parfois très complexes. C'est magique de pouvoir évoquer efficacement un concept imagé dans la tête de quelqu'un juste en utilisant des mots.

Le savoir en lui-même sert de base réutilisable et nous permet d'aborder des concepts encore plus complexes, en profitant de squatter sur les épaules des géants d'autrefois.

En résumé: il est nécessaire qu'un terme ait une utilité à pouvoir rapidement et précisément exprimer un concept sans avoir recours à une farandole d'astérisques.

Moralité et inclusivité

Je disais plus haut que l'utilité d'une définition a, selon moi, toujours priorité.

Tout le monde ne partage pas cet avis. J'en parle dans une section ultérieure qui s'appelle sans doute POURQUOI ou un truc du genre, mais il semblerait que le moteur de l'engouement autour de "HTML/CSS sont des LP" soit en grande partie un désir d'inclusivité et de tenter de maximiser le confort mental de tout le monde par rapport aux termes utilisés.

Pour faire simple, on pourrait vaguement le relier au désir de retirer des termes comme "maître" et "esclave" en informatique.

Ces mesures sont assez populaires bien qu'évidemment détestées par les personnes à tendance naturelle conservative.

Cependant, si on réfléchit à ce cas particulier de renommage de la banche master en main pour Github... Est-ce que ce changement de terme entraîne une perte d'utilité? Moi je trouve pas. Genre, vraiment 0. Ça change rien.

On pourrait juste s'inquiéter de "est-ce que ça va ruiner tous mes vieux programmes?" et ça c'est effectivement valide. Dans le cas de Github, le changement est (à ma grande surprise je dois dire) totalement indolore. Oui j'en reviens toujours pas. Il n'y a donc aucune objection raisonnable à empêcher ce renommage de branche et si quelqu'un s'y oppose, je vais avoir tendance à penser qu'il s'agit de quelqu'un qui a un dégoût naturel face au changement — et y a pas de mal à ça, changer trop et trop vite peut réellement avoir des conséquences délétères qui devraient être envisagées dans la discussion.

Au niveau moral, certains vont toujours préférer que le langage soit tel qu'il y ait le moins de risques possibles qu'il engendre une détresse émotionnelle chez quelqu'un (un peu similaire à la création et popularisation des Trigger Warnings).

Pour le cas HTML/CSS, je trouve que, si on les inclus dans le terme LP, on perd tout de même pas mal d'utilité alors que la détresse émotionnelle engendrée est selon moi le symptôme d'autres problèmes et il existe dès lors une discussion plus productive à avoir pour tenter de régler le problème de fond.

Je vais évidemment disserter là dessus pour le reste de l'article. Je sais, Youpie.

Je tiens à répéter que si un changement de définition quelque part fait que des gens se sentent mieux, c'est tout bénef et je suis pour! Par contre je trouve qu'il est judicieux de tenir compte de l'utilité qui pourrait être perdue suite à ce changement.

Je peux vous donner tout plein d'exemples qui [potentiellement] fachent. Par ex. les pronoms, pour moi ça ne change absolument rien d'appeler quelqu'un par tel ou tel pronom si ça met cette personne plus a l'aise. La perte en utilité est pratiquement de 0 et l'autre personne est contente. C'est tout benef.

Par contre, devoir systématiquement et proactivement demander les pronoms des gens lors d'un événement social ou trouver qu'une erreur commise par rapport à un néo-pronom un peu obscur est inadmissible, ça c'est un peu contre-productif... Faut pas oublier qu'à l'heure actuelle il y a pas mal de gens qui ne savent même pas que ça existe les personnes trans, encore moins les non-binaires.

Si vous poussez vos exigences de changement trop loin et trop vite, vous n'allez pas faire avancer votre cause. Ceci dit, je le répète, pour certaines personnes l'utilité d'avancer la cause n'est pas la priorité. La priorité absolue c'est le confort mental immédiat des minorités et autres gens générallement laissés-pour-compte. Ce qui est admirable et nécessaire en soi. Le soucis c'est qu'on peut pas avoir le beurre, l'argent du beurre, le sourire de la crémière et transformer la crémerie en coopérative ouvrière en même temps tout de suite et sans coûts ou conséquences négatives additionnelles prévues ou pas.

Je vous laisse un autre genre de dissertation encore plus longue que la mienne, écrite par quelqu'un de progressiste qui dissèque de manière très objective différents obstacles que son propre "camp" progressiste se fourre dans les roues tout seul.

Bien sûr, vous l'aurez compris, cette discussion sort du cadre déjà tout foireux de cet article.

Une définition utile de langage de programmation?

Mettons-nous dans les bottes de quelqu'un qui doit expliquer à un néophyte ce qu'est un LP, ainsi qu'expliquer ce que sont HTML, CSS et JavaScript, par exemple.

Si on s'en réfère à une définition de LP du genre "texte qui donne des instructions à un ordinateur" on a immédiatement le soucis que tous les langages et formats en informatiques sont alors automatiquement des LP.

Ce qui inclut HTML et CSS, mais aussi le XML ou CSV, RTF, LaTeX, et même un document Word.

Est-ce qu'on a vraiment besoin d'une définition qui brasse aussi large pour un terme composé comme "langage de programmation"? Ne pourrait-on pas utiliser "langage informatique" pour englober absolument tous les langages, et puis spécialiser?

Wikipedia est plus ou moins d'accord avec moi bien que, évidemment, il s'agisse d'une prise d'opinion. Pourquoi ne pas utiliser "langage de programmation" pour englober tous les langages informatiques existants, finalement?

Et puis ensuite on utilise "langage de programmation à usage général" pour qualifier des langages comme Rust et Python. Apparemment le Wikipedia francophone a eu cette idée fantastique et tellement simple à retenir (#SARCASME).

En soi, quand quelqu'un parle de programmation à l'heure actuelle, personne ne pense à des cartes perforées pour métier à tisser ou piano automatique et on imagine une machine moderne style ordinateur portable voire téléphone, à la limite une de ces tours pécé pour darons ou un pécé gamer avec 20 watts de LEDs de toutes les couleurs. On limite déjà automatiquement le champ du possible dans notre petite tête.

Selon moi, à l'heure actuelle, utiliser "langage informatique" comme terme global est bien plus utile que d'utiliser LP, et je vais tenter de vous le démontrer.

Comment que j'expliquerais ce que c'est un LP

Je diviserais ça en deux points.

1. Faut taper du texte

C'est déjà contentieux parce qu'il existe des langages de programmation graphique comme Scratch ou Labview, qui est le Scratch pour adulte.

Rien n'empêche de bien ajouter "graphique" quand on parle de ces LP, et tout va bien. C'est même plus clair et donc tout benef.

Normalement, un LP, c'est du texte. Par conséquent, HTML et CSS sont OK pour le point 1. Parce que c'est du texte. Youpie. Plus qu'un point.

2. Le texte peut être utilisé pour créer ou exécuter un programme informatique de manière raisonnablement simple

Ce qui demande vaguement de définir "programme informatique".

Le programme représente un ou une série d'algorithmes ou opérations à donner à un microprocesseur.

Au plus bas niveau ce sont des instructions réelles sorties d'un jeu bien spécifique et qui se suivent avec la possibilité de présenter des sauts vers l'avant ou l'arrière du programme qui peuvent être conditionnels (et dès lors, créer des boucles).

Un LP ne doit pas nécessairement être immédiatement traduct... Tradubjdf... traduisible en instructions microprocesseur (= compilation en langage machine), il est courant qu'il y ait toutes sortes d'intermédiaires, les plus courants étant des "interprêteurs".

Par contre, les LP utilisent un formalisme relativement proche du langage machine (= ce que comprends le microprocesseur) avec des structures de contrôles (si tel emplacement mémoire vaut ci, fait ça) ou des boucles comme évoqué précédemment. Même Scratch, qui est particulièrement loin du langage machine en terme de situation, présente ces caractéristiques.

HTML et CSS? Pas trop.

Pour qu'un programme soit utile (ce qui est quand même pas mal) il reçoit certaines données en entrée, effectue des traitements sur ces données, et génère un résultat ("la sortie"), lequel est censé être utile à euh... le truc qu'est-ce que vous vouliez faire.

Les traitements ça peut être n'importe quoi y compris des trucs qui ne vont jamais s'achever, planter la machine, prendre 50 ans ou stocker une immense quantité de résultats intermédaires en mémoire, pourvu qu'il y en ait suffisamment.

Imaginons un programme qui prend en entrée le texte "t'as une tache là!" et comme traitement il affiche cette entrée sur l'écran en gras et en rose.

Il s'agit effectivement d'un programme, que HTML et CSS sont typiquement capables de produire. Le problème c'est qu'à peu de choses près (oui si on est très chaud on peut créer certains jeux à base de checkboxes et de sélecteurs CSS qui donnent mal de tête) HTML et CSS ne permettent que de créer ce type de programmes et rien d'autre.

Mais, DIIIIICK, HTML/CSS/humain_cliqueur est Turing-complet tu te souviens?

Oui je me souviens. C'est un peu comme si quelqu'un vous montre un couteau et vous annonce que c'est une fourchette.

Vous dites que non, c'est un couteau! Oui mais oui mais, vlaty pas qu'il svous démontrent, tout guillerets, qu'en plantant le couteau bien fort dans le navet on peut s'en servir comme d'une fourchette foireuse et porter le dit navet à sa bouche.

OK? Cool. Je sais plus de quoi on parlait.

Ah oui! Il y a des gens qui sont tout rouges parce que je viens de dire qu'HTML ou CSS sont incapables d'effectuer des traitements et c'est pas vrai, ils sont capables d'effectuer certains traitements et conserver un genre d'état modifiable en mémoire.

Par ex., CSS comporte un système de compteurs que personne n'utilise, et on peu imaginer qu'il va s'étoffer d'autres fonctions dans l'avenir que probablement personne n'utilisera.

Concernant HTML, je crois que je ne dois plus vous présenter les FAMEUSES CASES A COCHER.

Ce qui m'amène au dernier qualificatif: un LP doit permettre l'implémentation de n'importe quel algorithme de manière raisonnablement simple.

Parce que, oui, on peut tuer un poulet avec une Knacky surgelée si on veut vraiment fort mais ce serait tout de même mieux une hache. C'est pas pour rien que les tigres ont quattre longues dents pointues plutôt que quattre Knackis dans la bouche.

Je m'excuse si vous êtes vegan je sais pas d'où m'est sortie cette histoire de Knacky et de poulet.

Appuyons encore un coup: si ça me prend trois semaines pour coder un convertisseur de degrés celcius/fahrenheit en utilisant le langage X, c'est que c'est juste pas un LP.

Evidemment si ce test ultra spécifique passe ça veut pas dire que c'est un LP aussi. Une calculatrice c'est pas un LP, on est d'accord.

Disons qu'il faut pouvoir coder un convertisseur celcius/fahrenheit et un jeu de pendu en un temps et avec un niveau de pénibilité raisonnable.

En fait, un LP devrait toujours également être capable de créer un autre LP. OUAAAAAAAAAAHhhh... Sérieux??

Bah ouais. Program-ception. Truc du genre.

Je ne vais peut-être pas vous l'apprendre, mais le compilateur C le plus connu, ben il est majoritairement écrit en C. Ben ouais...

Cependant, le compilateur aurait pu être écrit en n'importe quel autre langage, même un langage interprêté. On aurait juste eu un compromis de performances et de difficulté, mais c'est faisable.

Est-ce que je peux écrire un "compilateur HTML+CSS" en HTML+CSS? Non. En ajoutant JavaScript, oui. D'ailleurs il existe des moteurs de templates en JavaScript qui transforment un langage de formattage qui n'est pas HTML en HTML.

Définir par l'exemple

Vous vous souvenez peut-être de certaines définitions dictionnaire, ou des articles Wikipedia en anglais et en français que ce citais plus haut en mettant en évidence leur choix d'exemple.

Les exemples montrent toujours des LP qui incluent pratiquement tout (y compris COBOL) mais pas HTML ou CSS.

Effectivement, je pense qu'un quelconque quidam de bonne foi ne vas jamais choisir HTML et/ou CSS comme exemple dans le but d'expliquer à quelqu'un ce qu'est un LP.

Imaginez que vous deviez créer un jeu de pendu ou un remake de Bonzi Buddy comme exercice. Si c'est pas réalisable à base de case à cocher et sélecteurs CSS basés sur ce statut coché ou pas et celui des voisins, et que c'est pas juste AFFICHER UN TRUC, ça va pas le faire en HTML/CSS.

Garder LP mais ajouter des qualificatifs

Je me répète un peu, mais la substantifique essence intellectuelle du conflit est que certains individus sont partisans d'élir l'expression "langage de programmation" pour désigner n'importe quel langage textuel que-tu-tapes-sur-un-ordinateur et préconisent d'ajouter toutes sortes d'adjectifs derrière pour pouvoir plus précisément expliquer la différence entre HTML et C++, par exemple.

Oui, ça revient au même que d'utiliser langage informatique globalement puis qualifier en langage de présentation, formattage etc. Mais on est censé être plus inclusif... Gentil? En utilisant LP comme terme générique.

Parce que si y a pas programmation dans la désignation du truc, c'est nul. C'est bien connu (???).

On peut partir sur "CSS et HTML sont des langages de programmation délcaratifs à domaine spécifique":

Mais alors, comment on appelle un langage comme Java ou C#? Un "langage de programmation impératif de... Traitement"? Vous aussi vous trouvez que ce serait plus simple de finir en "langage de programmation impératif" puis virer le "impératif" et du coup on tombe sur juste "langage de programmation"?

Pour être honnête, je pourrais envisager d'appeler HTML/CSS des "langages de programmation de présentation". J'ai juste la même critique relative à utiliser LP comme terme générique pour tous les langages utilisés sur un ordinateurs et j'ai pas l'impression que ce changement, qui complique le terme (langage de présentation ou langage de formattage sont plus courts) soit intéressant à part pour sa valeur morale ou inclusive que j'étudie plus loin.

Je pense que le soucis c'est cette idée latente que "si c'est pas un LP c'est caca" et le manque de confiance en eux des gens.

Rendons tout ceci plus utile

En incluant HTML dans l'histoire (parce que certains semblent uniquement défendre CSS comme étant un LP, je comprends pas en quoi c'est plus inclusif de nier HTML mais passons):

• HTML = langage de balisage (markup language — C'est le ML de HTML, au cas où, hein) ou langage de présentation ou encore langage de formattage (qui sonne moins bien je trouve);
• CSS = langage de style — Oui c'est aussi simple que ça — Alternativement langage de présentation fonctionne aussi.

Parce que ouais, je comprend pas pourquoi il ne faut absolument pas mentionner immédiatement que la finalité de HTML et CSS c'est la présentation des données, l'affichage, l'apparence. C'est genre l'idée numéro 1 à communiquer quand on parle de ces langages, tout le monde s'en frotte le cubitus que ça soit Turing-complet ou qu'on puisse créer un jeu de OXO sans JavaScript, ça n'a rien à faire dans une explication initiale de ce que sont ces langages.

Pour expliquer CSS à quelqu'un on peut évoquer les "classes" de formattage dans Word, qui sont en fait dans "styles" et sont enregistrés comme tels dans le document. Ce qui nous permet de bien expliquer que ces langages permettent de facilement grouper et combiner des jeux de propriétés relatives à l'apparence d'un document, et qu'on peut garder le même document mais changer entièrement son apparence just en modifiant les styles associées.

C'est beaucoup plus intuitif (à mon avis hein) que d'expliquer ce qu'est un langage déclaratif ou impératif (utile aussi mais pas face à un débutant ou quelqu'un qui n'est pas dans l'informatique...) et ne laisse pas trainer la possibilité que la personne se dise "ah oui Candy Crush est programmé en HTML et CSS du coup!".

Attention, je pense que la section suivante est importante. C'est pas parce que HTML/CSS ne sont pas des LP au sens pratique du terme qu'on ne peut pas réaliser des trucs de FOU avec ces technologies et avoir du fun en le faisant.

HTML/CSS sont des technologies incroyablement complexes et essentielles

Je sais pas trop pourquoi HTML et CSS ont un genre de mauvaise réputation de "trucs de puni" ou "uniquement le job des designers ou UI/UX" qui soit dit en passant semble être à peine mieux vu que le support technique (genre pour les connexions internet) qu'on exporte quelque part dans un autre pays selon certains gens.

Et ça me fait un peu iech parce qu'en tant qu'utilisateur, je suis pas fan des interfaces pourries et je pense qu'il est très indiqué de respecter le travail des experts qui dessinent de bonnes, jeunes et jolies interfaces.

C'est vrai qu'il fut un temps où le marché du "développeur web" (= quelqu'un qui fait des sites internet en PHP, "design" compris) était relativement saturé. Entre temps les standards ont évolué, on s'attend à un niveau élevé d'accessibilité et de flexibilité de l'affichage.

Par exemple, toute interface web moderne doit absolument fonctionner sur mobile malgré les contraintes de taille (particulièrement avec le clavier déployé sur l'écran) et l'absence de certains gestes souris. Déjà juste ça c'est tout un rayon de compétence en soi.

Les compétences en informatique sont extrêmement variées. Certains indépendants qui réalisent des sites internet vont sous-traiter tout le UI/UX et CSS mais tout adapter eux-même ensuite et ajouter le JavaScript ou autre partie fonctionnelle qui soit nécessaire.

D'autres vont combiner HTML, CSS et JavaScript et un éventuel langage backend, tout en un (je crois qu'on les appelle FULL STACK). Certains UI/UX sont payés moins que certains développeurs, d'autres davantage. Il y a des consultants en UI/UX. Il y a aussi des UX/UI qui, en fait, ne connaissent que très peu HTML et CSS. Si je vous jure qu'ils existent.

C'est à coup sûr une sorte de champ d'expertise mais l'existance de ces experts ne dispense pas d'autres développeurs d'au moins connaître les bases d'HTML/CSS. Ces technologies sont trop importantes pour être juste niées par d'autres types de développeurs spécialisés.

Pour en revenir à l'essence de ce que c'est un blog et parler de MOI, j'ai découvert les CSS bien ultérieurement à mon introduction au HTML de l'époque. Je le qualifie comme ça parce qu'on mettait tous les tags en majuscules et on utilisait des table et des frameset pour la mise en page.

J'explique plus ou moins l'aventure sur un post dédié à mon passé de designer (lol).

Plutôt que d'utiliser les CSS on faisait des trucs de ce genre (oui du coup c'était avant la fête du div):

<BODY bgcolor="#333" text="#fff">

<FONT color="red" face="arial" size="16">Trop Beaaau</FONT>

<P>Lorem Ipsum Truc.</P>

</BODY>

Le tag "font" est tellement banni qu'il n'est même pas référencé chez w3schools, ils donnent tout de suite des exemples en utilisant du CSS en ligne.

Quand j'ai entendu parler de ces Cascading Style Sheet pour la première fois, c'était sur un site avec tout un tas d'exemples que je trouvais trop mega classe mais qui seraient sûrement bien CRINGE de nos jours.

J'essaye de vous reproduire le coup du titre répété plusieurs fois avec des marges négatives pour faire un super effet 3D trop bien:

J'étais fan des noms de couleur (le classique DEEPPINK) et la propriété letter-spacing que j'utilisais partout. C'était le bon vieux temps et déjà à ce moment-là c'était cool le CSS (enfin, je trouve, c'est possible que je sois légèrement atypique).

De nos jours il y a les transitions, les animations, encore plus d'effets sur texte, de perspective, des tonnes d'options pour la mise en page, ...

Pourtant, les CSS sont générallement assez mal vus. Plutôt du côté corvée ou bidule incompréhensif et chaotique que "youpie on va bien s'amuser".

Je peux en partie comprendre pourquoi:

• La cascade — système de priorité des styles appliqués — est assez complexe et peu de gens (j'en ai été longtemps coupable) prennent le temps de l'étuder et qui en plus peut être brisée par la mention maléfique !important dont vous connaissez peut-être la réputation;
  • En fait, les propriétés CSS avec !important prennent le dessus en terme de priorité et ignorent la cascade;
  • Sauf que c'est possible d'avoir plusieurs !important en conflit, et là, la cascade revient. Si ça vous arrive, vous êtes en ce moment en visite dans un des 7 enfers des CSS, bonne chance!
• Il est courant d'avoir énormément de choses dans un seul fichier .css et il n'y pas de système de classement ou filtrage automatique ou moyen de grouper des sélecteurs ensembles — Ceci rend l'évoluation de la cascade complexe par moment (heureusement les inspecteurs des navigateurs sont balaises de nos jours);
• Il y a tellement de propriétés et d'interactions étranges entre elles qu'il faut une tonne d'essai-erreur pour obtenir exactement ce qu'on souhaite, sans compter que la cascade complique ça aussi avec les propriétés héritées ou sélecteurs obscurs dont vous ignoriez l'existence;
• Les commentaires sur une seule ligne à base de // ne sont pas autorisés et j'ai toujours pas compris pourquoi;
• Il est courant d'enchaîner plusieurs fois la même propriété CSS mais en étoffant la technologie sur chaque propriété successive. Le navigateur appliquera la dernière qui soit compatible avec son implémentation; Ceci permet de rester compatible avec de plus anciens navigateurs tout en offrant les trucs les plus modernes quand supportés, mais ça complique les CSS surtout pour les gens qui ne connaissent pas (du moins en gros) ce qui est compatible avec quoi et comment les combiner;
• Il existe une grande quantité de propriétés CSS spécifiques aux navigateurs qui commencent par un tiret et un nom de code de navigateur. Leur connaissance est également nécessaire pour obtenir une compatibilité maximale mais ça rend tout encore moins clair et demande de répéter la même priorité plusieurs fois;
• On peut mettre les styles dans des fichiers CSS, les coller dans un tag <style>, les ajouter en JavaScript (avec ou sans framework) — Dans un projet à plusieurs collaborateurs on peut vite se retrouver avec des CSS PARTOUT;
• Je l'ai déjà évoqué mais vous êtes toujours censé développer avec l'apparence sur mobile en tête alors que pas mal de développeurs non-UI créent tout pour leur écran de MacBook et oublient tout le reste;
• De nos jours on a les CSS variables mais il n'y a pas si longtemps il fallait répéter les mêmes valeurs sur une énorme quantité de proprétés, et changer la couleur d'un thème voulait dire ENORME CHERCHER & REMPLACER avec des tas d'effets secondaires possibles.

Il existe évidemment des solutions et manières de travailler pour éviter la plupart de ces obstables, ce qui s'ajoute aux compétences dont un expert CSS doit disposer.

Par exemple, des conventions de nommage (comme BEM, qui est un peu passé de mode d'ailleurs), des préprocesseurs comme PostCSS ou SASS qui s'ajoutent souvent sur un écosystème NodeJS qui est encore une autre grosse boîte de cuisses de canard entourées de gras.

J'en conclus personnellement que le problème n'est pas dû aux lacunes de CSS, qu'il est possible de combler par des outils et de la connaissance. Le problème, c'est que les gens n'ont pas cette connaissance. Ni les outils. Et ça les barbe pour une raison ou une autre.

Par ailleurs, beaucoup (genre, tous) de langages de programmation ont leurs propres boulets et je pourrais produire des listes à puce de trucs merdiques pour eux aussi. En particulier JavaScript est une autre technologie qui hérite de moultes années d'évolution des navigateurs, ce qui est impossible sans accrocher quelques casserolles.

Après je comprends tout à fait que certaines détestent toucher à l'apparence parce que c'est pas leur boulot et qu'ils sont de très mauvais designer.

Je répond moi-même parfaitement à tous ces qualificatifs sauf que j'aime beaucoup chipoter à essayer de "design" (faut le dire vite) des interfaces. Entre autres choses.

Je veux dire, vous trouvez pas que mon blog est magnifique? Hein? Oui? Moi aussi.

Bon c'est sûr que ça reste en dehors de mon travail donc j'ai peut-être une dimension ludique que certains n'ont pas le luxe de se permettre.

Toujours est-il qu'avec ou sans moi, HTML et CSS sont des compétences complexes avec un véritable écosystème d'outils (je n'ai même pas parlé des outils d'UX) et requièrent de l'expérience pour être efficace et ce, qu'il s'agisse de programmation ou pas dans votre propre fantastique monde définitoire.

Tout ça ne s'est pas amélioré au fil des années parce que HTML et CSS continuent d'évoluer et il y a toujours de nouvelles choses à apprendre, comme dans d'autres domaines de l'informatique comme la programmation. Ben ça alors!

Je vais m'autoriser à me répéter une seule fois dans cet article: une technologie ne doit pas obligatoirement être un "langage de programmation" pour être complexe à apprendre ou maitriser et présenter une valeur aussi élevée que d'autres technologies dans une équipe ou sur le marché du travail.

Et si ça vous embête cette histoire, copiez collez un peu de JavaScript voire utilisez quelques PLUGINS JQUERY dans votre soupe HTML/CSS et dites que vous faites de la programmation. Je suis 100% avec vous.

Perso, mes connaissances en CSS de mes débuts de "web-dev" étaient nazes de chez nazes et je suis content de comprendre un peu mieux la cascade et la multitude de sélecteurs possibles, avec le confort de propriétés de mise-en-page comme CSS grid.

Devoir ajouter une interface utilisateur sur un programme c'est courant, même si c'est juste un prototype qui devra être retravaillé par des designers plus tard.

Même dans le domaine des "applications du bureau" le HTML/CSS est très bien représenté (par ex. Spotify, Discord, Teams, Skype, Slack, l'Epic Game Store, ...) et on le retrouve aussi dans les applis mobiles.

Pourquoi le sujet déchaîne tant les passions?

Ben en fait, j'ai déjà donné la majorité des clés de cette discussion dans la sous-section "Moralité et inclusivité" plus haut.

Les défenseurs de la cause ont deux objectifs:

1. Défendre les opprimés qui ont été intimidés sur Internet par des méchants qui les ont corrigés quand ils parlaient de programmation en disant "gnnéééé le CSS spa dla programmation";
2. Rendre les boulots dans l'informatique les plus inclusifs possible;
3. Contrer un des arguments que les gens utilisent pour dire que HTML ou CSS, c'est nul.

Pour le point 1, c'est pas très clair si ces gens existent vraiment, mais je peux comprendre l'envie de remballer les farceurs qui répondent sèchement "HTML/CSS SPA DES LANGAGES DE PROGRAMMATION" parfois avec deux ou trois insultes, puisque, comme on l'a bien étudié en détail dans cet article, on pourrait techniquement considérer HTML/CSS comme des LP même si, en pratique, je trouve ça un peu étrange et je viens d'expliquer pourquoi pendant 1000 ans dans les sections précédentes.

On en arrive à croiser la mission d'essayer de rendre les réseaux sociaux plus accueuillants et sympas, ce qui est une très noble cause mais ça n'a rien à voir avec HTML/CSS.

Pour le point 2, c'est clair qu'il y a encore du travail pour obtenir davantage de diversité et d'inclusivité dans le monde de l'informatique en général. Je suis d'accord. Par contre, est-ce que dire que HTML/CSS sont des LP aide à cette cause? Euh? Peut-être?

C'est totalement obscur pour moi mais peut-être que c'est parce que je suis pas dans le cas. C'est très difficile d'imaginer quelqu'un qui est tout content en général mais juste triste que HTML/CSS ne soient pas considérés comme étant des LP. Genre ça le réveille la nuit et tout.

Pour le point 3, si les gens trouvent que HTML ou CSS c'est nul genre ça sert à rien et ça pue, ils sont juste teubés et/ou très jeunes et écrivent probablement du code bien pourri.

Souvent, la raison pour laquelle ils trouvent ça "nuls" est qu'ils ne maîtrisent pas ces technologies.

Si vous voulez vraiment rétorquer, trouvez leur LP favori et balancez quelques points qui expliquent en quoi ce LP est nul (je vous jure qu'il y a moyen de trouver du matos pour n'importe quel LP) et qu'il est temps de grandir et considérer les outils qu'on doit tous utiliser avec respect.

Ne rétorquez pas avec "tu savais que HTML/CSS sont des LP?" parce que c'est comme dire "tu dis que t'as coupé des légumes mais la tomate c'est un fruit et pas un légume hein, tu savais pas ou quoi?". Tout le monde s'en barre que la tomate c'est un fruit, attaquez le fond de l'argument pas le chipotage ultime de la forme de Turing-complétude de sa maman.

Pour faire un pas vers les vaillants défenseurs d'HTML et CSS, je dois bien avouer que l'aura "HTML et CSS c'est un peu relou" existe réellement et peux envisager que ça puisse couper l'envie d'apprendre ces technologies plus en profondeur pour certains développeurs.

Le truc c'est que même si tout le monde décidait subitement d'appeler HTML et CSS des LP, ça m'étonnerais énormément que le problème soit tout à coup résolu "ah ouais HTML et CSS c'est génial! J'en fais même aux toilettes maintenant!".

Il y a un soucis humain là derrière, doublé de l'anonymat des réseaux sociaux et de l'over-confiance de certains débutants en leurs opinions.

C'est sûr que corriger les gens sur "HTML/CSS SPA DLA PROGRAMMATION" c'est un peu nul.

D'un autre côté, passer des heures à disserter pour défendre que HTML/CSS sont totalement 100% des langages de programmation, officiel et tout, approuvé par la papauté, c'est aussi un peu bizarre.

Au final, ça devrait être:

- "Ecoute gamin, tu auras besoin d'HTML et CSS un jour ou l'autre. Arrête de dire que ça craint si tu veux bosser sur ta carrière et arrête de chier dans la soupe et chipoter sur les définitions".

- "Et toi, l'autre gamin, on s'en balance que ce que tu apprends soit un langage de programmation pour métier à tisser de slip ou un langage qui gère un domaine très précis, on s'en fout aussi que tu code sous Windows ou Linux ou Mac, l'important c'est d'avoir du résultat et évoluer personnellement et dans ta carrière — Tu y arrives sans être une bouse humaine avec tes pairs et sans avoir l'impression que ta vie n'a plus aucun sens? ALORS TOUT LE RESTE ON S'EN FOUT".

Raviver la confiance en ces technologies

J'ai tout un autre article sur le sujet du syndrôme de l'imposteur où j'avais déjà écrit une partie sur cette histoire d'HTML/CSS.

Dans des articles comme celui-ci, on peut trouver ce type de citations (j'ai traduit):

Si on met de côté la politique au sein du développement logiciel, pourquoi est-ce que CSS (et HTML tant qu'on y est) ne seraient pas considérés comme des langages de programmation?

Alors, je viens d'expliquer pourquoi sur un nombre particulièrement douloureux et pas nécessaire de lignes de texte. Ce que je me demande, c'est d'où sort la "politique".

C'est politique maintenant de dire que HTML/CSS est ou n'est pas un LP? Je suis vraiment pas sûr que les gens qui supportent la négative soient particulièrement engagés sur le sujet. Par contre ceux qui supportent l'affirmative sont souvent visiblement émotionnellement engagés.

Ça me rappelle un peu ces sujets qui braquent immédiatement un des bords politiques mais pas l'autre.

Par exemple le "racisme systémique" qui est l'idée qu'un système peut agir de manière raciste sans qu'aucun acteur du dit système ne soit nécessairement raciste, ce sont des vieux trucs qui traînent, de richesse générationnelle, facteurs environnementaux, parfois des restes d'anciennes lois, qui provoquent des effets qui s'avèrent cibler en particulier certaines races.

Vous dites ça à quelqu'un de droite, dans sa tête il a entendu le mot "racisme", vous êtes en train de le traiter de raciste. Lui et toute sa famille. Et tous ses ancêtres. Et de toutes façons tout le monde est raciste. Il est émotionnellement braqué.

Pour l'histoire d'HTML/CSS le côté de l'engagement émotionnel change et une affirmation assez innocente braque totalement des gens qui, en général, sont tous progressites.

Parfois c'est bien de se demander est-ce que ce serait pas moi qui rend [INSERER UN TRUC] politique?

C'est pareil pour l'idée de devoir "défendre" HTML et CSS. Ils n'ont pas besoin de défense, ce sont des outils très utilisés et très puissants et somme toute difficiles à maîtriser.

J'en viens parfois à me demander si ces gens n'ont pas l'opinion secrète que "ouais en fait ils ont raison c'est un peu nul HTML et CSS :(". Un peu d'introspection c'est pas mal parfois pour se rassurer.

Posez vous la question: est-ce que c'est vraiment justifié que j'aie si peu confiance en mes compétences technique si elles sont majoritairement HTML/CSS?

On pourrait (presque) tous bénéficier d'un petit boost de confiance en nous et en plus on le mérite. Si, je vous jure.

Je vous re-invite à lire mon article sur le syndrôme de l'imposteur qui parle de confiance en détail, au cas où vous avez vraiment besoin de lire plus de texte de ce blog ce qui est honnêtement un peu bizarre. HEEEY on avait dit d'avoir plus de confiance! C'est difficile hein?

Conclusion

HTML et CSS, et XML et LaTeX sont des langages de programmation si vous le voulez. Sinon, pas.

Est-ce que c'est vraiment important? Posez-vous la question. Demandez-vous pourquoi. Laissez ensuite filer vos angoisses au gré du vent.

Pourquoi j'ai passé tant d'heures à débattre sur un sujet qui, à mon avis, a un niveau d'importance-dans-le-monde largement inférieur à la présence ou non d'une petite rondelle de citron dans un Perrier?

He bien, c'est simple, je vais vous expliquer