HTML Entwicklung: Veraltete und neue Tags

Nachdem ich zuletzt über noarchive geschrieben habe und darüber, was veraltete HTML-Tags anrichten können, sind mir jetzt zwei Artikel über den Weg gelaufen:

1. In seinem Artikel „Antiquated HTML Snippets and Artefacts“ nimmt Declan Chidlow uns mit zu einem Rundgang über den Friedhof: Alter Müll im HTML, den man getrost raustragen kann.
2. Chris Coyier hingegen zeigt uns eine Liste neuer HTML-Elemente von einer echten HTML-Autorität in „New Things You Should Know About HTML Here in Mid 2026“

Die Geister des HTML Friedhofs

Früher musste HTML nicht nur Inhalte beschreiben. Es musste Browser zähmen.

• X-UA-Compatible sagte dem Internet Explorer, in welchem seiner eigenen Modi er eine Seite darstellen sollte.
• Mit chrome=1 konnte sogar Googles Chrome Frame im Internet Explorer einspringen. Conditional Comments lieferten Markup gezielt an bestimmte IE-Versionen; Netscape hatte dafür wiederum seine eigene Technik.

Heute sollte sowas der Grab-Archäologie angehören, meiner Meinung nach.

Noch deutlicher wird das bei Tags, die sich gegen Eingriffe von Browsern und Erweiterungen wehrten.

Microsofts Smart Tags wollten automatisch Links in Webseiten setzen. Das Meta-Tag MSSmartTagsPreventParsing schaltete sie ab.

Baidus mobiler Browser konnte Seiten über eigene Server umformen, Styles entfernen, Bilder komprimieren und Werbung austauschen. Auch dagegen entstanden Opt-out-Tags. Die Skype Toolbar setzte Symbole neben Telefonnummern und brachte dabei mitunter Layouts durcheinander. Sogar Entwickler wurden per Meta-Tag ausgesperrt.

Zu den hübscheren Relikten gehört <meta name="ICBM">. ICBM steht tatsächlich für „Intercontinental Ballistic Missile“. Im Usenet-Jargon bezeichnete das die geografische Position; später nutzte GeoURL die Koordinaten, um Websites auf einer Karte einzuordnen.

Oder revisit-after. Das Tag sollte einem kleinen regionalen Suchdienst sagen, wann er eine Seite erneut besuchen sollte. Große Suchmaschinen nutzten es nach allem, was bekannt ist, nicht. Trotzdem verbreitete es sich als SEO-Regel.

Doch einige Relikte stellen sich als Zombies raus, in diesem Fall ziemlich adrette Zombies mit Rüschen.

Internet Explorer bot schon in den Versionen 4 bis 8 Übergänge zwischen Seiten. Proprietär, versteht sich. Heute gibt es dafür die standardisierte View Transition API.

Ähnlich bei Web-Apps. Microsoft, Google und Apple hatten jeweils eigene Tags für angeheftete Websites, Kacheln, Icons, Startseiten und Vollbildmodi. Vieles davon wurde später durch modernere PWA-Mechanismen ersetzt.

Nun geht die Idee noch einen Schritt weiter: Ein experimentelles <install>-Element soll die Installation einer Web-App direkt als semantische Funktion der Seite anbieten. Statt darauf zu hoffen, dass der Nutzer irgendwo im Browsermenü den richtigen Punkt findet, könnte die Seite selbst einen Installationsknopf bereitstellen. Fraglich ist, ob die Browser mitziehen, es klingt erstmal nach einer sinnvollen Idee für mich.

Das ist der Unterschied zwischen gestern und heute: Früher baute jeder Hersteller seinen Sonderweg. Heute versucht die Plattform, gemeinsame Begriffe dafür zu finden.

Neu: Klickfehler oder fehlerhafte Auswahl sind einfacher zu korrigieren

Besonders interessant sind <geolocation> und <usermedia>.

Beide zielen auf ein altes Problem: Berechtigungen für Standort, Kamera oder Mikrofon. Wer sie einmal ablehnt, muss seine Entscheidung heute oft mühsam in den Browser-Einstellungen ändern.

Nicht das Tag selber ist die spannende Idee, sondern die „Recovery“ Möglichkeit dahinter: Der Nutzer kann später einfach erneut entscheiden. <geolocation> macht aus der Standortfreigabe ein spezialisiertes Bedienelement; <usermedia> übernimmt den Ablauf für Kamera und Mikrofon.

Diese Elemente sind noch kein HTML-Alltag. Die Unterstützung ist bislang begrenzt beziehungsweise experimentell. Man sollte sie beobachten, nicht blind ausrollen.

Mehr Semantik, weniger Marke Eigenbau

Das klassische <select> lässt sich mit neueren CSS- und HTML-Mechanismen deutlich freier gestalten. Gem. Coyier unterstützen Chrome & Safari diesen Ansatz. Elemente wie <selectedcontent> und Pseudoelemente für den Picker geben Entwicklern Kontrolle, ohne das Element komplett nachbauen zu müssen.

Declarative Shadow DOM ermöglicht Shadow DOM ohne JavaScript:

• focusgroup soll eine Tastatursteuerung vereinfachen, die bislang oft als „roving tabindex“ per JavaScript implementiert wird.
• hidden="until-found" kann Inhalte verstecken und sie trotzdem für die Seitensuche auffindbar halten.

Nothing special, aber wichtig.

Spannend ist auch die Commands-API.

Ein Button kann deklarativ ein anderes Element anweisen, etwa ein Popover zu öffnen oder zu schließen. Es gibt eingebaute Befehle wie show-popover, hide-popover und toggle-popover; auch eigene Commands sind möglich.

Coyier schreibt, diese allgemeinere API fühle sich „wie die Zukunft“ an. Besonders interessant sind sogenannte Interest Invokers: Aktionen müssen nicht zwingend durch einen Klick ausgelöst werden.

HTML-in-Canvas.

Mit dem experimentellen Ansatz lassen sich HTML-Inhalte auf ein <canvas> zeichnen und trotzdem interaktiv halten. Coyier nennt es sinngemäß die "überraschendste großartige Neuerung des Jahres". Die Darstellung scheint noch etwas weniger scharf als normales HTML.

Ob daraus ein alltägliches Werkzeug wird, ist offen. Aber das Experiment ist spannend.

Und wie immer: Was nehmen wir uns daraus mit?

1. Regelmäßig auf dem Laufenden bleiben. Was haben wir in der Vergangenheit ins HTML eingebaut, was uns jetzt vielleicht vor die Füße fällt - Siehe noarchive!
2. Was für Neuerungen gibt es? Was kann unser HTML verbessern?
3. Wir müssen auf dem Laufenden bleiben. Dinge ändern sich vielleicht nicht super schnell, aber doch von Zeit zu Zeit.