<portal> Veraltet

Zuletzt aktualisiert am 3. Juli 2026

Das <portal> Element war ein experimenteller Vorschlag für nahtlose Seitenübergänge im Web. Die Idee: Eine Zielseite wird als Live-Vorschau in die aktuelle Seite eingebettet, und per JavaScript wechselt der Browser flüssig dorthin, ohne harten Seitenwechsel mit weißem Ladebildschirm. Aus dem Vorschlag ist nie ein Standard geworden. Chrome hat das Element eine Zeit lang hinter einer experimentellen Flag getestet, den Code aber wieder komplett aus Chromium entfernt. Auch die Spezifikationsarbeit wurde eingestellt. Dieser Artikel dokumentiert <portal> als Stück Web-Geschichte und zeigt dir, was du heute stattdessen nutzt: View Transitions für flüssige Übergänge, Speculation Rules mit Prerendering für schnelle Navigation und <iframe> für reines Einbetten.

Grundlagen

• Nie Standard geworden: <portal> war ein Proposal der Web Incubator Community Group (WICG). Es hat den Sprung in den HTML-Standard nie geschafft und wird laut eigener Aussage der Autoren nicht weiterverfolgt, das Repository ist praktisch archiviert
• Aus Chromium entfernt: Chrome war der einzige Browser, der das Element implementiert hat, und auch dort nur hinter einer experimentellen Flag. Der komplette Portal-Code wurde später aus Chromium entfernt. Das Element funktioniert heute nirgends mehr, auch nicht hinter Flags
• Die Idee: Ein Portal sah aus wie ein <iframe>, hatte aber einen anderen Zweck. Es zeigte eine nicht-interaktive Vorschau der Zielseite und konnte per activate() zur Hauptseite werden. Der Browser tauschte dabei die Seiten flüssig aus, ohne sichtbaren Neuladevorgang
• src-Attribut: Definierte die URL der Seite, die im Portal vorgeladen und als Vorschau angezeigt wurde
• activate()-Methode: JavaScript-Methode auf dem Portal-Element, die den nahtlosen Übergang zur Zielseite auslöste
• Keine Interaktion in der Vorschau: Anders als bei einem iframe konnte man mit dem Inhalt im Portal nicht interagieren, kein Klicken, kein Scrollen. Erst nach der Aktivierung war die Seite bedienbar

Warum ist <portal> gescheitert? Mehrere Gründe kamen zusammen. Außer Chrome hat kein Browser-Hersteller mitgezogen: Mozilla hat die Umsetzung mit offenen Fragen zurückgestellt, von WebKit (Safari) kam nie ein Signal. Dazu wirft eine Live-Vorschau fremder Seiten schwierige Sicherheits- und Datenschutzfragen auf, denn eine Cross-Origin-Seite wird geladen und angezeigt, bevor der Nutzer aktiv dorthin navigiert. Am Ende hat die Plattform die guten Ideen aus dem Portal-Konzept in kleinere, fokussierte Features aufgeteilt: View Transitions übernehmen die flüssigen Übergänge, die Speculation Rules API übernimmt das Vorladen ganzer Seiten, und für spezielle Einbettungs-Szenarien gibt es Fenced Frames.

Syntax (historisch)

<!-- Historisch: funktioniert in keinem Browser mehr -->
<portal src="https://example.com" style="width: 100%; height: 300px;"></portal>

So sah die geplante Syntax aus. Das Portal wurde als Block-Element gerendert und zeigte eine nicht-interaktive Vorschau der angegebenen URL. Heute behandeln Browser <portal> wie jedes unbekannte Element: Es wird ignoriert und hat keinerlei Funktion.

Attribute (historisch)

Die folgenden Attribute waren im Proposal vorgesehen. Sie haben heute in keinem Browser mehr eine Wirkung.

Beispiele

Die historischen Beispiele zeigen, wie Portals gedacht waren. Sie funktionieren in keinem Browser. Danach siehst du die modernen Wege, die dasselbe Problem lösen.

Vorschau mit nahtloser Navigation (historisch)

<!-- Historisch: funktioniert in keinem Browser mehr -->
<portal
  id="mein-portal"
  src="https://example.com/zielseite"
  style="width: 100%; height: 300px; cursor: pointer;">
</portal>

<script>
  const portal = document.getElementById("mein-portal");

  portal.addEventListener("click", () => {
    // Sollte den nahtlosen Übergang zur Zielseite auslösen
    portal.activate();
  });
</script>

Das war der Kern der Portal-Idee: Die Zielseite wird im Hintergrund vollständig geladen, als Vorschau angezeigt und per activate() ohne Ladepause zur aktiven Seite. Genau diese beiden Bausteine, Vorladen und flüssiger Übergang, gibt es heute als getrennte, tatsächlich verfügbare Features.

Moderne Alternative: View Transitions

Die View Transitions API animiert den Wechsel zwischen zwei Zuständen. Innerhalb einer Seite (same-document) startest du eine Transition per JavaScript:

<button id="wechseln">Ansicht wechseln</button>
<main id="inhalt">Alter Inhalt</main>

<script>
  const button = document.getElementById("wechseln");
  const inhalt = document.getElementById("inhalt");

  button.addEventListener("click", () => {
    // Fallback für Browser ohne View Transitions
    if (!document.startViewTransition) {
      inhalt.textContent = "Neuer Inhalt";
      return;
    }

    // Der Browser blendet alten und neuen Zustand weich ineinander
    document.startViewTransition(() => {
      inhalt.textContent = "Neuer Inhalt";
    });
  });
</script>

