À propos d’un fork du Web

• L’objectif d’une spécification alternative n’est pas de viser l’ensemble du Web, mais de prendre en priorité pour cible la spécification HTML, qui faisait 18.3MiB une fois décompressée au 6 mai 2026, afin de conserver les avantages du Web tout en évitant ses inconvénients
• La spécification doit être courte et simple, et réduire la charge d’implémentation — par exemple en limitant à 1.44MiB l’archive tar.gz contenant l’ensemble de la spécification — afin de permettre l’apparition de navigateurs et de clients variés
• Au lieu d’être un document en évolution permanente comme la Web specification actuelle, elle doit avoir une version sémantique comme 1.2.3, et une version de standard publiée ne doit jamais être modifiée
• La spécification doit inclure une grammaire formelle non ambiguë facile à parser, et les pages non conformes au standard ne doivent pas être rendues, afin de réduire le coût de création des parseurs et des outils de traitement de contenu
• La spécification alternative ne vise pas une reproduction fonction par fonction du Web, mais l’échange d’informations centré sur le texte rédigé ; au lieu du scripting, elle privilégie l’ouverture de fichiers et d’URL standardisés dans des programmes natifs, comme avec les standards Geo link ou tiled web map

---

Objectifs d’une spécification alternative au Web

• La spécification HTML faisait 18.3MiB une fois décompressée au 6 mai 2026, et le premier périmètre d’examen se limite non pas au Web dans son ensemble, mais à la spécification HTML
• L’objectif est de créer une spécification alternative qui conserve autant que possible les avantages du Web tout en évitant ses défauts
• Il ne s’agit pas encore d’une spécification formelle, mais plutôt de notes informelles susceptibles d’évoluer avec le temps

Simplicité et diversité des implémentations

• L’ensemble de la spécification doit être court et simple, et il doit être possible de créer divers navigateurs et clients avec peu d’efforts
• Comme il est très difficile de préserver la simplicité pendant des décennies, une façon de faire pourrait être d’imposer une limite de taille à la spécification en nombre d’octets
• Dillo utilise déjà la même approche pour faire tenir ses versions dans une seule disquette, et la spécification alternative pourrait elle aussi fixer une limite de 1.44MiB pour l’archive tar.gz contenant toute la spécification

Gestion sémantique des versions

• La Web specification actuelle est une page modifiée à peu près chaque semaine, ce qui oblige les clients à suivre en permanence les changements pour rester conformes à la spécification
• La spécification alternative doit avoir une version sémantique précise comme 1.2.3
• Il faut un critère de compatibilité tel qu’un document 1.2.3 puisse être rendu correctement par des navigateurs prenant en charge 1.2.3, 1.2.0 ou 1.3.0, mais pas par des navigateurs ne prenant en charge que 1.1.0 ou 2.0.0
• La cible de rédaction des documents ne doit pas être l’état d’implémentation navigateur par navigateur, mais la version du standard ; par exemple, on pourrait rédiger pour la version 1.2.0 en partant du principe que 90 % des navigateurs prennent en charge ce standard
• Une version de standard publiée ne doit jamais être modifiée
  • Les corrections de coquilles se font par incrément du numéro de patch
  • Les nouvelles fonctionnalités rétrocompatibles se font par incrément du numéro mineur
  • Les changements cassant la compatibilité nécessitent un incrément du numéro majeur
• Même avec seulement une version imprimée du standard 1.2.0, il devrait être possible de créer dans un environnement isolé un navigateur entièrement conforme, capable de parser correctement et durablement les documents 1.2.X

Grammaire stricte

• La spécification doit inclure une grammaire formelle non ambiguë facile à parser
• Les pages doivent être testées par rapport au standard pour déterminer leur conformité, et les pages non conformes ne doivent pas être rendues
• Il doit être explicitement interdit aux clients d’accepter des pages qui ne respectent pas la spécification
• Cela évite d’avoir à implémenter des règles de standardisation complexes pour corriger des pages cassées, et force aussi à corriger les erreurs de la spécification dans les versions ultérieures
• Une grammaire stricte pourrait pousser vers des langages plus faciles à écrire pour les humains et plus tolérants, comme Markdown, et c’est un effet recherché
• L’objectif est de simplifier les parseurs et de réduire le coût de création d’outils manipulant le contenu
• Les changements de version patch ne modifient que la formulation, la grammaire restant inchangée

