Miser sur HTML

• Avec la diffusion de l’IA fondée sur les grands modèles de langage, la valeur du HTML sémantique lisible par les machines augmente autant que celle des écrans vus par les humains
• Les jardins clos des grands réseaux sociaux empêchent la portabilité des données et l’interopérabilité, tandis que les tentatives décentralisées comme le fediverse, Threads ou Bluesky offrent peu de motivation pour attirer les utilisateurs ordinaires
• Le HTML moderne dispose déjà d’une bonne partie des éléments d’interface de base nécessaires aux applications web, comme <details>, <dialog> et divers <input>
• En exploitant les styles par défaut du navigateur et le mode lecture, on peut réduire la dépendance à un excès de CSS et de JavaScript ; les bonnes balises améliorent la lisibilité machine et l’expérience de saisie sur mobile
• Dans un contexte où RSS reste bien vivant et où les interfaces de type ChatGPT émergent comme mode d’accès aux données, le HTML structuré peut devenir une base plus pratique que les interfaces centrées sur la publicité

---

HTML comme interface de données fondamentale du web

• L’émergence de l’IA fondée sur les grands modèles de langage remet en avant l’importance du HTML sémantique
• Le cœur d’Internet est de transmettre les données nécessaires aux humains pour interagir avec le monde, mais la liberté offerte par HTML/CSS/JavaScript a aussi pour revers de limiter l’accès aux données
• Les réseaux sociaux des grandes entreprises technologiques enferment les utilisateurs dans des plateformes fermées plutôt que de proposer des formats de données et des API ouverts et accessibles
  • L’interopérabilité entre plateformes est devenue difficile en pratique
  • Le problème se complique encore parce que les entreprises rechignent à faciliter la portabilité des données
• L’instabilité récente des réseaux sociaux ravive l’intérêt pour les plateformes décentralisées comme le fediverse
  • Threads de Meta et Bluesky, créé par Jack Dorsey, mettent en avant leur interopérabilité avec le fediverse au sens large
  • Mais les utilisateurs ordinaires ne choisissent souvent pas un nouveau réseau social pour cette seule raison
• Il faut réexaminer HTML comme une solution déjà éprouvée
  • Par le passé, il fallait beaucoup de CSS pour éviter que le contenu HTML ne soit laid dans le navigateur
  • Aujourd’hui, de nombreux éléments HTML modernes ont été ajoutés et fournissent la plupart des composants d’interface nécessaires aux applications web contemporaines
  • Le mode lecture peut rendre inutiles les efforts consacrés au style, et cela peut être vu positivement
• Les bonnes balises fournissent un format facile à lire par les machines
  • C’est une raison plus forte d’adopter le HTML moderne que le simple gain de temps sur le design
  • RSS est toujours vivant
  • Les interfaces comme ChatGPT pourraient devenir une future manière pour les humains d’accéder aux données

Éléments HTML utiles ou à redécouvrir

• La liste complète des éléments HTML sur MDN vaut le détour
  • Les exemples ci-dessous n’utilisent que les styles par défaut du navigateur, sans style supplémentaire
  • Selon le navigateur, leur rendu peut être très différent, voire ne pas être pris en charge du tout
• <abbr> : élément qui encadre une abréviation
  • On peut lui appliquer un style pour la mettre en évidence
  • Il est surtout utile pour la lecture par les machines
• <datalist> : élément fournissant une liste de suggestions de saisie
  • Il permet de créer une interface qui ressemble à de l’autocomplétion
  • Il ne semble pas y avoir de validation intégrée
  • Dans Safari, il faut fermer la balise option ; sinon, cela ne fonctionne pas
• <details> : élément de divulgation dépliable/repliable
  • Il peut servir de petit menu déroulant
  • On peut aussi lui appliquer un style de manière poussée
• <dialog> : élément de boîte de dialogue
  • C’est un élément intégré que l’on peut ouvrir et fermer avec des boutons, des formulaires, des attributs et JavaScript
  • Ce n’est pas exactement la même chose qu’une modale, mais c’est une bonne base si l’on veut en créer une
  • Il semble être rendu au-dessus de l’élément suivant