Für Übergänge zwischen zwei getrennten Seiten derselben Origin (cross-document) brauchst du nicht einmal JavaScript. Ein CSS-Opt-in auf beiden Seiten genügt:

/* Auf beiden beteiligten Seiten einbinden */
@view-transition {
  navigation: auto;
}

Same-document View Transitions werden von allen modernen Browsern unterstützt. Cross-document View Transitions funktionieren in Chrome, Edge und Safari, Firefox arbeitet noch an der Umsetzung. Browser ohne Unterstützung zeigen einfach den normalen, harten Seitenwechsel: Die Seite bleibt voll funktionsfähig.

Moderne Alternative: Speculation Rules und Prerendering

Den zweiten Teil der Portal-Idee, das Vorladen der Zielseite, übernimmt die Speculation Rules API. Du hinterlegst als JSON, welche Seiten der Browser im Hintergrund vorladen oder komplett vorrendern soll:

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": { "href_matches": "/artikel/*" },
        "eagerness": "moderate"
      }
    ]
  }
</script>

Mit prerender lädt und rendert der Browser die Zielseite vollständig im Hintergrund. Klickt der Nutzer den Link, erscheint die Seite praktisch sofort. "eagerness": "moderate" startet das Vorrendern zum Beispiel, sobald der Nutzer mit dem Mauszeiger über dem Link schwebt. Speculation Rules funktionieren in Chromium-Browsern (Chrome, Edge, Opera). Firefox und Safari unterstützen sie nicht, ignorieren den Script-Block aber einfach. Du kannst die Regeln also gefahrlos einbauen, unterstützende Browser werden schneller, alle anderen verhalten sich wie bisher.

Moderne Alternative: iframe für reines Einbetten

Falls du gar keine Navigation brauchst, sondern nur eine andere Seite in deiner Seite anzeigen willst, ist <iframe> das richtige Element. Genau dafür war das Portal nie gedacht:

<iframe
  src="https://example.com"
  width="600"
  height="400"
  title="Eingebettete Beispielseite"
  loading="lazy">
</iframe>

Anders als ein Portal ist der Inhalt eines iframes interaktiv: Der Nutzer kann darin scrollen, klicken und Formulare ausfüllen.

Barrierefreiheit

Da <portal> nie eine stabile Spezifikation erreicht hat, wurden auch die Barrierefreiheits-Patterns nie fertig ausgearbeitet. Offene Fragen wie die Tastatur-Bedienung der Vorschau, die Ankündigung durch Screenreader und die Rolle des Elements im Accessibility-Tree blieben ungeklärt. Das war einer der Kritikpunkte am Vorschlag.

Für barrierefreie Navigation bist du mit den heutigen Mitteln deutlich besser aufgestellt: Normale Links (<a>) sind von Haus aus tastaturbedienbar und werden von Screenreadern korrekt angekündigt. View Transitions und Speculation Rules setzen auf genau diesen Links auf und ändern nichts an deren Zugänglichkeit. Beachte bei View Transitions nur die Nutzerpräferenz prefers-reduced-motion und reduziere die Animationen entsprechend.

Häufige Fehler

Portal-Code aus alten Tutorials übernehmen

<!-- Falsch: funktioniert nirgends, der Browser ignoriert das Element -->
<portal src="https://example.com/zielseite"></portal>

<!-- Richtig: normaler Link, optional mit View Transitions und Prerendering -->
<a href="/zielseite">Zur Zielseite</a>

Im Netz kursieren noch viele Artikel und Demos aus der Experimentierphase von Portals. Dieser Code funktioniert heute in keinem Browser mehr, auch nicht hinter Flags. Der Browser behandelt <portal> wie ein unbekanntes Element ohne Funktion. Nutzer sehen im besten Fall nichts, im schlechtesten Fall einen leeren Bereich ohne den erwarteten Inhalt.

Auf Feature-Detection als Absicherung vertrauen

<script>
  // Läuft nie in den if-Zweig: kein Browser hat HTMLPortalElement
  if ("HTMLPortalElement" in window) {
    // Portal-Logik
  }
</script>

Feature-Detection per "HTMLPortalElement" in window war in alten Demos das übliche Muster. Der Check schadet nicht, aber er ist toter Code: Die Bedingung wird nie wahr, weil die Implementierung aus Chromium entfernt wurde und kein anderer Browser sie je hatte. Solche Code-Pfade kannst du ersatzlos löschen.

portal mit iframe verwechseln

Das Portal sah aus wie ein iframe, war aber als Sprungbrett für Navigation gedacht, nicht zum dauerhaften Einbetten. Wenn du heute Inhalte einbetten willst, verwende <iframe>. Wenn du flüssige Seitenübergänge willst, verwende View Transitions. Wenn du schnelle Navigation willst, verwende Speculation Rules mit Prerendering. Für jede Teilaufgabe des Portals gibt es inzwischen ein passendes, tatsächlich unterstütztes Werkzeug.

Browser-Kompatibilität

Das <portal> Element wird von keinem Browser unterstützt. Chrome hat die experimentelle Implementierung wieder aus Chromium entfernt, alle anderen Browser haben das Element nie umgesetzt. Die Spezifikationsarbeit ist eingestellt.

Verwende <portal> in keinem Projekt mehr. Die Nachfolge-Features View Transitions und Speculation Rules decken die ursprünglichen Anwendungsfälle ab und werden aktiv weiterentwickelt.

Email-Kompatibilität

Das <portal> Element wird von keinem Email-Client unterstützt und wird komplett entfernt oder ignoriert.

Da das Element nicht einmal in Browsern funktioniert, ist die Frage nach Email-Support rein akademisch. Verwende in E-Mails klassische Links (<a>) für Navigation.

Verwandte Elemente