Hallo Habr! Ich präsentiere Ihnen die Übersetzung des Artikels "Der HTML- Code, den wir nie hatten" von Sergey Kucherov.
In diesem Jahr begann Berners-Lee 30 Jahre lang mit der Entwicklung von HTML. Seitdem haben wir einen langen Weg zurückgelegt, angefangen mit der Bewunderung für neue Technologien bis hin zur Behandlung von Internetabhängigkeit und Zensur. Was das Internet nicht stört, hat uns nicht gehackt, Passwörter gehackt, Identitätsdiebstahl, Computerviren, Würmer und jetzt sogar Ransomware-Viren. Haben Sie sich jemals gefragt, warum das Netzwerk immer noch so instabil und anfällig ist? Irgendwo auf diesem langen Weg haben wir den falschen Weg eingeschlagen? Lass es uns richtig machen.
HTML 1.0, 1993 veröffentlicht, enthielt nur 13 Elemente (nur diejenigen, die bis heute überlebt haben):
a, address, base, dd, dir, dl, dt, h1..h6, li, p, plaintext, title, ul
Der wichtigste von ihnen ist natürlich „Anker“ (a). Er definiert die Funktionalität, die für die ersten beiden Buchstaben des Standardtitels verantwortlich ist - Hypertext. Ohne Anker (oder Links) wäre HTML nur eine andere Textauszeichnungssprache. Es ist diese Fähigkeit, den Benutzer mithilfe des Universal Resource Locator (URL) an jedes Dokument auf der Welt zu senden, und dieses erstaunliche Phänomen namens World Wide Web wurde erstellt. Zwei Jahre später wurden HTML mehrere nützliche Elemente hinzugefügt: html , head , body sowie Elemente zum Erstellen von Formularen, Tabellen und Bildern.
Das letzte Element spielte wahrscheinlich die bedeutendste Rolle in der Geschichte des Internets. Indem wir dem Browser die Möglichkeit geben, nicht nur Text, sondern auch Bilder anzuzeigen, haben wir die neue Technologie nicht nur für eine kleine Gruppe von Wissenschaftlern und Enthusiasten, sondern auch für Millionen gewöhnlicher Benutzer attraktiv gemacht. Wir können mit Sicherheit sagen, dass diese Innovation die Branche sogar dazu veranlasst hat, die Geschwindigkeit des Internets und seine Zugänglichkeit für den Massenbenutzer zu erhöhen. Es gibt jedoch eine weitere Funktion dieses HTML-Elements, die historische Bedeutung hat. Schau hier:
<img src="http://ibm.com/ibm-logo.gif" />
Da es (zumindest zu diesem Zeitpunkt) nicht möglich ist, ein Binärbild in eine Textdatei einzubetten, ist das img Element mit einem Attribut ausgestattet, das den Ort angibt, an dem der Browser die gewünschte Datei finden kann. Diese einfache Idee war der Schlüssel zu einer großartigen Erfindung.
Der Schlüssel, den wir nie gedreht haben.
HTML 2.0 wurde im November 1995 veröffentlicht. Alle waren begeistert von den neuen Funktionen und wahrscheinlich, warum niemand die Idee hatte vorzuschlagen: Warum lassen wir nicht auch alle anderen HTML-Elemente dieses Attribut verwenden? Stellen Sie sich Folgendes vor:
<h1 src="/website/info/title"> </h1>
Dieser Code bedeutet, dass der Inhalt des Headers von dieser URL geladen werden sollte. Für ein so kleines Element mag es keinen Sinn machen, aber was ist mit einem div oder article ?
<article src="/parts/article/blog1298" />
Nun, macht das jetzt Sinn? Ich weiß, dass die Geschwindigkeit des Internets 1993 nicht so hoch war wie heute. Neue Funktionen haben bereits den größten Teil der vorhandenen Bandbreite belegt, und HTTP war nicht auf dem neuesten Stand. Es gab jedoch keinen Grund, eine solche Möglichkeit in der Norm zu verhindern.
Jetzt werden Sie wahrscheinlich darüber nachdenken, welche Auswirkungen dieses Attribut auf die Zukunft des WWW haben könnte. An sich vielleicht nicht so groß. Aber wenn wir noch eine Gelegenheit hinzufügen, könnte das Ergebnis ganz anders sein als jetzt. Wenn der Browser die Seite anzeigt, übersetzt er den HTML-Code in ein Dokumentobjektmodell (DOM) im Speicher. Dieses Modell bleibt unverändert, bis der Browser eine Anforderung erhält, es durch ein anderes HTML-Dokument zu ersetzen. Selbst 1993 funktionierte die Software nicht so primitiv. In diesem Jahr, als Netscape Navigator den Mosaic-Browser ersetzte, war Lotus 123 zehn Jahre alt und VisiCalc noch größer. Die Idee, den Zustand eines Dokuments als Funktion der vom Benutzer eingegebenen Daten zu berechnen, war bereits bekannt und recht einfach zu implementieren. Leider hat es niemand gewagt, es auf Browser anzuwenden. Stellen Sie sich vor, was passieren würde, wenn HTML 2.0 diese Gelegenheit hätte:
<div id="name">George</div> <h1>Welcome, $name</h1>
Wenn Sie in der Tabelle auf den Inhalt anderer Zellen verweisen können, kann das HTML-Dokument die Verwendung von Variablen ermöglichen, die auf die Werte anderer Elemente verweisen. Der obige Code wird beispielsweise als Welcome, George- Header angezeigt. Variablen könnten in URLs noch nützlicher sein:
<article src="http://server.com/blog/$name"></article>
Mit dem obigen Code wird der Inhalt des Artikels von der URL http://server.com/blog/George heruntergeladen. Wenn sich der Wert des Namenselements ändert, aktualisiert der Browser nur den Inhalt dieses einen Elements. Der Server ist nach wie vor für die Logik und Generierung von HTML-Code verantwortlich. In diesem Fall müssen AJAX und JavaScipt nicht verwendet werden. Diese neue Funktion, die noch von niemandem vorgeschlagen wird, würde es einfach machen, ein Suchfeld mit dynamischen Hinweisen zu implementieren:
<input list="find" type="text" id="term" /> <datalist id="find" src="http://server.com/search/$term" />
Das Auswerten von Ausdrücken ist natürlich viel sicherer als das Ausführen von eingebettetem Programmcode, dessen Folgen schwer vorherzusagen sind. Um HTML noch kompatibler mit Tabellenkalkulationen zu machen, müssen Sie die Möglichkeit hinzufügen, Funktionen zu verwenden:
@CONCATENATE(first,", ",last);
Es werden kein JavaScript, Schatten-DOM oder andere teure und äußerst unsichere Funktionen benötigt. Der Browser berechnet Änderungen im DOM automatisch anhand von Benutzereingaben. Heute nennen wir es reaktive Programmierung. Es ist eine Schande, dass wir 26 Jahre gebraucht haben, um dies zu entwickeln. Ist es zu spät, es jetzt zu implementieren?
Sie können davon ausgehen, dass die neuesten Versionen von HTML5 + CSS3 + JS für moderne Anforderungen ausreichen. Ich glaube nicht. Wir haben immer noch Probleme damit, eine einfache Benutzeroberfläche zu erstellen, und sind gezwungen, verwirrende JS-Bibliotheken wie Angular zu verwenden. Was ist mit Webkomponenten? Werden sie in der Lage sein, die Webprogrammierung schneller, einfacher und sicherer zu machen? Möglicherweise. Oder vielleicht auch nicht. Ich weiß nur, dass Komponenten extrem einfach zu implementieren sind, zusätzlich zu dem HTML-Standard, den wir nie hatten. Lassen Sie mich Ihnen das define Element vorstellen:
<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>
Das ist alles. Die Ressource, die unter der in der Komponenten-URL angegebenen Adresse geladen wird, ist eine reguläre HTML-Datei. Es kann Variablen, Funktionen sowie Links zu anderen Komponenten enthalten. Solche Webkomponenten können problemlos nicht nur auf einer Website, sondern auch als Standardbibliothek im Internet verwendet werden. Das HTTP / 2-Protokoll bietet viele nützliche Funktionen, mit denen der neue HTML-Code sein volles Potenzial entfalten kann. JavaScript kann belassen werden, wird aber in den meisten Fällen einfach nicht benötigt. Wann mussten Sie das letzte Mal ein Makro in einer Tabelle verwenden?