• <i> et <em>
  • Il faut connaître la différence entre les deux éléments
• <iframe>
  • Inclus dans la liste d’exemples, mais traité sur le ton de la plaisanterie
• <input> : élément de saisie de formulaire
  • Les champs de saisie doivent utiliser des libellés et des types appropriés
  • Sur mobile, le système d’exploitation ouvre des claviers différents selon le contexte, d’où l’importance de préciser le type de saisie
  • Les nombreuses saisies liées au temps peuvent réduire le besoin d’un date picker JavaScript séparé
  • Les exemples cités sont les champs color, range et datetime-local
• <mark> : élément de surlignage de texte
  • Par défaut, Safari l’affiche avec un surlignage jaune
• <meter> : élément d’affichage d’une mesure
  • Dans Safari, il s’affiche en rouge, jaune ou vert selon les paramètres définis
  • On peut définir une valeur optimum
  • Il peut être utile pour une démo de visualisation musicale à 60 fps
• <progress> : élément d’affichage de progression
  • C’est une barre de progression HTML native, pouvant recevoir une valeur fixe ou un état indéterminé
  • Dans Safari, elle apparaît en bleu lorsque la fenêtre est active et en gris lorsqu’elle est inactive
  • Par défaut, elle suit la couleur d’accentuation du système et peut être configurée avec la propriété CSS accent-color

[GN⁺]

Avis sur Hacker News

• Il est étrange de dire que HTML serait la solution à la dépendance aux écosystèmes fermés. Ces services fermés utilisent déjà HTML, ainsi que certains des éléments sémantiques mentionnés et des attributs sémantiques ARIA plus sophistiqués.
  Quant à l’idée que des interfaces comme ChatGPT représentent l’avenir de l’accès humain aux données, le point essentiel des systèmes d’intelligence artificielle est justement qu’ils n’ont pas besoin d’annotations spéciales « lisibles par la machine » pour traiter les entrées. ChatGPT et ses successeurs peuvent parcourir des sites web ordinaires comme le ferait une personne, et comprendre qu’un groupe de paragraphes est une « liste » même sans balisage explicite
  Ce que décrit l’auteur ressemble au fond à une API passant par des éléments sémantiques HTML. Mais s’il existe une API, il n’y a pas besoin d’un grand modèle de langage pour l’accès automatisé aux données : un simple script Python utilisant Beautiful Soup suffit, avec l’avantage de s’exécuter uniquement en local

  • Je pense que c’est une vision trop réductrice. Il y a « HTML », et il y a des sites web dont le DOM final n’est déterminé qu’après que l’utilisateur a essayé de lire pendant 10 secondes. Entre ces deux extrêmes, il existe de grandes différences dans le degré d’utilisation requis des fonctionnalités du navigateur.
    Au bout du compte, ce qui distingue le bon du mauvais, c’est la complexité de mise en œuvre. N’importe quel outil peut être bien ou mal utilisé, et un débutant peut provoquer un gros accident avec une scie circulaire et une batterie chargée. Un artisan peut aussi choisir de ne pas utiliser l’outil du tout et de taper à côté, autrement dit d’aller à l’encontre des besoins métier.
    Les sites web que j’ai créés récemment sont les plus compatibles que j’aie jamais faits. Je n’utilise plus de websockets et je ne dépends plus d’un JavaScript qui dialogue par petits morceaux avec le serveur. Même avec JavaScript complètement désactivé, environ 80 % du produit reste utilisable. Je ne vois pas en quoi de tels choix d’ingénierie ne seraient pas une solution à la dépendance aux écosystèmes fermés.
  • Dire que « ChatGPT et ses successeurs peuvent parcourir des sites web ordinaires comme le ferait une personne » me semble plutôt être une affirmation qui n’est pas encore vraie. Mais si l’on suppose que c’est possible, c’est intéressant.
    Les grands modèles de langage sont entraînés sur du texte, du code source, etc., mais sans véritable mécanisme qu’on pourrait appeler moteur de raisonnement, peuvent-ils vraiment regarder un arbre DOM et savoir ce que c’est et ce qu’il fait ? Le DOM n’est pas du texte, et il est difficile de le considérer comme du code source bien structuré, puisqu’il résulte du bundling et de la componentisation. Cela ressemble presque à dire qu’un « grand modèle de langage peut regarder un .exe arbitraire et l’intégrer immédiatement ».
  • J’ai compris l’intention de l’article comme un appel à utiliser, à la place ou en plus d’un amas de div réservé à JavaScript, du contenu sémantique lisible par la machine au-dessus de HTTP. Ainsi, les agents automatisés comme la nouvelle vague de grands modèles de langage pourraient extraire facilement les détails importants sans lancer un navigateur headless pour rendre la page.
    J’ai un intérêt similaire, mais pour le crawling et les nouveaux moteurs de recherche. Si chaque page doit être exécutée dans un navigateur headless avant d’être indexée, la barrière à l’entrée pour un nouveau moteur de recherche devient beaucoup plus élevée.
  • C’est une remarque pertinente. Ironiquement, le principal avantage du balisage sémantique semble désormais être devenu une abstraction qui facilite le styling et le contrôle par les développeurs humains.
  • ChatGPT peut vraiment faire ça ? Le fait-il réellement ?

