Ne le faites pas vous-même…

• Le principe Don't Roll Your Own ... s’applique non seulement à la cryptographie, mais aussi aux interfaces web, et il faut éviter de remplacer inutilement des fonctions que le navigateur fournit déjà de manière fiable
• Remplacer des comportements de base comme le défilement, la gestion des liens, la sélection de texte ou le copier-coller casse les réactions familières aux entrées et oblige l’utilisateur à refaire attention à la manière d’interagir
• Comme pour les liens de fichiers ou d’issues sur GitHub, lorsque JavaScript intercepte la navigation des liens, il peut parfois être plus rapide d’ouvrir dans un nouvel onglet que d’attendre le traitement dans l’onglet courant
• Le champ de mot de passe natif et <input type="date"> coopèrent avec l’autocomplétion, les gestionnaires de mots de passe, les outils d’accessibilité et les claviers mobiles, si bien qu’un faux UI peut casser ces fonctions
• Des mises en page et contrôles de formulaire qui changent tous les quelques mois font perdre du temps aux utilisateurs en réapprentissage plutôt qu’en travail, et il est préférable de conserver les comportements natifs stables du navigateur

---

Application du principe « Ne le faites pas vous-même » aux interfaces web

• L’interdiction de réimplémenter soi-même la cryptographie est le principe selon lequel, dans un logiciel de production qui protège des données sensibles, il ne faut pas dépendre d’implémentations maison non validées
• Cela ne veut pas dire que personne ne doit jamais écrire de code cryptographique, mais plutôt qu’il faut utiliser autant que possible des packages et outils revus et validés
• Il y a environ 20 ans, on trouvait réellement des implémentations maison de RC4 avec des problèmes comme des vecteurs d’initialisation inadaptés, des flux de clés prévisibles ou la fuite d’une partie du texte en clair
• Aujourd’hui, les grands sites d’e-commerce et les banques n’utilisent généralement pas leur propre cryptographie pour les services web, et dans les domaines réglementés comme le paiement, la santé ou le traitement de données personnelles, le non-respect d’exigences de chiffrement strictes peut entraîner de lourdes amendes
• La conception d’un site web n’est pas la même chose que la cryptographie, mais réimplémenter des fonctions que le navigateur gère déjà bien et sur lesquelles les utilisateurs comptent chaque jour peut dégrader l’expérience utilisateur

Problèmes créés quand on remplace les fonctions natives du navigateur

• Si l’on réimplémente soi-même le défilement de page, les réactions familières à la souris, au touchpad et au clavier peuvent être perturbées
• Remplacer le comportement natif du défilement peut faire bouger la page trop lentement ou trop vite, et le défilement au clavier peut même cesser de fonctionner
• Quand un comportement utilisé sans y penser devient un comportement inhabituel, l’utilisateur doit à nouveau prêter attention à la manipulation de la page elle-même
• Parmi les fonctions typiques qu’il vaut mieux ne pas réimplémenter figurent la navigation des liens, la sélection de texte, le menu contextuel, le copier-coller, les champs de mot de passe et le sélecteur de date
• Lorsqu’on ajoute des fonctions d’interface à un site web destiné à un usage sérieux, il faut décider prudemment s’il faut ajouter des fonctions sophistiquées ou s’en remettre au comportement natif du navigateur

Navigation des liens et cas de GitHub

• Le navigateur web sait déjà très bien suivre les liens, et la navigation par lien est une fonction centrale du navigateur
• Si l’on pense devoir perturber le comportement normal des liens, il faut reconsidérer si l’objectif recherché est vraiment assez important pour casser la navigation des liens classique
• Sur GitHub, lorsqu’on clique sur un lien de fichier ou d’issue, une grosse fonctionnalité implémentée en JavaScript prend en charge le clic à la place
• Dans Firefox ou Chrome, on peut le constater en ouvrant les outils de développement avec F12, puis en sélectionnant click dans Mouse, dans Event Listener Breakpoints de l’onglet Debugger ou Sources, avant de cliquer sur un lien GitHub
• Sur GitHub, il arrive qu’ouvrir un lien dans un nouvel onglet soit plus rapide que d’attendre le traitement de navigation JavaScript dans l’onglet courant

Saisie de mot de passe et sélecteur de date