Possibilité de réutiliser HTML

• Il serait souhaitable de pouvoir créer un sous-ensemble de HTML fonctionnant avec un minimum d’efforts dans les logiciels existants
• Toutefois, cela pourrait être impossible en raison de la complexité du parsing HTML
• Comme créer une grammaire formelle pour des documents XML n’est pas non plus trivial, il faut examiner si HTML/XML sont vraiment des formats adaptés à un parsing simple

Résistance à la capture du standard

• L’un des problèmes du Web est que, lorsqu’un acteur dominant peut mettre en place des mécanismes d’extraction de rente, il a intérêt à capturer le standard et à le faire évoluer à son avantage
• Dans le Web, cela a selon cette analyse conduit à une complexité du standard devenue incontrôlable, à une barrière d’entrée plus élevée pour les nouveaux navigateurs et à une baisse de la concurrence
• Il existe déjà quelques idées initiales pour éviter cette situation, mais elles demandent un examen plus prudent du point de vue de la théorie des jeux

Principe du texte d’abord

• L’objectif de la spécification est de couvrir le niveau de détail suffisant pour transmettre de l’information entre humains, comme le font un livre imprimé ou un texte écrit
• Le texte rédigé doit être prioritaire, car c’est le support le plus polyvalent pour encoder l’information
• Le texte peut être traduit, lu à voix haute par un ordinateur et stocké dans peu d’espace
• Les documents doivent être repliés à la ligne en fonction de la taille de l’écran, afin qu’un même document puisse être lu aussi bien sur petit que sur grand écran

Exclusion du scripting

• L’ajout de capacités de scripting a été une erreur, et peut donc être évité dans la spécification alternative
• Cela ne signifie pas pour autant limiter l’usage de programmes interactifs par les utilisateurs
• Par exemple, aujourd’hui on charge dans le navigateur une carte interactive affichant l’emplacement d’un point d’intérêt via JavaScript ; on pourrait à la place fournir un Geo link pour ouvrir cet emplacement dans n’importe quel client prenant en charge ce protocole
• De même, s’il existe une spécification publique, n’importe quel client peut utiliser les tuiles cartographiques d’un serveur ; l’exemple cité est celui du standard tiled web map
• Le fait d’ouvrir des fichiers ou des URL standardisés dans des programmes natifs permet une optimisation selon l’appareil utilisé, et évite l’approche uniforme de nombreuses pages web interactives

Ce qui n’est pas l’objectif

• L’objectif n’est pas de reproduire le Web fonctionnalité par fonctionnalité
• L’objectif est de créer une spécification permettant aux humains d’échanger connaissances, notes et autres informations, tout en supprimant l’exigence de devoir exécuter une VM complète pour les lire

[GN⁺]

Avis sur Lobste.rs