• La première phrase de l’article est : « avec l’arrivée de l’intelligence artificielle fondée sur les grands modèles de langage, le HTML sémantique est devenu plus important que jamais ». À mon avis, la phrase inverse, « avec l’arrivée de l’intelligence artificielle fondée sur les grands modèles de langage, le HTML sémantique est devenu moins important que jamais », est bien plus défendable.
  Le web sémantique a échoué, et Google l’a remplacé en dépensant des sommes énormes dans toutes sortes d’heuristiques adossées à ce qui était alors l’état de l’art de l’intelligence artificielle. Plus l’intelligence artificielle s’améliore, plus elle devient capable d’extraire de l’information à partir de n’importe quel fatras construit n’importe comment ; et si ce fatras suffit, l’effort que les gens fourniront s’arrêtera là. En principe, au bout du compte, le web sémantique comme les tas d’heuristiques seront remplacés par l’intelligence artificielle.
  Le fait que l’article écrive LLM au début puis passe ensuite au terme général AI est aussi important. Les grands modèles de langage ne sont pas toute l’intelligence artificielle : ils ne sont qu’une branche actuellement très en vue, et pas la dernière. Il n’est pas bon de faire des projections sur les décennies à venir en supposant que les grands modèles de langage sont la réponse finale à l’intelligence artificielle.

  • Est-ce que l’idée est que l’intelligence artificielle va aussi résoudre l’accessibilité web fondée sur le HTML sémantique et ARIA ? Si ce n’est pas le cas, il faudra toujours des humains pour garantir que le contenu web soit accessible, et dans ce cas le HTML sémantique restera important.
  • Je me demande à quoi ressemblera l’optimisation pour les moteurs de recherche après les grands modèles de langage.
    Si l’objectif était que les parties pertinentes du contenu soient suffisamment bien indexées pour être classées, on peut dire que l’incitation à adopter complètement le HTML sémantique était insuffisante.
    Si l’objectif passe de « être bien classé » à « permettre aux grands modèles de langage d’extraire autant que possible les nuances et la texture du contenu », l’incitation à mieux utiliser certains éléments pourrait augmenter. Les sites qui le font pourraient avoir une plus grande influence sur les sorties des grands modèles de langage.
    Cela me fait penser à la différence entre parler assez fort pour être entendu et parler assez clairement pour être compris.
  • schema.org et Wikidata/Wikipedia ne soutiennent-ils pas encore la plupart des résultats enrichis de Google ?
    J’ai entendu parler de l’annonce de la nouvelle page de résultats avec Bard, mais je ne crois pas l’avoir vue — peut-être à cause de mon habitude d’ignorer les publicités, ou parce qu’elle n’est pas encore disponible dans ma région — donc il faudra que je vérifie.
  • L’intelligence artificielle donne l’impression d’être magique. J’ai toujours pensé que la capacité humaine de reconnaissance de motifs était assez unique et difficile à reproduire. C’est cette capacité que l’on utilise quand on parcourt le fatras d’un site web pour en extraire des données d’une manière ou d’une autre.
    Intellectuellement, j’étais plutôt du côté du web sémantique, mais si les machines peuvent comprendre plus ou moins ce fatras, alors l’argument selon lequel il n’y a pas vraiment de raison de se donner cette peine se tient.
  • Les projets qui veulent créer des ressources de données et faire en sorte que l’intelligence artificielle les utilise passent à côté de l’essentiel. L’intelligence artificielle elle-même est une ressource de données.
    Certains projets affirment que les graphes de connaissances ou d’autres actifs de données peuvent aider l’intelligence artificielle à rechercher des connaissances « vraies ». Personnellement, je pense qu’il vaut mieux développer des méthodes permettant à l’intelligence artificielle de créer ses propres actifs de données. Les poids d’un réseau neuronal font partie de ces actifs.
    La question de la vérité reste très difficile. Comment indiquer à une intelligence artificielle qu’un savoir est plus fiable qu’un autre ? Bien sûr, les humains ont le même problème.

