Bonjour, Habr! Je vous présente la traduction de l'article "Le HTML que nous n'avons jamais eu" de Sergey Kucherov.
Cette année marque 30 ans depuis que Berners-Lee a commencé à développer le HTML. Depuis lors, nous avons parcouru un long chemin, en commençant par l'admiration pour les nouvelles technologies et en terminant par le traitement de la dépendance à Internet et de la censure. Quels problèmes Internet nous a-t-il apportés, les mots de passe piratés, le vol d'identité, les virus informatiques, les vers et maintenant même les virus rançongiciels. Vous êtes-vous déjà demandé pourquoi le réseau reste si instable et vulnérable? Quelque part sur cette longue route, nous avons fait fausse route? Faisons les choses correctement.
HTML 1.0, publié en 1993, ne comprenait que 13 éléments (en ne comptant que ceux qui ont survécu à ce jour):
a, address, base, dd, dir, dl, dt, h1..h6, li, p, plaintext, title, ul
Le plus important d'entre eux, bien sûr, est «l'ancre» (a). C'est lui qui définit la fonctionnalité qui est responsable des deux premières lettres du titre standard - hypertexte. Sans ancres (ou liens), le HTML ne serait qu'un autre langage de balisage de texte. C'est cette capacité d'envoyer l'utilisateur à n'importe quel document dans le monde en utilisant le localisateur de ressources universel (URL), et ce phénomène étonnant appelé le World Wide Web a été créé. Deux ans plus tard, plusieurs éléments utiles ont été ajoutés au HTML: html , head , body , ainsi que des éléments pour créer des formulaires, des tableaux et des images.
Le dernier élément, a probablement joué le rôle le plus important dans l'histoire d'Internet. En donnant au navigateur la possibilité d'afficher non seulement du texte, mais aussi des images, nous avons rendu la nouvelle technologie attrayante non seulement pour un petit groupe de scientifiques et de passionnés, mais aussi pour des millions d'utilisateurs ordinaires. Nous pouvons affirmer avec certitude que cette innovation a même poussé l'industrie à augmenter la vitesse d'Internet et son accessibilité pour l'utilisateur de masse. Cependant, il existe une autre caractéristique de cet élément HTML qui a une signification historique. Regardez ici:
<img src="http://ibm.com/ibm-logo.gif" />
Puisqu'il est impossible d'incorporer une image binaire dans un fichier texte (au moins à ce moment-là), l'élément img est équipé d'un attribut qui indique l'endroit où le navigateur peut trouver le fichier souhaité. Cette idée simple était la clé d'une grande invention.
La clé que nous n'avons jamais tournée.
HTML 2.0 a été publié en novembre 1995. Tout le monde était ravi des nouvelles fonctionnalités, et probablement pourquoi personne n'a eu l'idée de suggérer: pourquoi ne laissons-nous pas tous les autres éléments HTML utiliser également cet attribut? Imaginez ceci:
<h1 src="/website/info/title"> </h1>
Ce code signifie que le contenu de l'en-tête doit être chargé à partir de cette URL. Cela peut ne pas avoir de sens pour un si petit élément, mais qu'en est-il d'une div ou d'un article ?
<article src="/parts/article/blog1298" />
Eh bien, est-ce que cela a du sens maintenant? Je sais qu'en 1993, la vitesse d'Internet n'était pas aussi élevée qu'aujourd'hui. De nouvelles fonctionnalités ont déjà occupé la majeure partie de la bande passante existante et HTTP n'était pas à la hauteur. Cependant, il n'y avait aucune raison d'empêcher une telle possibilité dans la norme.
Maintenant, vous penserez probablement à l’effet que cet attribut pourrait avoir sur l’avenir du WWW? En soi, peut-être pas si gros. Mais si nous y ajoutons une opportunité de plus, le résultat pourrait être très différent de ce que nous avons actuellement. Lorsque le navigateur affiche la page, il traduit le code HTML en un modèle d'objet de document (DOM) situé en mémoire. Ce modèle reste inchangé jusqu'à ce que le navigateur reçoive une demande pour le remplacer par un autre document HTML. Même en 1993, le logiciel ne fonctionnait pas aussi primitivement. Cette année-là, lorsque Netscape Navigator a remplacé le navigateur Mosaic, Lotus 123 avait dix ans et VisiCalc était encore plus gros. L'idée de calculer l'état d'un document en fonction des données saisies par l'utilisateur était déjà bien connue et assez simple à mettre en œuvre. Malheureusement, personne n'a osé l'appliquer aux navigateurs. Imaginez ce qui se passerait si HTML 2.0 avait cette opportunité:
<div id="name">George</div> <h1>Welcome, $name</h1>
Si, dans la feuille de calcul, vous pouvez faire référence au contenu d'autres cellules, le document HTML pourrait autoriser l'utilisation de variables faisant référence aux valeurs d'autres éléments. Par exemple, le code ci-dessus sera affiché en tant qu'en-tête Bienvenue, George . Les variables pourraient être encore plus utiles dans les URL:
<article src="http://server.com/blog/$name"></article>
Le code ci-dessus téléchargera le contenu de l'article à partir de l'URL http://server.com/blog/George . Et si la valeur de l'élément name change, le navigateur mettra à jour le contenu de cet élément uniquement. Comme maintenant, le serveur est responsable de la logique et de la génération du code HTML. Dans ce cas, il n'est pas nécessaire d'utiliser AJAX et JavaScipt. Cette nouvelle fonction, toujours proposée par personne, faciliterait l'implémentation d'un champ de recherche avec des indices dynamiques:
<input list="find" type="text" id="term" /> <datalist id="find" src="http://server.com/search/$term" />
De toute évidence, l'évaluation des expressions est beaucoup plus sûre que l'exécution de code de programme intégré, dont les conséquences sont difficiles à prévoir. Pour rendre HTML encore plus compatible avec les feuilles de calcul, vous devez ajouter la possibilité d'utiliser des fonctions:
@CONCATENATE(first,", ",last);
Aucun JavaScript, DOM fantôme ou autres fonctions coûteuses et extrêmement peu sûres ne sont nécessaires. Le navigateur calcule automatiquement les changements dans le DOM en fonction de l'entrée utilisateur. Aujourd'hui, nous l'appelons programmation réactive. C'est dommage qu'il nous ait fallu 26 ans pour en arriver là. Est-il trop tard pour essayer de le mettre en œuvre maintenant?
Vous pouvez supposer que les dernières versions de HTML5 + CSS3 + JS sont suffisantes pour les besoins modernes. Je ne pense pas. Nous avons encore du mal à créer même une interface utilisateur simple, et nous sommes obligés d'utiliser des bibliothèques JS déroutantes comme Angular. Qu'en est-il des composants Web? Seront-ils en mesure de rendre la programmation Web plus rapide, plus facile et plus sûre? C'est possible. Ou peut-être pas. Tout ce que je sais, c'est que les composants sont extrêmement faciles à implémenter en plus du standard HTML que nous n'avons jamais eu. Permettez-moi de vous présenter l'élément de define :
<head> <define tag=“login” src=“http://server.com/components/login”> <define tag=“footer” src=“http://server.com/components/footer”> </head> <body> <login toremember="yes" /> ... <footer /> </body>
C’est tout. La ressource chargée à l'adresse spécifiée dans l'URL du composant est un fichier HTML standard. Il peut contenir des variables, des fonctions ainsi que des liens vers d'autres composants. Ces composants Web peuvent être facilement utilisés non seulement sur un site Web, mais également comme bibliothèque standard sur Internet. Le protocole HTTP / 2 introduit de nombreuses fonctionnalités utiles qui permettront au nouveau HTML de fonctionner à son plein potentiel. JavaScript peut être laissé, mais dans la plupart des cas, il ne sera tout simplement pas nécessaire. À quand remonte la dernière fois que vous avez eu besoin d'utiliser une macro dans une feuille de calcul?