• Donc il faudrait à nouveau une app pour tout ? Je ne suis pas d’accord avec l’idée que la capacité de scripting ait été une erreur
  Je trouve positif que le Web soit une plateforme généraliste qui dépasse les frontières des systèmes d’exploitation

  • Même avis. L’avantage d’ouvrir des fichiers standardisés ou des URL dans des programmes natifs, c’est l’optimisation pour l’appareil et l’évitement du modèle de page web « taille unique », mais je n’ai pas envie de revenir à l’époque où les utilisateurs Linux étaient des citoyens de seconde zone
    L’époque où seul Windows était pris en charge, avec parfois Mac ajouté en bonus
  • On peut se plaindre des web apps sur bien des points, mais c’est aussi quasiment le seul moyen d’éviter la taxe Apple et la future taxe de Google lorsqu’on distribue des apps sur plateformes mobiles
    Et comme la situation du développement natif sur desktop n’est pas simple non plus, je comprends tout à fait ceux qui choisissent les web apps ou Electron sur ordinateur
  • Pourquoi faudrait-il une app pour tout ? Cette spécification n’empêche pas l’exécution dans un navigateur web classique, et le Web actuel ne va pas disparaître
  • Le vrai bon angle, à mon avis, c’est de chercher jusqu’où on peut aller avec un markup standardisé uniquement
    Le problème du Web moderne, c’est qu’il réinvente sans cesse des concepts, dont une grande partie devrait relever d’un markup déclaratif. Il ne devrait pas être nécessaire d’avoir du JavaScript dans le chemin d’affichage d’un site. Le scripting devrait servir à certains usages de programmation côté client, quand on fait côté client ce qui se faisait côté serveur, par exemple traiter un jeu de données renvoyé par le serveur
  • En réalité, il y a déjà une app pour tout. On les appelle simplement URL ou noms de domaine au lieu d’apps
    On a l’impression que l’industrie IT a poussé le navigateur web comme machine virtuelle de facto une fois devenu évident que des alternatives sandboxées comme Java et Swing ou Flash étaient douloureusement inférieures. Aujourd’hui, une application unique, Google Chrome, sert de machine virtuelle pour la majeure partie de l’informatique grand public, et elle est détenue et développée par un monopole de capitalisme de surveillance. Je ne sais pas si c’est vraiment plus sûr, ou si c’est simplement que les vrais zero-days coûtent désormais trop cher pour être divulgués
    Je pense que l’ajout du scripting a été une erreur. C’était au moins une fonctionnalité ajoutée après coup, et je suis d’accord avec Dillo pour limiter le périmètre d’un lecteur de documents hypertexte à la lecture de documents, au lieu d’essayer de permettre aussi la création et l’édition de documents dans le lecteur
    L’objectif ne devrait pas être de reproduire le Web fonctionnalité par fonctionnalité, mais de créer une spécification lisible sans exiger l’exécution d’une machine virtuelle complète juste pour échanger du savoir, des notes et des informations
    J’aimerais voir une application généraliste réduite, dans une meilleure sandbox, capable de répondre à la plupart des besoins « d’interaction ». A-t-on vraiment besoin d’une machine virtuelle complète pour échanger de l’hypertexte dans un feed de réseau social comme Reddit ? A-t-on besoin d’une machine virtuelle complète pour gérer un panier et des informations de paiement ?
    Cela dit, le « généraliste » finit souvent par engloutir « l’application », et on risque alors de réinventer le Web. Malgré tout, s’il y avait une chance d’avoir une base portée par autre chose que Google et un langage autre que C++, ce serait peut-être déjà mieux. Dillo semble être en C et C++, donc peut-être qu’on a déjà amélioré au moins un des deux points

• Une autre amélioration utile serait d’utiliser une version réduite de HTTP, avec prise en charge uniquement des cookies de session contrôlés par le client, interdiction des ressources tierces, et obligation de rendre les formats comme text/markdown via des convertisseurs intégrés au navigateur en gardant toutes les ressources sur le même serveur web que le document

  • Interdire les ressources tierces à lui seul permettrait d’éviter plusieurs problèmes graves
  • Idéalement, j’aimerais quelque chose d’indépendant du mode de transport. Je commencerais probablement par le local afin que cela fonctionne depuis n’importe quel point de montage de système de fichiers distant
    Cette fois, l’idée serait d’améliorer le régime pour voir si on peut éviter les cookies. C’est une représentation machine du document, conçue pour être lisible par des humains, mais pas pour être écrite directement par eux. Mieux vaut utiliser un langage frontend comme Markdown et le compiler en document strict et portable
  • À mon avis, si les cookies sont vraiment nécessaires, ils devraient être limités au domaine exact du site. Un cookie de example.net ne devrait pas être envoyé à sub.example.net, et sub.example.net ne devrait pas non plus pouvoir définir des cookies pour example.net
    Il vaudrait mieux laisser HTTP/2 et HTTP/3 au Web applicatif, et garder HTTP/1 pour le Web documentaire. Je ne vois pas comment on pourrait limiter JavaScript sans retomber dans le problème du « il faut un navigateur dédié pour voir mon contenu », donc il ne devrait pas y avoir de JavaScript
    Si l’on exige le rendu de text/markdown, se pose aussi la question de la version concernée. Il existe environ une demi-douzaine de variantes qu’il faudrait prendre en charge