• Le champ de saisie de mot de passe du navigateur peut offrir l’enregistrement du mot de passe, le remplissage automatique et la génération de mots de passe robustes pour les nouveaux comptes
• Le champ de mot de passe natif avertit lorsqu’un mot de passe est envoyé sur une connexion HTTP non sécurisée, et coopère aussi avec les gestionnaires de mots de passe, l’autocomplétion, les claviers mobiles et les outils d’accessibilité
• Le remplacer par un faux champ de mot de passe peut casser ces fonctions, et si l’on masque soi-même un champ texte ordinaire, le navigateur, le système d’exploitation et les outils d’assistance peuvent traiter le mot de passe comme du texte visible normal
• <input type="date"> ne prend pas directement en charge la sélection d’une plage de dates, mais on peut conserver le sélecteur de date natif du navigateur en fournissant deux champs, un pour la date de début et un pour la date de fin
• Les sélecteurs de date personnalisés fonctionnent différemment selon les implémentations : il faut parfois passer à une vue par année, cliquer des dizaines de fois sur le bouton de l’année précédente pour choisir une date de naissance, ou bien la saisie directe de la date peut être bloquée
• Si un widget calendrier est nécessaire pour des navigateurs où le sélecteur de date natif est insuffisant, mieux vaut l’ajouter comme widget auxiliaire manipulant le même champ plutôt que de remplacer <input type="date">

Le coût des changements fréquents d’interface

• Modifier à la légère les contrôles de formulaire résout parfois des problèmes existants, mais introduit presque toujours de nouveaux problèmes en même temps
• Si la mise en page et l’interface d’un site changent tous les quelques mois, certains utilisateurs s’y adapteront, mais les utilisateurs plus âgés subiront chaque fois une charge comparable à l’apprentissage d’un nouvel outil
• Quand plusieurs sites web changent sans cesse d’interface, les utilisateurs doivent consacrer beaucoup de temps à réapprendre ce qui leur était familier, sans gain fonctionnel réel
• Comme si une distribution Linux repensait tous les quelques mois ses commandes essentielles et leurs options en ligne de commande, ou comme si la disposition des boutons d’une machine à laver changeait tous les matins, ces réorganisations répétées de l’interface produisent une expérience désagréable
• L’interface web est un outil que l’utilisateur emploie pour terminer son travail, il est donc préférable de ne pas remplacer inutilement des comportements familiers et stables que le navigateur fournit déjà

[kirinonakar]

Je pense qu’il n’y a probablement pas beaucoup de pays comme le nôtre avec autant de systèmes de chiffrement et de programmes de sécurité développés en interne.

[GN⁺]

Avis sur Lobste.rs