• Je n’avais presque jamais entendu parler de la plupart de ces éléments HTML, et c’est assez regrettable. Parce que ce genre de choses pourrait beaucoup aider à mettre fin à l’écosystème où « tout a besoin de JavaScript »
  À tout le moins, cela pourrait remettre JavaScript à une place plus proche de son intention initiale : un moyen d’ajouter un peu d’ornement ou d’interaction. Il n’a pas besoin d’être un substitut à tout le balisage ni le gestionnaire complet du DOM
  Le navigateur dont je rêve ressemblerait peut-être à visurf https://sr.ht/~sircmpwn/visurf/, avec le moteur Netsurf interne mis à jour pour prendre en charge du HTML+CSS moderne incluant ces éléments. Avec un tel navigateur, on pourrait construire un petit Web presque sans JavaScript. L’accessibilité serait meilleure, en cassant moins les lecteurs d’écran, les thèmes système, les raccourcis clavier, etc. ; cela utiliserait beaucoup moins de ressources que les lourds dispositifs JavaScript remplaçables ; et la plupart de ce qu’on attend aujourd’hui d’une application Web de niveau intermédiaire semblerait possible. Pour des choses comme WebGL, il suffirait de lancer Firefox, mais par exemple un client Matrix pourrait n’avoir besoin que d’un peu de JavaScript pour les WebSockets et le chiffrement de bout en bout

  • Le problème général de ce type de composants intégrés, c’est qu’il est difficile de leur appliquer un thème. Quand un composant au style Windows 7 surgit au milieu d’une application moderne, c’est terriblement gênant
    Ils sont aussi très peu extensibles, donc dès qu’il faut faire quelque chose d’un peu complexe, on finit par les abandonner et recommencer en JavaScript. Dans ce cas, autant partir en JavaScript dès le début : ça marche bien, ça donne un contrôle total et ça se comporte de la même façon sur tous les systèmes
    Au final, ces composants supplémentaires restent du gonflement que tous les navigateurs doivent implémenter, mais que personne n’utilise
  • Quand j’ai vu datalist pour la première fois, je me suis dit : « waouh, c’est un game changer ». Le comportement est le même d’un navigateur à l’autre, mais l’apparence dépend entièrement du navigateur et on ne peut pas la styliser en CSS
    Parfois, seul le texte de la donnée est affiché ; parfois, le texte et l’attribut value sont affichés ensemble. Du coup, au lieu de sélectionner « Atlanta », on sélectionne « 234290780 Atlanta », c’est-à-dire l’ID et la valeur ensemble
    Même au clic, on ne peut pas obtenir directement l’ID : il faut récupérer l’ensemble et parser l’ID. Ça donne vraiment l’impression d’un élément abandonné
  • Ceci pourrait vous plaire : http://youmightnotneedjs.com/
  • Je ne suis pas opposé à l’idée générale, mais ces éléments existent depuis longtemps. Pour qu’une critique du HTML soit prise au sérieux, il faut à mon avis en connaître les bases
    L’article renvoie vers MDN, et MDN est probablement la référence courte la plus utile. Bien sûr, il y a aussi la spécification HTML du WHATWG, et si elle est trop volumineuse, il existe des grammaires au format SGML DTD pour les snapshots WHATWG HTML 2021 et 2023, ainsi que les anciennes grammaires de la série HTML 5.x
    [1]: https://sgmljs.net/docs/html200129.html
  • https://qutebrowser.org