• Une syntaxe stricte ne fonctionnera probablement pas. C’est aussi pour cela que XHTML a échoué, et pourquoi HTML5 a ajouté des règles pour gérer les « cassures » courantes
  On pourrait certes re-spécifier HTML5 avec une grammaire plus formelle, comme le souhaite l’auteur, mais rejeter strictement les pages ne me semble pas être un bon usage d’un fork. L’autre alternative, c’est de devenir encore un énième remplaçant de gopher/gemini, et s’ils ont un public passionné, il y a aussi une raison à leur manque de popularité. La force de la rétrocompatibilité est trop grande

  • Je ne suis pas d’accord avec l’idée que XHTML ait échoué à cause de sa rigidité. C’est surtout parce que IE n’a pas pris en charge XHTML avant 2011, beaucoup trop tard, et que les gens n’ont donc pas utilisé du vrai XHTML ni bénéficié de ses avantages
    La rigueur peut être excellente, mais il faut un support pour que cela fonctionne

• L’idée que « l’ajout du scripting a été une erreur » est un vieux mème chez un certain type de programmeur morose qui n’aime pas qu’on s’amuse, mais je trouve cela surtout révélateur d’un manque d’imagination
  Le multimédia interactif appliqué avec soin peut énormément améliorer la communication et l’explication. Il suffit de voir les schémas interactifs du tutoriel Hex-Grid de Red Blob Games ou la fantastique explication du mécanisme d’une montre mécanique par Bartosz Ciechanowski. Grâce aux médias interactifs sur le Web, on peut aussi essayer des ordinateurs rares mais historiquement importants comme le Canon Cat en quelques secondes via un simple clic, sans passer par le cauchemar consistant à compiler et lancer un émulateur natif. L’envoi de formulaires et les image maps ne sont qu’une ombre très pâle du multimédia, et déplacent l’effort de prise en charge de l’interactivité vers un modèle centré sur le serveur, potentiellement gourmand en bande passante
  Le problème n’est pas le scripting en soi, mais ce que les navigateurs actuels lui permettent de faire. De la même manière qu’on peut réduire HTTP et HTML à un système plus petit, plus simple et plus respectueux de l’autonomie de l’utilisateur, on peut conserver la plupart des aspects positifs du JavaScript web tout en réduisant fortement la surface d’API et le potentiel malveillant. On peut imaginer un Web où une sorte de rectangle interactif à la Flash vit dans la page, où l’interaction est fournie via des scripts Lua accessibles et inspectables par l’utilisateur, avec des capacités graphiques et d’entrée comme Love2D, tandis que les opérations intrusives — contacter un serveur distant ou accéder à la webcam — sont placées derrière une sandbox forte et un consentement explicite préalable de l’utilisateur
  On peut déjà construire aujourd’hui des applications web respectueuses dans cet esprit, mais les fondations sont cahoteuses et incohérentes, avec des absences évidentes de fonctionnalités utiles et des menaces inutiles pour la sécurité et la vie privée de l’utilisateur un peu partout
  Du point de vue de l’accessibilité, on pourrait imaginer des entrées d’UI déclaratives — boutons, champs, cases à cocher, curseurs — traitées strictement, et des formulaires côté client rendus comme des images et du markup dans un <iframe>, mais fonctionnant sans aller-retour vers un serveur distant. Beaucoup de calculatrices, d’outils et de visualisations interactives pourraient entrer dans ce modèle, avec une meilleure latence et une meilleure sécurité pour l’utilisateur qu’avec un modèle piloté par le backend