• Je suis d’accord avec l’idée de ne pas réimplémenter le défilement de page. On ne fera jamais aussi bien que le natif, sauf peut-être dans des cas comme les cartes où il existe une convention qui mappe le défilement au zoom.

  En revanche, je suis fortement opposé à l’idée d’en faire une règle pour la navigation par liens. Pour un site de contenu classique, je ne recommanderais pas le routage côté client (CSR), mais pour certaines apps je pourrais au contraire le recommander activement, et un service comme GitHub se situe quelque part entre les deux.

  Cela dit, il faut toujours utiliser un vrai élément `` pour que les fonctionnalités natives du navigateur continuent de fonctionner. Pour une app comme un client de webmail, le CSR a du sens, et GitHub s’était amélioré quand il l’appliquait autrefois de façon légère, mais son approche frontend récente s’est nettement dégradée.

  Le problème, c’est que le CSR est trop souvent implémenté à la va-vite et sans vraie robustesse face aux mauvaises conditions réseau. Le navigateur, lui, est solide dans ce genre de situation, et des optimisations comme l’indicateur de chargement d’onglet ou le bfcache peuvent aussi être gênées par le CSR.

  La réimplémentation de la sélection de texte ne se justifie que dans des cas très spécifiques, comme une app d’annotation mobile où l’on utilise son doigt comme un surligneur. J’ajouterais même qu’il vaudrait mieux ne pas utiliser ::selection non plus. C’est une mauvaise conception qu’un simple ajout de ::selection{} dans une feuille de style puisse rendre la sélection invisible.

  Je ne suis pas d’accord non plus avec l’interdiction de réimplémenter le menu contextuel. Dans des apps comme un client mail, un gestionnaire de fichiers ou un traitement de texte, on a besoin d’éléments propres à l’application, et comme le navigateur n’offre pas de mécanisme d’extension, un menu entièrement personnalisé est aujourd’hui un choix pragmatique. Heureusement, dans Firefox, Shift+clic droit permet de forcer l’ouverture du menu natif.

  Pour l’interdiction de réimplémenter le copier-coller, je peux être d’accord ou non selon l’interprétation, donc il faudrait être plus précis.

  Je n’ai pratiquement jamais vu de réimplémentation d’un champ mot de passe en dehors de démos techniques. Le simple fait d’avoir un bouton afficher/masquer qui change `` de password à text ne me semble pas entrer dans cette catégorie.

  Je ne suis pas non plus d’accord avec l’idée de ne jamais réimplémenter un sélecteur de date. Je recommanderais volontiers le contrôle natif, mais ses limites et ses incohérences sont importantes, et il y a eu très peu d’intérêt pour les corriger au cours des dix dernières années. On ne peut pas enrichir le sélecteur avec des informations supplémentaires, et choisir une date ancienne, comme une date de naissance, est atroce sur certaines plateformes. Exemple : Safari's date-picker is the cause of 1/3 of our customer support issues

  Les sélecteurs de date personnalisés posent beaucoup de problèmes d’accessibilité, mais ils sont aussi souvent meilleurs pour l’utilisateur moyen, et dans bien des cas on ne peut pas utiliser le contrôle natif parce qu’il manque des fonctionnalités essentielles. Pour le simple choix d’une date, je préfère le natif dans les navigateurs que j’utilise parce qu’on peut saisir directement la date, mais pour beaucoup d’utilisateurs le natif n’est pas assez bon. Pour une plage de dates, faire ça avec deux `` risque fort d’être bien pire pour la plupart des gens.

  • Quand on parle d’accessibilité, ou qu’on oppose les personnes qui en ont besoin aux “gens normaux”, on risque facilement d’exclure certains lecteurs. Comme tu sembles en réalité accorder pas mal d’attention à l’expérience et aux besoins des personnes qui utilisent des aides d’accessibilité, je voulais le souligner.

  • Après avoir essayé moi-même le sélecteur de date de Safari, je comprends à quel point il est limité. Mais je me suis toujours demandé pourquoi les sites web remplacent le sélecteur de date natif par un widget calendrier.

    Est-ce qu’on ne pourrait pas mettre ce widget calendrier à côté du widget natif ? L’interface pourrait sembler ambiguë avec deux modes de saisie, mais j’ai l’impression qu’avec des libellés adaptés, par exemple en présentant l’un comme un sélecteur de date avancé, on pourrait résoudre le problème. Ainsi, on ne pénaliserait pas les gens qui préfèrent le sélecteur de date natif, tout en aidant ceux pour qui celui du navigateur est insuffisant.

    Je comprends qu’un menu contextuel soit utile dans des webapps comme un outil de rédaction ou de diagrammes, mais quand le clic droit fait disparaître le menu standard du navigateur, ça reste pénible. C’est pourquoi, dans Firefox, je laisse généralement dom.event.contextmenu.enabled = false. Le menu Firefox s’affiche alors au-dessus et celui de la webapp derrière, mais comme le menu natif fonctionne, c’est un contournement acceptable. Quand c’est possible, mieux vaut utiliser la barre de menus de la webapp et ne pas toucher au menu contextuel natif du navigateur. L’astuce Shift+clic droit est aussi une bonne solution.

  • Les personnes qui ont besoin de contrôles accessibles sont elles aussi des personnes normales.

  • On voit des champs mot de passe réimplémentés dans presque toutes les banques au Pérou.

    J’aimerais utiliser le sélecteur de date natif, mais du côté des implémenteurs, on ne voit pas beaucoup d’efforts d’amélioration. Firefox a des problèmes ouverts sur l’UI de sélection d’heure/horloge, et ça avance lentement : https://bugzilla.mozilla.org/show_bug.cgi?id=datetime