• J’aimerais croire au Web sémantique, et croire que les navigateurs pourraient fournir de bons modules par défaut avec des styles par défaut corrects, mais il faut bien accepter que ce n’est pas le cas aujourd’hui
  Rien que pour associer un libellé à un input, il faut déjà se demander pourquoi ce n’est pas un attribut, puis on ne sait pas vraiment s’il faut l’utiliser comme wrapper ou le placer comme élément frère avec un attribut for=. Et ce n’est que la partie émergée de l’iceberg. Pour chaque balise, il faut apprendre toute son histoire de développement et rechercher à nouveau quelle est la bonne façon de faire aujourd’hui
  On aurait pu avoir quelque chose de bien, mais il est peut-être temps de se calmer et de lâcher prise

  • Je ne vise personne en particulier, ne sachant pas quels outils chacun utilise, mais si les développeurs Web avaient consacré ne serait-ce qu’une partie du temps passé à apprendre React, Tailwind, etc. à apprendre le HTML, le Web serait dans un bien meilleur état
    Il y a évidemment des bizarreries et des angles rugueux, mais si tous les développeurs Web savaient tirer le meilleur parti du HTML sémantique, il y aurait beaucoup moins de JavaScript dans les navigateurs, moins de bugs d’accessibilité, et probablement davantage de regards sur la spécification lorsqu’il faudrait corriger ou remplacer ces étrangetés
  • Si le libellé d’un champ était un attribut HTML, les formulaires seraient beaucoup moins flexibles. Cela fusionnerait deux éléments visuels en un seul, ce qui rendrait l’ajustement de l’affichage difficile. Il suffit de penser, par exemple, à un champ avec un libellé aligné à droite sur sa gauche, ou à une case à cocher avec le libellé à droite
    Un attribut label désignerait sans doute du contenu en texte brut, ce qui paraît trop restrictif
    HTML a, comme on peut s’y attendre après des décennies d’usage, une histoire complexe et plusieurs couches. Cela dit, il n’a pas beaucoup changé récemment, et grâce à MDN, il est assez facile d’apprendre ce que permet HTML5 et d’approfondir quand c’est nécessaire
  • Dans mon cas, j’ai presque toujours envie de mettre la balise label après la balise input. Cela permet, avec les pseudo-classes CSS, de sélectionner et styliser le libellé en fonction de l’état de l’entrée
  • Devoir apprendre la signification de chaque balise fait intrinsèquement partie de tout système de balisage sémantique. Si cette idée vous déplaît, c’est que vous n’êtes fondamentalement pas en phase avec l’idée même de Web sémantique
    Bien sûr, pour utiliser efficacement n’importe quel système de publication — en fait, n’importe quel système — il faut apprendre à utiliser les éléments de base qu’il fournit. Ce n’est donc pas un problème propre au Web sémantique

• J’utilise beaucoup details pour déboguer des templates HTML en Go
  En mettant les données en mode développement avec {{if .DevMode}}, quand c’est replié, ça ne casse pas trop la page et reste discret ; quand on en a besoin, on déplie et on peut voir tout le contenu

  • J’abuse un peu de l’élément details dès que possible. C’est très propre, je ne comprends pas pourquoi il n’est pas plus utilisé
  • On peut l’utiliser pour plein de choses sur une page Web, comme des menus repliables
    Il fonctionne aussi dans GitHub Markdown, et certaines personnes l’utilisent pour des exemples ou des explications inline