• Si l’on veut du texte d’abord, alors il faut aussi abandonner CSS. CSS existe surtout au service des entreprises, pas des utilisateurs. Le style devrait être contrôlé par le navigateur, pas par la page
  Si l’utilisateur choisit de lire la charge utile brute d’une page, l’essentiel de celle-ci devrait correspondre aux informations que le navigateur lui montre. Aujourd’hui, le contenu lisible n’est que la partie émergée de l’iceberg
  Concernant le « sans scripting », je suppose que si l’on enlève le style et les pages lourdes, le besoin de scripting qui affecte le rendu pourrait aussi fortement diminuer. Le scripting qui n’affecte pas le rendu a généralement été utilisé à l’encontre de l’intérêt de l’utilisateur

  • C’était justement le cœur de la cascade CSS à l’origine. Il existait un sous-ensemble raisonnable de CSS utilisable pour la mise en forme de livres et d’articles, et censé se fusionner avec les styles utilisateur
    Mais CSS et la mise en forme sont devenus trop complexes, et les styles utilisateur doivent désormais commencer par un reset CSS complet ou être extrêmement spécifiques à chaque site
  • Si l’on veut afficher un horodatage dans le fuseau horaire du lecteur, aujourd’hui il n’y a pas de solution sans scripting côté client
    Je suis tombé sur ce problème en créant un outil personnel sans JS côté client, et j’ai compris qu’il fallait soit stocker « mon réglage de fuseau horaire » sur le serveur, soit ajouter un petit script auxiliaire
    Si l’on laisse le navigateur contrôler le style, j’ai l’impression qu’on risque d’aggraver encore les cas du genre « ma page est lisible dans les navigateurs X et Y, mais pas dans Z »
  • Je vivrai très bien dans un monde rempli de CSS, de couleurs, d’arrière-plans voyants, de belles polices, de layouts flexbox et grid
    Je préfère ça à des documents ternes qui réduisent la voix de l’auteur à du texte noir sur fond blanc. CSS est le moyen d’expression de l’auteur sur le Web, et je n’ai vraiment pas envie de le voir disparaître. C’est complexe, oui, mais c’est justement une bonne chose parce que cela permet à davantage de personnes de faire des choses intéressantes sur leur propre site web
  • D’accord. Il faudrait approfondir avant d’interdire les styles d’auteur optionnels
    J’ai aussi l’intuition qu’en retirant les styles et les pages lourdes, on réduirait le besoin de scripts qui modifient l’affichage. Avec une syntaxe simple, on pourrait peut-être embarquer des « documents » dans des programmes natifs interactifs, plutôt que l’inverse