• Pour les formulaires web, c’est une bonne remarque. S’appuyer sur le navigateur est l’approche la plus simple, la plus rapide et presque toujours la plus cohérente.

  Mais du côté du code cryptographique, c’est différent. Écrire du code crypto correct n’est pas facile, mais ce n’est pas impossible non plus. Dans certaines situations, les options sont si limitées que faire soi-même peut être le meilleur choix.

  Le problème, ici, vient des puristes de la sécurité, qui ont tendance à partir du principe que pour écrire du nouveau code crypto, il faut appartenir à leur cercle. Si l’on ne peut pas exhiber un doctorat en cryptographie ou un stage auprès de DJB ou Dan Boneh, on n’aurait pas le droit d’écrire du code crypto. Pour “apprendre”, d’accord, mais dès qu’on veut appliquer ce qu’on a appris dans le réel, non. Ils semblent même parfois avoir du mal à reconnaître la compétence réelle de personnes extérieures à leur milieu. Fait intéressant, le recoupement entre ces puristes de la sécurité et les vrais cryptographes qui publient des articles semble très faible.

  Et maintenant, ça s’étend jusqu’à dire qu’il ne faudrait plus rien écrire dans un langage non memory-safe. Même si 70 % des vulnérabilités critiques y sont liées, quelle en était la vraie cause ? À mon avis, l’essentiel venait de l’usage de malloc() ou de new explicite pour chaque petit objet non placé sur la pile, ou de la manipulation de chaînes terminées par un octet nul. Avec des arenas et des slices, il y aurait eu bien moins de problèmes. Évidemment, dans certains scénarios à haut risque, il faut éliminer complètement certaines classes de bugs, et là, la memory safety devient prioritaire.

  Alors quoi, il ne faudrait plus rien écrire qui traite des entrées non fiables ? Il ne faudrait jamais réinventer la roue même si toutes les roues existantes sont carrées ? Cela dit, si on évite l’obésité JavaScript et qu’on utilise les formulaires fournis par le navigateur, je ne serais sans doute pas très critique même vis-à-vis d’un framework web maison.

  • Le péché originel du C, à mes yeux, c’est qu’en passant un tableau, on perd l’information de borne et il s’effondre en pointeur.

  • J’ai toujours compris “n’écris pas ta propre crypto” non comme un absolu, mais comme un avertissement très fort. Il est vrai qu’on peut implémenter ça de manière sûre sans doctorat, mais cela demande malgré tout un apprentissage énorme.

    Si l’on se contente d’implémenter minutieusement une spécification, c’est peut-être beaucoup moins nécessaire. Mais la plupart des logiciels veulent une implémentation crypto rapide, et là la complexité grimpe fortement. La vulnérabilité de Monocypher liée plus haut en est un bon exemple. D’un coup, il faut comprendre comment s’articulent l’équivalence birationnelle, les points d’Edwards et la Montgomery ladder.

    Des qualifications comme un doctorat aident aussi les autres à vous faire confiance sur le fait que vous savez ce que vous faites. Un audit est une autre voie. Monocypher semble avoir été audité par deux docteurs de chez Cure53. Le problème, c’est que la plupart des programmeurs ne sont pas en mesure d’évaluer si une bibliothèque crypto est sûre, donc ils s’appuient sur des signaux non techniques, comme les diplômes ou les qualifications des auditeurs. On aimerait avoir quelque chose de plus direct, mais les qualifications fonctionnent plutôt bien.

  • Bien sûr qu’il est possible d’écrire sa propre crypto. Si c’était impossible, il n’existerait pas de bibliothèques cryptographiques. La vraie question n’est pas de savoir si c’est faisable, mais si, en production, quand il s’agit de hasher les mots de passe des utilisateurs et de protéger des données privées, on peut faire confiance à une crypto que toi ou moi avons écrite à la main. Moi, non.

  • Dans un ancien poste, du vieux code utilisait MD5 pour vérifier des licences, et comme il fallait valider cela dans un environnement où il était impossible d’exécuter le vieux code C++, j’ai dû réimplémenter MD5. J’ai bien trouvé des bibliothèques existantes, mais aucune ne permettait de modifier l’IV.

  • Je n’aurais jamais le courage d’écrire moi-même de la crypto, mais l’industrie de la sécurité semble maintenant aller jusqu’à dire qu’il ne faudrait même plus faire sa propre authentification, et ça me paraît un peu excessif.

• J’aimerais que le navigateur fournisse un champ de sélection multiple utilisable sans qu’on ait besoin de l’implémenter soi-même.

  • Ça existe, mais c’est lamentable.