• Les lectures et les démos interactives étaient très bonnes
  Après avoir touché à Flutter pendant quelques années, j’en suis revenu à la même conclusion. Il faut miser sur HTML
  Le combo Astro / Tailwind / Daisy UI / Alpine.js est bien adapté pour créer des sites HTML qui utilisent beaucoup de rendu côté serveur simple et saupoudrent un peu de réactivité côté client
  Le résultat, ce sont de simples fichiers HTML tout à fait corrects, agréables à consulter et qui fonctionnent bien dans les navigateurs web desktop comme dans les WebView mobiles encapsulées. Mon appli est pratiquement statique, donc elle est mise en cache sur un CDN, fonctionne hors ligne, et l’affichage du source facilite le débogage

  • Après avoir essayé plusieurs frameworks et plateformes tape-à-l’œil, j’ai fini par faire la même chose : un site statique avec Alpine.js et Tailwind. C’est de loin la meilleure décision que j’aie prise jusqu’ici
    Le mieux, c’est que je peux être sûr qu’un nouveau développeur, qu’il vienne de React, Angular, PHP ou Python, comprendra le fichier de build de 100 lignes en environ 3 minutes. C’est vraiment simple, et c’est très bien
  • À mon avis, l’export web avec Flutter est presque un cauchemar. La dernière fois que j’ai vérifié, le rendu se faisait dans un canvas, et il n’y avait aucun balisage
  • Quelqu’un peut m’aider à comprendre l’utilité de Daisy UI ? J’ai l’impression d’utiliser les anciennes classes + feuilles de style, mais avec l’étape supplémentaire de Tailwind
  • Oui, Astro et l’architecture en îlots sont vraiment agréables à utiliser

• Je pense que le problème du web sémantique, c’est que, même si cela devient très facile, les développeurs refusent de l’utiliser correctement. Mon extension de navigateur utilise la balise main, donc je l’observe attentivement ; la documentation MDN est très claire sur ce qu’il faut faire, et elle montre elle-même de bons exemples d’utilisation. Pourtant, très peu de sites l’emploient correctement
  Même des sites professionnels très soignés enveloppent souvent tout le contenu de la page dans la balise main, y compris la navigation, le footer, etc. Cette balise ne devrait servir qu’au contenu principal de la page
  Si l’on n’arrive même pas à utiliser correctement un élément aussi simple, je n’attends pas grand-chose des autres éléments

  • C’est le même genre que les développeurs qui utilisent mal les verbes HTTP
    Il ne faut pas faire semblant que ce sont des contrats
  • Littéralement tous les développeurs qui ont utilisé la balise p pour un paragraphe l’ont fait correctement. Ce n’est pas comme class="card"
    Je ne comprends pas que tant de gens très compétents techniquement se lamentent autant sur l’inutilité ou l’échec du web sémantique. On dirait quelqu’un qui dirait : « J’aimerais que l’automobile réussisse, ça rendrait les longs trajets plus faciles »
  • La première solution qui me vient à l’esprit serait une validation plus stricte : si la structure n’est pas correcte, le navigateur refuse de faire le rendu
    Mais cette époque a existé. C’était globalement le cas avant HTML4, et c’était encore pire
    Donc il vaudrait peut-être mieux que les outils de développement affichent des avertissements ou des erreurs en cas de mauvais usage
  • Il n’y a absolument aucune incitation à le faire correctement. J’essaie moi-même de le faire, mais à part le temps passé à décider quel élément devait être utilisé, je n’ai constaté aucune différence