• Comme d’autres l’ont dit, Gemini est à mon avis une bonne référence. Encore une fois, Gemini tient presque de la performance artistique, mais il y a vraiment beaucoup à en apprendre
  Une fonctionnalité remarquable et trop peu connue de Gemini est la page à laquelle on peut s’abonner. Dans une page, les liens dont le texte commence par YYYY-MM-DD forment un feed implicite. C’est très limité et ça paraît idiot, mais je trouve que c’est l’une des fonctionnalités les plus impressionnantes de Gemini. Spec here
  En HTML traditionnel, on peut écrire un blog à la main. C’est fastidieux, mais tout à fait faisable. En revanche, pour maintenir des flux RSS/ATOM, il faut presque forcément un outil de génération de feed
  Un HTML de nouvelle génération orienté « contenu » gagnerait à intégrer quelque chose de similaire. Peut-être que h-feed dans microformats est la bonne manière de faire, mais j’aime vraiment la simplicité des pages abonnables de Gemini. Et les feeds omniprésents, c’est une bonne chose
  Le fait que Gemini soit orienté ligne par ligne et facile à parser est un gros avantage, mais j’ai l’impression que c’est trop limité et que cela peut nuire à l’accessibilité. Malgré tout, une sorte de HTML-lite à la Gemini me semblerait acceptable
  Un autre bénéfice possible d’un fork du Web serait de faire le ménage dans tout ce qui a été ajouté autour de HTML. <meta name="viewport" content="width=device-width, initial-scale=1.0"/> est assez irritant. Si l’on créait une nouvelle version avec ce que l’on sait aujourd’hui, on pourrait obtenir quelque chose de très correct
  Sur d’autres aspects, je suis moins certain. En principe, je suis totalement pour l’absence de JS. Mais l’un des meilleurs usages du Web reste l’accès universel à des services essentiels comme les administrations ou les banques. Je ne suis pas encore totalement convaincu qu’on puisse vraiment tout faire sans JS tout en conservant une bonne utilisabilité, même si c’est peut-être possible
  J’aimerais aussi souligner le passage de another comment disant que « cette spécification n’empêche pas l’exécution dans un navigateur web classique, et le Web actuel ne va pas disparaître »
  J’aimerais pouvoir lancer séparément un « navigateur web de contenu » et un « navigateur d’apps ». Pour beaucoup d’usages, il n’existe pas tant de meilleures alternatives au Web comme plateforme applicative, le Web a énormément progressé, et les développeurs semblent très largement le préférer à autre chose
  Dans un tel monde, Google Maps ne fonctionnerait pas dans mon navigateur web de contenu, mais s’ouvrirait dans le navigateur d’apps. Si j’exécute GMail dans le navigateur d’apps, les liens contenus dans les e-mails s’ouvriraient dans le navigateur de contenu
  Idéalement, le navigateur de contenu devrait être beaucoup plus facile à implémenter, ce qui favoriserait la concurrence et l’innovation. Mais je ne vois malheureusement pas bien le chemin pour y arriver. Je serais bien plus heureux si je pouvais faire toute ma navigation de contenu avec un tel navigateur. La surface d’attaque serait bien plus petite, donc je me sentirais plus serein sur le plan de la sécurité. Mais plus personne ne semble s’en soucier maintenant

  • Presque tous les cas d’usage légitimes de JS sur les pages web existent parce qu’il manque des fonctionnalités importantes au navigateur. On l’a appris pendant des décennies, et grâce au script les navigateurs n’ont pas eu besoin de les ajouter
    Donc il suffit de les ajouter comme fonctionnalités du navigateur

• Cela ressemble un peu à Gemini, mais ce fork permettrait sans doute un peu plus de choses
  Les sites web pourraient être écrits dans une variante de Markdown ou quelque chose d’approchant. Il faudrait que ce soient des documents faciles à lire même sous leur forme brute. Quelque chose comme Gemtext avec quelques fonctions supplémentaires, comme des médias inline
  Et il faudrait aussi autoriser un peu de style. Le Web a toujours été, et reste, un excellent lieu de créativité. Si l’on conserve un ensemble de styles simple et cohérent, les créatifs pourront faire des sites encore plus inventifs

• Il serait aussi intéressant de couvrir les éléments de base de HTMX

  • Personnellement, je préférerais simplement intégrer les primitives de Triptych. Cela donne juste assez pour construire côté serveur sans rendre le client excessivement complexe

• Cette idée fonctionnerait mieux avec une motivation claire. « Rendons-le plus simple » reste trop abstrait. Chacun a sa propre idée de la simplicité, donc il faut des objectifs plus explicites expliquant pourquoi le Web devrait être plus simple et à quel besoin concret cela répond
  Par exemple, le projet Gemini vise surtout à créer une communauté qui valorise une certaine forme de communication. Il a donc simplifié le Web en le limitant à ce format d’échange, cohérent avec les objectifs de cette communauté, et si je me souviens bien, les images ne sont même pas techniquement prises en charge
  À l’inverse, des outils comme Sciter ou Blitz visent à faciliter l’intégration d’un moteur de rendu de type navigateur dans d’autres applications. Ils simplifient en supprimant des comportements exotiques inutiles ou en rendant optionnels le parsing HTML et l’exécution de JS. Cela réduit à la fois ce qu’il faut implémenter et ce que l’utilisateur doit embarquer
  Les deux visent la simplicité, mais comme leurs objectifs fondamentaux sont très différents, les résultats le sont aussi. Quel est ici l’objectif fondamental ?