• La méthode consistant à utiliser deux `` pour recueillir une date de début et une date de fin est lourde et peu intuitive pour une plage de dates. On prend quelque chose qui est conceptuellement unifié et on le découpe visuellement en deux vues séparées qui semblent sans rapport.

  L’absence de plage de dates n’est qu’un des nombreux problèmes de ``. Par exemple, on ne peut pas exclure certaines dates, ce qui fait que, pour presque tous les services de réservation, ça ne convient pas dès le départ.

  Je doute que la position consistant à accepter le petit coût de deux champs de saisie afin d’avoir partout la même manière d’écrire les dates soit réellement majoritaire. L’utilisateur moyen n’aime pas les champs, et s’il y a pire qu’un champ, c’est bien deux champs. L’argument de l’habitude me paraît lui aussi peu convaincant. D’après mon expérience, les champs de date natifs restent rares sur le web.

  • J’ai vu plusieurs sites qui empilaient deux widgets calendrier personnalisés ne fonctionnant pas correctement, un pour la date de début et un pour la date de fin. Le pire des deux mondes.

  • Je n’étais pas non plus d’accord sur la partie concernant les plages de dates. J’utilise souvent les plages de dates comme exemple pour montrer qu’un contrôle conceptuellement simple peut en réalité devenir très complexe. Le slogan “utilisez toujours les contrôles natifs” peut en fait dégrader l’expérience utilisateur lorsqu’on pourrait fournir un meilleur contrôle, plus adapté au problème.

    Une fonction utile des contrôles date/plage de dates qu’on ne peut pas faire en natif, c’est l’affichage des prix. Quand on cherche un vol ou un hôtel, il est très utile de voir directement dans le sélecteur quelles dates sont moins chères ou plus chères. Avec un contrôle natif, il faudrait beaucoup plus de clics ou consulter un tableau séparé pour obtenir cette information, alors qu’un contrôle personnalisé peut associer ce type de métadonnées à chaque date.

    L’exemple classique, c’est la saisie de date de naissance. Le sélecteur de date affiche généralement par défaut le mois en cours, ce qui n’a presque jamais de rapport avec la date cherchée, donc c’est catastrophique. Ici, on peut utiliser un contrôle personnalisé, mais une combinaison de zones de texte est souvent meilleure. Ce n’est pas un contrôle totalement maison, plutôt une combinaison de contrôles natifs, mais l’idée essentielle est qu’il n’existe pas de sélecteur de date universel qui traite bien tous les cas.

• Ça remonte à quelques années, donc il faudrait que je revérifie, mais il y avait malheureusement de bonnes raisons de devoir réimplémenter un sélecteur de date à la place du html5 natif. L’UI de `` était vraiment atroce dans certains navigateurs.

  Réimplémenter le menu contextuel est rare, mais très utile quand il le faut. Par exemple, si l’on crée un éditeur de diagrammes dans une page web, j’aimerais vraiment qu’un menu contextuel personnalisé permette d’effectuer des actions utiles sur un nœud du diagramme. Ce n’est pas une bonne idée de forcer toute l’interaction à passer par une UI au clic gauche, par exemple en alternant entre une palette d’actions et les nœuds.

  Je suis fortement d’accord avec le reste de la liste.

• Je ne vois pas bien comment interpréter ensemble l’exemple sur la cryptographie et le problème du défilement. Cela me semble relever de domaines très différents.

  Je suis d’accord avec l’idée générale que les sites web en font trop. Mais le comportement approprié dépend aussi des objectifs de l’utilisateur et du site.

  Peut-être qu’un réglage comme prefers-user-scroll, à la manière de prefers-reduced-motion, pourrait constituer une solution intermédiaire ?

  • Il n’existe aucun cas d’usage légitime du scrolljacking pour implémenter une zone de défilement verticale. Ce code n’aurait jamais dû être écrit.

    Cela dit, je limite cette affirmation aux zones de défilement verticales. Quand on remappe le défilement vers un comportement qui n’est pas un défilement, il existe des cas d’usage ; ça reste très problématique, mais on peut au moins discuter du cas où, dans un système d’écriture vertical, on remappe le vertical vers l’horizontal. Il existe peut-être aussi un ou deux autres cas d’usage légitimes, mais dans la pratique, l’implémentation est en général encore mauvaise.

• Je suis tout à fait d’accord avec l’interdiction de réimplémenter le défilement de page. À KotlinConf, j’ai assisté à une présentation intéressante sur la difficulté d’implémenter le défilement dans Compose Multiplatform for Web.

  L’un des problèmes était que les navigateurs web émettent moins d’événements de défilement que les apps natives, ce qui faisait échouer l’algorithme de calcul de la direction du défilement. L’algorithme traçait une parabole passant par tous les points et utilisait la pente au dernier point, mais s’il y avait trop peu de points, il pouvait déduire la direction inverse du défilement.

  Quand on porte ce genre d’interactions depuis une autre plateforme ou qu’on les réimplémente, il est facile de partir de mauvaises hypothèses ou d’oublier des comportements “étranges” que le navigateur gère par défaut.

  • Je me demande à quoi servaient ces événements de défilement dans l’app d’origine, pour qu’il faille aussi les reproduire dans le contexte web. J’ai un petit doute sur l’idée d’utiliser le défilement comme signal de pilotage pour autre chose.