• Je trouve intéressant que beaucoup de commentaires ici voient cet article comme un texte anti-JavaScript. Pour moi, au contraire, ce sont des outils qui pourraient être extrêmement utiles avec les frameworks centrés sur TypeScript que nous utilisons dans les frontends d’applications d’entreprise modernes. Comme ce sont des outils natifs à HTML, ils ne demandent pas grand-chose
  Par exemple, la balise meter va probablement remplacer tous les modules de chargement que nous utilisons dans React dès que j’arriverai au travail aujourd’hui, parce qu’elle est bien meilleure que ce que nous utilisons actuellement
  Il se peut que j’aie mal compris les gens ou mal lu l’article, mais même lorsque tout le frontend est presque entièrement en TypeScript, comme dans les grosses applications d’aujourd’hui, c’est très intéressant

  • Mon espoir, c’est que ces éléments remplacent d’énormes blocs de code JavaScript. Je sais qu’un web sans JavaScript est malheureusement une illusion, mais on peut au moins retirer de gros morceaux et créer une expérience utilisateur plus standardisée, que le système peut guider et façonner
    De nouvelles applications peuvent désormais être créées avec beaucoup moins de JavaScript qu’avant. Dans les applications TypeScript d’entreprise existantes, cela pourra peut-être être une mise à niveau sur place, mais l’espoir est que, pour le développement de nouvelles applications, on puisse éviter ces frameworks d’entreprise eux-mêmes. On peut toujours rêver, non ?

• Je ne veux pas dénigrer complètement le développement web, mais c’est vraiment atroce. J’en ai fait pendant des années, du HTML brut aux langages de script et aux frameworks, et le temps qu’il faut pour faire des choses toutes simples me semble être un immense gaspillage de cerveau
  Quand je suis parti en vacances, je voulais juste trouver des endroits où manger et boire, ou des lieux où passer une journée, mais la plupart des sites étaient en vrac, vieux ou pas à jour. Il y a encore beaucoup de sites créés une fois puis oubliés. Probablement parce que les budgets sont serrés et qu’ils n’ont pas les moyens de les mettre à jour, ou parce que les mettre à jour est techniquement trop difficile
  La complexité des sites entraîne une paralysie. Ce qui devrait être quelques pages de texte simple et d’images est inutilement surconçu et brûle énormément de cycles CPU. Il y a aussi de fortes chances que ce soit bricolé à partir d’un CMS tout fait qui nécessite des mises à jour de sécurité
  Récemment, je regardais le site d’un cinéma, et il était presque impossible de parcourir ne serait-ce que les quelques films projetés cette semaine-là. Je me suis dit que ce serait plus lisible dans un tableur, et quand j’ai effectivement récupéré le JSON depuis l’API, c’était plus facile à lire
  La plupart du temps, ce n’est qu’un habillage fatigant, comme du rouge à lèvres sur un cochon. L’une des raisons du succès de Facebook, c’est la facilité d’onboarding, et une autre, la facilité de partager des photos. Même chose pour WhatsApp et Instagram. Publier devrait être facile. Le simple FTP est facile aussi, mais pour les gens ordinaires, il y a une rupture bizarre dans le parcours d’utilisation. Les gens veulent du glisser-déposer, téléverser, poser puis oublier, et modifier facilement. Ceux qui veulent consommer des données veulent au final l’essentiel. Les données, tout simplement

  • Je ne pense pas que les gens qui consomment des données veuillent seulement les données brutes. Le lecteur moyen de HN, peut-être, mais pas la personne moyenne
    Ce que les gens veulent, ce sont des pages web bien stylées et utilisables. Le problème, c’est qu’il n’y a pas assez de designers d’expérience utilisateur efficaces et talentueux, et que les parties prenantes des entreprises manquent elles aussi d’un sens correct de l’UX
    Du coup, fournir seulement les données brutes devient meilleur pour l’utilisateur moyen que l’UX médiocre qu’une entreprise moyenne peut se permettre. Même si ce n’est pas ce qu’il préférerait, c’est mieux
    {mauvaise UX} << {données brutes} < {bonne UX}
    Le contournement trouvé par WordPress a été de créer des styles et des thèmes professionnels, puis de permettre aux utilisateurs de les acheter et de les appliquer. Mais cela ne résout pas le mauvais goût des parties prenantes
    Je pense que Facebook a réussi parce qu’il a imposé une UX professionnelle et standardisée. {données des gens} + {UX professionnelle et standardisée} = {victoire}. On peut détester l’UX des débuts de Facebook, mais il est difficile de dire que c’était du travail d’amateur. La perception générale de MySpace, Geocities, etc., était l’inverse
  • La mention de WhatsApp met le doigt sur l’essentiel. Dans le pays africain où je vis, WhatsApp est tellement populaire que les opérateurs mobiles vendent même des forfaits de données WhatsApp
    Si je veux trouver quelque chose comme du grillage, je commence par demander dans les groupes WhatsApp dont je fais partie, famille, quartier, anciens camarades de lycée. En général, j’obtiens quelques numéros, puis je contacte les prestataires sur WhatsApp pour avoir les informations à jour
    Ces prestataires n’ont pas les moyens d’avoir un site web à jour. WhatsApp propose aussi une fonction permettant de mettre un catalogue dans le profil, et c’est destiné aux comptes Business gratuits
  • C’est pourquoi je recommande Wix à la plupart des petits commerçants. Est-ce que les sites se ressemblent tous ? Oui, et ce n’est pas forcément une mauvaise chose. C’est facile à utiliser et à mettre à jour, donc les clients apprécient d’obtenir les informations récentes dont ils ont besoin
    Ce que j’aimerais voir, c’est quelque chose comme des « Wix Widgets » : des widgets connectés aux données, avec juste assez de personnalisation pour relier des appels à des services REST et mapper des points de données vers l’affichage du widget. Cela aiderait pas mal à traiter les besoins en sites web internes que toutes les entreprises ont aujourd’hui
    Pour 90 à 95 % des pages web, une solution simple est vraiment nécessaire
  • C’est drôle d’entendre dire que la plateforme web est le meilleur système de GUI multiplateforme cohérent, alors que construire quelque chose dessus est atroce
    Je me demande si ce n’est pas simplement la nature même des GUI. Il faut donner chaque instruction une par une, cela consomme beaucoup de cycles, et sinon la structure ne fonctionne pas en multiplateforme
  • Une partie du problème vient du fait que les balises et éléments dans les fichiers HTML n’ont cessé de se multiplier. Ce n’est plus du balisage de document, mais du balisage de page, et il est difficile de voir où l’un finit et où l’autre commence. Même si le W3C a bien essayé en ajoutant les éléments article et section
    Bien sûr, le code HTML brut n’a sans doute jamais été conçu pour être lu par quelqu’un d’autre que des développeurs, donc il y a aussi cet aspect

• J’étais vraiment enthousiaste en apprenant l’arrivée des modales en pur HTML, puis déçu en découvrant qu’il n’y avait aucun moyen de les déclencher sans JavaScript. En pur HTML, on peut seulement les fermer, pas les ouvrir
  https://github.com/whatwg/html/issues/3567
  L’élément dialog est un excellent ajout et je suis content qu’il soit implémenté, mais une partie de ses fonctionnalités essentielles dépend de JavaScript. Pour ouvrir un dialog, il faut définir l’attribut open en JavaScript
  Ce serait bien qu’un élément button ou a puisse ouvrir une boîte de dialogue. Il existe déjà des précédents d’interactions de page intégrées à HTML. Par exemple, les liens peuvent faire défiler la page, et l’élément details peut masquer des éléments derrière une interaction ; il semblerait donc naturel qu’un autre élément de la page puisse ouvrir un dialog

  • Je ne suis pas sûr que l’objectif noble du « HTML seulement » implique d’étendre HTML avec des fonctionnalités de scripting. Dans ce cas, autant utiliser JavaScript
  • On peut implémenter une modale avec seulement HTML et CSS, sans JavaScript
    Par exemple, cliquez sur le ? en haut à droite ici : https://aavi.xyz/proj/colors/
  • Ce serait bien que ce soit intégré à HTML lui-même, mais au moins le JavaScript nécessaire n’est pas compliqué et peut même être mis dans un attribut onclick
  • On peut l’afficher ou la masquer selon le hash actuel. Bien sûr, cette approche nécessite quand même du CSS