• Le conseil “appuie-toi sur la plateforme” est juste, mais suivre en permanence l’évolution de la plateforme est difficile. Il y a des choses comme enterkeyhint ou inputmode dont on sait vaguement qu’elles existent, tout en oubliant leur effet.

  Cette semaine, notre équipe a publié [0] pour aider sur ce point. Ça fournit les bonnes pratiques d’implémentation sous forme de skills. La documentation se lit aussi très bien pour des humains. Exemple : [1]

  [0] https://github.com/GoogleChrome/modern-web-guidance [1] https://github.com/GoogleChrome/modern-web-guidance/…

• Le ton de l’article sonne faux. Il serait bien plus productif d’expliquer aux gens dans quels cas et pourquoi il n’est pas nécessaire de réinventer la roue.

  Le texte explique bien les raisons, mais il devient moins bon à cause de la formulation péremptoire “ne le faites pas vous-même”.

  Le slogan “n’écrivez pas votre propre crypto” finit lui aussi par ressembler à un dogme. Qui sont ces experts qui sauraient le faire, et qui les a nommés ? Avant d’affirmer cela, ont-ils au moins regardé eux-mêmes le code ? Quand on voit des vulnérabilités comme Heartbleed, n’est-il pas clair qu’il s’agissait en réalité d’erreurs élémentaires ?

  • Ce sont des gens qui ont consacré leur vie à la cryptographie. Personne ne les a nommés ; ils ont acquis leur légitimité en publiant des travaux utiles et en étant validés par des personnes compétentes dans le domaine.

    Les algorithmes sont publics, examinés, attaqués publiquement, améliorés, puis standardisés. Ce n’est pas quelque chose qui se passe derrière des portes closes. Les articles sont publics et le code aussi. On peut les consulter quand on veut. Ce n’est pas parce que toi, tu ne les as pas regardés que personne ne l’a fait. Des gens les examinent et essaient de les casser. Si on les utilise, c’est parce qu’ils ont résisté aux attaques.

    Si, en voyant Heartbleed, ta conclusion est qu’il faut réimplémenter OpenSSL toi-même, je te garantis que ton OpenSSL contiendra cinquante Heartbleed pour chaque Heartbleed du vrai OpenSSL. La différence, c’est que le vrai OpenSSL est relu, testé, audité, attaqué et corrigé par des gens compétents. Le tien restera simplement faux, en privé.

  • Le point important n’est pas qu’il existerait quelque part un expert parfait capable d’appeler AES sans jamais se tromper. C’est qu’en utilisant un wrapper populaire qui fonctionne de manière sûre, si un bug apparaît, il peut être identifié et corrigé à un seul endroit.

    Même lorsqu’une nouvelle attaque par canal auxiliaire est découverte, on peut réagir à un seul endroit. Ce que tu écris toi-même ne bénéficiera pas de ce type d’amélioration, à moins de consacrer ton temps plein à suivre en continu l’apparition de nouvelles attaques.

• Cela ressemble surtout à une plainte contre des gens qui utilisent mal les outils du web. Cela aurait été plus intéressant si ça traitait aussi des cas d’usage légitimes où une réimplémentation se justifie. Le lecteur pourrait alors apprendre quelque chose d’utile, au lieu de rester avec un modèle infantile du type “ne jamais le faire soi-même”.

  La maîtrise, c’est avoir les connaissances et les compétences pour construire soi-même, tout en ayant la sagesse de savoir quand il ne faut pas le faire.

  Cela dit, je compatis à cette frustration. J’ai moi aussi eu beaucoup de frustrations similaires. Le problème, c’est qu’il n’y a pas eu beaucoup d’efforts pour documenter les interactions web de manière assez rigoureuse et complète pour que les développeurs web puissent s’y référer facilement. Il existe un vrai problème grave de connaissances périphériques à la programmation qui ne sont pas correctement documentées ni transmises à la génération suivante, ce qui nous condamne à redécouvrir les mêmes problèmes encore et encore. En général, dans l’industrie, des ensembles de comportements et d’interactions finissent par s’imposer comme standards, mais personne ne les écrit.