Die Web-Trickkiste

Wählen Sie Ihre Sprache:
Deutsche Flagge
Britische FlaggeAmerikanische Flagge
Französische Flagge
Tschechische Flagge
Wohin möchten Sie?
  • Inhaltsverzeichnis
  • Startseite
  • Die Wahl des Dokumenttyps
    • Der MIME-Typ
    • Die Dokumenttypdeklaration
  • Barrierefreiheit
    • Weshalb das Ganze?
    • Dokumenttypen
    • Barrierefreies Layout
      • Farbschemata
      • Der Dalton-Modus
      • Schriftarten
      • Schriftgrößen
      • Keine Sitzung notwendig!
    • Vereinfachte Sprache
      • Zu komplex – und jetzt?
      • Ein besseres Verständnis herbeiführen
      • Fördern und fordern
      • Umsetzung
    • Barrierefreie Bedienbarkeit
      • Tastaturunterstützung
    • Probleme mit der Barrierefreiheit
      • Graphiken
      • Flash
      • Formulierung
    • ARIA
      • Elemente und ihre Rollen
      • Rollen definieren
      • Zustände der Elemente
    • Formulare
      • Kenntlichmachung
      • Pflichtfelder
      • Rückmeldungen
  • Kampf dem Spam!
    • Captchas – wirklich notwendig?
    • Spamfreies Gästebuch
      • Wie MySQL helfen kann
      • Wie Schwarze Listen helfen können
      • Spamfallen auslegen
      • Inhaltsanalyse
      • Wie Gästebuchmoderation hilft
      • Zu guter Letzt: Die Bestätigungsmail
    • Spamresistente Webstatistiken
  • Apache aufgebohrt
    • Power-Logging
    • MIME-Typen festlegen
    • Fehlerdokumente im Eigenbau
      • Weshalb überhaupt selber machen?
      • Das eigene Fehlerdokumente-Verzeichnis
      • Die Fehlerdokumente registrieren
      • Neue Fehlerdokumente erstellen
    • Virtuelle Hosts einrichten
    • Der Deppenstopp
      • Was geht denn da vor sich?
      • Unerwünschte Zugriffe sperren
      • Datenmüll aus den Logs fernhalten
      • Referrerspam unterbinden
      • Den Deppen die eigene Medizin verabreichen
      • Selektive Sperren einrichten
      • Fallen für Webscraper
    • SSI
      • Was sind SSI?
      • SSI aktivieren
      • Gemeinsame Elemente vordefinieren
      • Dynamische Inhalte ohne CGI
        • Dynamische Navigation
        • Das zentrale Menü
        • Die Sprachauswahl
        • Zeitpunkt der letzten Veränderung anzeigen
    • Sicherheit
      • SSL
        • Grundlagen
        • Zertifikate beschaffen
        • Sicherheitsrisiken
        • SSL aufgebohrt
        • Weg mit SSL, TLSv1.0 und TLSv1.1!
        • Strict Transport Security
        • Private Key Pinning
        • Certificate Authority Authorization
      • Ursprungsbeschränkungen
      • Einbetten in Frames verhindern
      • CORS
        • Inhalte mit anderem Ursprung
        • Hotlinking
        • Ursprünge überprüfen
        • Mehrere zulässige Ursprünge
      • Referrer-Policy
  • Webseiten für Smartphones
    • Gründe für die Anpassung
    • Anpassung des Viewports
    • Probleme mit der Navigation
    • Elementgrößen
    • Umgang mit übergroßem Inhalt
    • Ein responsives Design aufbauen
    • Gesondertes Layout für Mobilgeräte
  • XHTML
    • XHTML und HTML im Vergleich
    • Grundlagen
    • Das Grundgerüst
    • Probleme
    • Irrglauben
  • CSS
    • Grundlagen
    • Das Box-Modell
    • Das Seitenlayout definieren
      • Grundlegende Stile
      • Selektoren
      • Kombinatoren
      • Eigenschaften
        • Textstile
        • Textformate
        • Textausrichtung
        • Boxen
        • Positionierung
        • Anzeige
        • Der Hintergrund
        • Animationen
      • Pseudoelemente und -klassen
    • Ein Basislayout erstellen
    • Browserweichen
    • Druckerfreundliches Layout
    • Stilauswahl
      • CSS und Skripte
      • CSS und CGI
      • Farbauswahl
      • Schriftgrößen
      • Schriftarten
      • Skins
  • JavaScript
    • Grundlagen
      • Aufbau
      • Der strikte Modus
      • Einbindung
      • Verzögerte Ausführung
      • Fehlerbehandlung
    • Das Document Object Model
    • Module
      • Grundlegende Probleme mit JavaScript
      • Gültigkeitsbereich und Namensraum
      • Kapselung
      • Objektorientierte Programmierung
    • AJAX
      • XMLHttpRequest
      • CORS
      • Skriptinitialisierung
    • Anwendungen
      • Tooltips
      • Länderauswahl
      • Kontextmenüs
      • Fehlermeldung
      • Dynamische Hilfeseiten
      • Menüsteuerung per Tastatur
      • Debughilfen
    • Gimmicks
      • Fenstergröße anzeigen
      • Knopf zum Drucken anbieten
      • Verweise in einem neuen Fenster öffnen
    • Erweiterungen
      • XHTML: document.write() dem DOM hinzufügen
      • Cookies setzen, auslesen und löschen
      • Metadaten auslesen
      • Modale Elemente
    • Unterstützende Techniken
      • Die Dokumenttypweiche
      • Inhaltsumschalter
    • API-Programmierung
      • Sicherheitsaspekte
      • Zuverlässigkeit
  • Unsinnige Frames
  • Cookies
    • Definition
    • Einsatzgebiete
    • Datenschutztechnische Bedenken
    • Sicherheitsaspekte
  • Steueroberfläche im Eigenbau
    • Überblick über die laufenden Dienste
    • Webserverkontrolle
    • Crontab-Editor
    • Virtuelle Maschinen steuern
  • Glossar
    A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

© 2013 - 2021 by Olaf Martens

Impressum
Datenschutz
Haftungsausschluß

Gültiges XHTML 1.1 + ARIACSS ist gültig
Seite drucken

Flattr-Button

Meine IP-Adresse sperren
  • Neuigkeiten
  • Kontakt
    • Gästebuch
    • Forum
  • Dienste
    • RSA-Schlüssel für SSH
    • Anforderung für SSL-Zertifikat
    • Domainnamen auflösen
    • Eine virtuelle Maschine definieren
    • Fingerabdrücke von Zertifikaten
    • Fehlerhaftes HTML bereinigen
  • FAQ
  • Sitemap
  • Unterstützung

Unsinnige Frames

  • Das Problem mit der Dokumentgliederung
  • Das Frameset
  • Der iframe
  • Probleme mit der Implementierung
  • Unschöne Begleiterscheinungen
  • Der Schaufenstereffekt
  • Probleme mit der Handhabung
  • Problematische Eigenheiten des iframe
  • Fazit

Das Problem mit der Dokumentgliederung

Jeder, der sich mit HTML befaßt, kennt dieses Problem sicherlich zu Genüge: Wie strukturiert man ein Dokument und – viel wichtiger – wie setzt man das in HTML um?
Diese Frage stellt sich spätestens seit CSS 2 nicht mehr, da man seit dieser Version die Position von Elementen nach eigenem Gutdünken festlegen kann. Davon wird beispielsweise auf diesen Seiten intensiv Gebrauch gemacht, so daß sich eine klar erkennbare logische Untergliederung einer jeden Seite in den Kopfbereich, die Navigationsleiste nebst sonstiger Angaben sowie den eigentlichen Dokumenttext ergibt. Eine Untergliederung ist alleine deshalb schon erforderlich, damit es nicht aussieht wie Kraut und Rüben und gleichzeitig eine einfache Handhabung gewährleistet ist.
Vor CSS 2 hatte sich jedoch das Problem ergeben, daß man die einzelnen Elemente zwar umgestalten konnte, doch ließ sich das Layout des Dokuments so noch nicht ändern. Um hier also eine Untergliederung eines Dokumentes zu erreichen, wurden schließlich Frames eingeführt. Diese erlauben es, ein Dokument so in mehrere Teile zu zerlegen, daß das, was bestehen bleiben sollte, auch tatsächlich bestehen blieb, und nur der Teil, der sich ändern sollte, wurde neu geladen.

nach oben

Das Frameset

Hiermit läßt sich ein Fenster in mehrere Untereinheiten untergliedern, die wiederum verschiedenen Zwecken dienen können. So kann man z. B. links eine Navigationsleiste anlegen, über die die verschiedenen Seiten einer Domain aufgerufen werden können, oder aber man definiert auch noch eine Kopfzeile hinzu, die wiederum ein zentrales Menü enthalten kann. Allerdings sind auch andere Varianten denkbar, z. B. die Anlage einer Fußzeile, in der Sie Verweise z. B. auf die Nutzungsbedingungen Ihrer Domain, auf das Impressum, etc. unterbringen können.

Um ein Frameset zu definieren, ist es erforderlich, ein übergeordnetes Dokument zu erstellen, das die einzelnen Frames definiert und festlegt, was in diese zu laden ist. Leider ist es nicht möglich, in einem Frame das HTML direkt zu notieren, sondern es müssen Dateien angegeben werden, die dann von dem übergeordneten Dokument nachgeladen werden.
Der Dokumenttyp für die übergeordnete Datei sollte dazu HTML 4.01 Frameset oder XHTML 1.0 Frameset sein. Für die nachgeladenen Dokumente können beliebige Dokumenttypen angegeben werden, obwohl HTML 4.01 Transitional oder XHTML 1.0 Transitional zu bevorzugen wären, da diese über ein paar Möglichkeiten verfügen, auf das Frameset, das sie geladen hat, zuzugreifen.

Leider ist der Einsatz von Frames nicht ganz unproblematisch, und man wird sehr schnell auf einige teils erhebliche Probleme stoßen, die sich zudem nicht so einfach beheben lassen, weshalb deren Einsatz vermieden werden sollte.

nach oben

Der iframe

Der iframe erfüllt letztlich einen ähnlichen Zweck wie ein normaler Frame, doch handelt es sich bei ihm um ein Inline-Element, das in einem normalen Dokument notiert wird und so zusätzliche Inhalte nachlädt. Hierzu ist es erforderlich, einen der Dokumenttypen HTML 4.01 Transitional, HTML 4.01 Frameset, XHTML 1.0 Transitional, XHTML 1.0 Frameset oder (X)HTML5 anzugeben, um den iframe nutzen zu können. Allerdings ergeben sich auch hier einige unschöne Probleme, die sich nicht so leicht lösen lassen, wenn man auf diese Technik zurückgreift, weshalb sie i. d. R. vermieden werden sollte, auch wenn der iframe in (X)HTML5 aufgenommen worden ist.
Darüber hinaus verfügt der iframe über einige Eigenheiten, die ihn noch problematischer als das normale Frameset machen.

nach oben

Probleme mit der Implementierung

Das Hauptproblem, das sich beim Einsatz von Frames ergibt, ist die Tatsache, daß man ein Dokument, das auf diesem Wege gegliedert werden soll, in mehrere Teile zerlegen muß. Diese sind dann wiederum als eigenständige Dokumente in die definierten Frames zu laden, wodurch sich letztlich keine rein logische, sondern eine tatsächliche Unterteilung des Dokuments ergibt. Jeder Frame stellt, wie ein Fenster auch, einen eigenen Viewport dar, der von den anderen Frames völlig unabhängig angesprochen werden kann. Dadurch wiederum ergeben sich einige Beschränkungen, da man aus einem Frame heraus ohne Zuhilfenahme von JavaScript nicht auf die anderen Frames zugreifen kann. Wenn man also ein Dokument in einem der Frames nachlädt und dies Auswirkungen auf andere definierte Frames haben soll, so ist es nicht möglich, dies mit reinem HTML zu bewerkstelligen.

Zudem sind Sie gezwungen, Ihre Seiten so zu gestalten, daß Sie sie auf ein Frameset aufspalten können. Zwar mag dies mit vielen Seitenschemata hervorragend funktionieren, doch sowie Sie speziellere Layouts benötigen, stoßen Frames wiederum an ihre Grenzen.

nach oben

Unschöne Begleiterscheinungen

Wenn Sie ein Frameset oder einen iframe einsetzen, so werden Sie sehr schnell feststellen, daß Sie mit einigen Problemen konfrontiert werden, die Sie ohne Frames nicht gehabt hätten. Da Sie das Browserfenster mit einem Frameset letztlich in mehrere Teile zerlegen, ist es nicht ganz so einfach, hier gestalterisch tätig zu werden. Dies ist bei einfachen Layouts noch kein Thema, aber sowie Sie beispielsweise Hintergrundgraphiken einbinden wollen, wird es schwierig: Sie müssen sie für jeden Frame einzeln einbinden. Dazu ist es jedoch erforderlich, daß Sie die geplante Hintergrundgraphik in mehrere Teile zerlegen und diese nach ihrer Position in die jeweiligen Frames einbinden. Dies stellt auf den ersten Blick kein Problem dar, da die Dimensionen Ihrer Frames bekannt sind und Sie so mit einem Bildbearbeitungsprogramm pixelgenau schneiden können, so daß die Zerlegung optisch nicht auffällt. Auf den zweiten Blick hingegen ergeben sich diverse Fallstricke: Werden die Maße der Frames verändert, so gerät Ihr sorgfältig geplantes Layout komplett durcheinander. Das zweite Problem entsteht, wenn Sie im Dokument zwar festlegen, daß der Inhalt der Frames nicht gescrollt werden darf, Ihre Nutzer im Browser jedoch festlegen, daß Inhalte von Frames gescrollt werden dürfen, egal was von einer Webseite vorgegeben wird – bis hin dazu, daß das Frameset durch die Anzeige von Scrollbalken gesprengt wird. In diesem Fall zerfällt die optische Einheit des Dokuments, wodurch es unansehnlich wird.
Diesem Problem ließe sich begegnen, indem man die einzelnen Frames so gestaltet, daß jeder Bereich klar gegen die anderen Bereiche abgegrenzt ist und diese Aufteilung somit nicht vor Ihren Nutzern versteckt wird. Doch selbst dann ist die Benutzbarkeit der Seite höchstens suboptimal.

nach oben

Der Schaufenstereffekt

Das Hauptproblem, das sich mit Frames ergibt, ist, daß man sie einsetzen kann, um fremde Dokumente so in die eigenen Seiten einzubinden, daß sie als Teil des eigenen Webprojektes erscheinen. Ein normaler Nutzer kann schließlich nicht so einfach feststellen, daß hier auf eine vollkommen andere Seite verwiesen wird, wenn er sich nicht die Mühe macht, den Quellcode der Seite zu analysieren, und könnte sehr schnell zu der Überzeugung kommen, daß das, was in Ihrem Frame angezeigt wird, tatsächlich zu Ihrem Webprojekt gehört.
Hier wäre es erforderlich, entweder die Nutzer darauf hinzuweisen, daß der Inhalt des Frames von einer anderen Seite als der Ihren stammt, oder aber dafür zu sorgen, daß das Frameset beim Aufruf externer Verweise entfernt wird, so daß die Zielseite das ganze Browserfenster zur Verfügung hat. Leider wird dies, oftmals aus Unwissenheit, verabsäumt, was zu dem bereits benannten Schaufenstereffekt führt.
Besonders schlimm wird es, wenn die Zielseite ihrerseits Frames definiert, da dann der Frame, in den sie geladen wird, ebenfalls durch ein Frameset unterteilt wird. Durch dieses Frameset innerhalb eines Frames wird der Bereich, in dem weitere Seiten nachgeladen werden, zusehends kleiner, so daß die nachgeladenen Seiten irgendwann nicht mehr benutzt werden können.

Leider gibt es auch einige schwarze Schafe, die sich diesen Effekt ganz bewußt zu Nutze machen, um sich mit fremden Federn zu schmücken, da sie nichtsahnenden Besuchern so vorgaukeln, als stammte das eingebundene Dokument von ihnen. Dies ist nicht nur extrem unfair gegenüber dem Autor der Seite, die auf diese Art und Weise „einverleibt“ wird, sondern kann im Bedarfsfalle Ärger nach sich ziehen.

Aus diesen Gründen findet sich in HTML-Dokumenten oftmals folgender Code:

<script type="application/javascript"> /* <![CDATA[ */ if(self.location != top.location) top.location = self.location; /* ]]> */ </script>

Dadurch sorgt das nachgeladene Dokument dafür, daß das Frameset oder der iframe, in das das Dokument geladen wird, gesprengt wird und das Zieldokument als einziges im Browserfenster steht. Dadurch wird der Schaufenstereffekt auf einfache Art und Weise unterbunden, und selbst Nachlässigkeit seitens desjenigen, der auf eine andere Seite verweist, stellt kein Problem mehr dar.

nach oben

Probleme mit der Handhabung

Aber auch die Bedienbarkeit einer Seite leidet darunter. Wenn Sie z. B. mittels der Tabulatortaste zwischen den Verweisen umschalten, so ergeben sich Probleme, wenn z. B. die Navigation in einem eigenen Frame untergebracht worden ist, da diese nicht mehr erreicht wird, es sei denn, daß Sie in den Frame klicken, der die Navigationsleiste enthält. Dann jedoch können Sie nicht mehr zwischen den Verweisen im eigentlichen Dokument hin- und herschalten, ohne dessen Frame wieder anzuklicken. Zudem ergeben sich mit einem Frameset unweigerlich Probleme mit der Barrierefreiheit, da Screenreader und Braillezeilen i. d. R. nicht darauf ausgelegt sind, daß Webseiten auf diese Art und Weise in mehrere Teile zerlegt werden.

Ein anderes Problem ergibt sich, wenn Ihre Seiten von einer Suchmaschine indiziert werden, da diese i. d. R. nicht das übergeordnete Frameset in ihren Suchergebnissen zurückliefern, sondern die Zielseite, die zu Ihrer Suchanfrage paßt. Wenn Sie diese jedoch aufrufen, so stehen Sie sehr schnell vor dem Problem, daß Sie ggf. ohne Navigation dastehen, wenn diese auf der aufgerufenen Seite in einem eigenständigen Frame untergebracht ist. Das Frameset nachzuladen und die aufgerufene Seite darin anzuzeigen, wäre nur mit einem erheblichen Aufwand möglich.
Und selbst wenn eine Navigation zu sehen ist, so ergeben sich zwangsläufig andere Probleme. Da ein Frame nur sehr bedingt auf das Geschehen innerhalb eines anderen Frames reagieren kann – wenn überhaupt, dann ist ein erheblicher Aufwand zu betreiben, zumal es ohne JavaScript ohnehin nicht funktioniert – ist die eingebundene Navigation i. d. R. statisch, so daß der Verweis auf die aktuelle Seite aktiv bleibt, obwohl dies nicht der Fall sein sollte. Hier müßte man die ganze Verweisliste abgrasen und sämtliche Verweise zunächst einmal reaktivieren, um anschließend den Verweis, der auf die nachgeladene Seite zeigt, wieder zu deaktivieren, damit man das aktuelle Dokument nicht erneut aufrufen kann. Hier ist es empfehlenswert, auf andere Techniken, z. B. SSI, auszuweichen, mit denen man diese Probleme wesentlich einfacher vermeiden kann.

Aber auch wenn Sie ein Lesezeichen setzen wollen, ergeben sich Probleme: Sie werden statt der gerade angezeigten Seite grundsätzlich das übergeordnete Frameset als Lesezeichen ablegen, wodurch Sie die Seite mit ihren Grundeinstellungen (also der Seite, die das Frameset anfangs lädt) geladen wird und Sie erst einmal das von Ihnen gewünschte Dokument anklicken müßten. Dies jedoch sorgt sehr schnell für Verdruß beim Benutzer, der sich so mit überflüssigen Aktionen traktiert sieht und somit auch schnell entscheiden könnte, die Seite zu verlassen.
Das gleiche Problem ergibt sich, wenn man sich einmal die Adreßzeile des Browserfensters, in das ein Frameset geladen worden ist, anschaut. Hier steht grundsätzlich die Adresse des übergeordneten Framesets; die nachgeladenen Dokumente treten hier überhaupt nicht als solche in Erscheinung. Dies ist genau das Verhalten, das den Schaufenstereffekt begünstigt.

Um Probleme gleich im Vorwege zu vermeiden, sollten Sie nach Möglichkeit auf serverseitige Technologien wie CSS, Skriptsprachen und SSI zurückgreifen, über die Sie bestimmte Teile in Ihr Dokument einbinden, ohne es in Teildokumente zerlegen zu müssen. Die Seiten auf dieser Domain beispielsweise machen intensiven Gebrauch von solchen Techniken; so wird das Menü links oben von einem Perlskript erstellt, das mittels SSI aufgerufen wird und an der Stelle im Dokument, an der der Aufruf notiert ist, den für die Navigation notwendigen XHTML-Code ausgibt. Der Vorteil solcher Techniken gegenüber Frames liegt klar auf der Hand: Sie können innerhalb der Skripte noch einige Überprüfungen vornehmen, z. B. ob die Zieldatei eines Verweises überhaupt vorhanden ist, und die betroffenen Verweise dann deaktivieren. Sie brauchen dann nicht jedesmal etwas am Menü zu ändern oder zig Dokumente zu durchforsten, wenn Sie eine Datei in Ihr Webprojekt einfügen, und dabei Gefahr laufen, daß Sie irgendetwas übersehen. Zudem behält das dargestellte Dokument seine physische Integrität.
So ließe sich diese Seite, die Sie gerade betrachten, sicherlich auch unter Zuhilfenahme von Frames aufbauen, da das Seitenlayout dies ermöglicht, doch wie bereits beschrieben, ergäben sich in dem Fall diverse Probleme, die es in ihrer aktuellen Form nicht gibt.

nach oben

Problematische Eigenheiten des iframe

Beim Einsatz von Frames gestaltet sich der iframe deutlich problematischer als das normale Frameset, weil man diesen in einem HTML-Dokument ganz einfach verschwinden lassen kann. Dazu braucht dem iframe lediglich das style-Attribut mitgegeben werden, das einzig display: none; als Wert enthält, und schon wird der iframe nicht mehr angezeigt. Das Dokument, das einen so versteckten iframe enthält, erscheint ganz normal, so daß ein nichtsahnender Benutzer nicht einmal vermutet, daß sich noch etwas in dem Dokument verbirgt. Hier müßte man schon den Quellcode betrachten, um derart versteckte Elemente zu sehen.
Ein derart versteckter Frame kann beispielsweise dazu mißbraucht werden, um fremdes JavaScript nachzuladen, das dann weitere Aktionen im Kontext des Dokuments, das den iframe enthält, ausführt. Dieses Verhalten wird teilweise von Cyberkriminellen ausgenutzt, die einem nichtsahnenden Nutzer Schadcode unterschieben, der von diesem vollkommen unbemerkt ausgeführt wird. Als besonders übel erweist sich das Problem, wenn der ausliefernde Webserver durch eine modifizierte Variante ersetzt wird, der beim Anfordern von Webseiten einfach einen iframe in den eigentlichen HTML-Code injiziert und den so modifizierten HTML-Code an den Aufrufer übergibt. Auf diesem Wege ist es nicht mehr erforderlich, die HTML-Dokumente einer Website zu modifizieren, was serverseitig zu einer deutlichen Reduktion von verräterischen Spuren führt. Erstmalig ist dieses Problem, besser bekannt als Linux/Cdorked.A in Form eines modifizierten Apache, Ende 2012 bis Anfang 2013 aufgetaucht, doch mittlerweile gibt es solche modifizierten Versionen auch für andere Webserver.
Gerade hier zeigt sich das Mißbrauchspotential versteckter iframes sehr deutlich. Zwar ließen sich auf ähnlichem Wege sicherlich auch normale Frames verstecken, doch ist es weitaus umständlicher, Nutzern auf diesem Wege Schadcode unterzuschieben, da man entweder ein bestehendes Frameset verändern müßte, was wiederum eine lexikalische Analyse des aufgerufenen Dokuments erfordert, oder aber man müßte überhaupt erst einmal ein Frameset aufbauen, das einen versteckten Frame anlegt. Dies kann aber Probleme verursachen, wenn die verwendete HTML-Variante keine Framesets unterstützt, wie es beispielsweise bei diesen Seiten der Fall ist. So unterstützt XHTML 1.1 keine Frames, und diese können auch nicht einfach mittels JavaScript angelegt werden, da der zugehörige Knoten im DOM fehlt. Eine Injektion von normalen Frames oder auch iframes funktioniert damit nicht, weil der Browser das Dokument schlichtweg nicht darstellen und stattdessen einen Fehler ausgeben wird.

nach oben

Fazit

Wie man es auch dreht und wendet, Frames egal welcher Art bereiten mehr Probleme, als daß sie Nutzen brächten. Zugegeben, zu der Zeit, als Frames eingeführt wurden – aber auch heute noch bei einigen Anbietern von kostenlosem Webspace – waren diese die einzige Möglichkeit, überhaupt eine feste Navigation aufzubauen, da CSS noch nicht so weit entwickelt war wie heutzutage, dazu meist keine Skriptsprachen zur Verfügung standen, der Aufbau eines JavaScripts schlichtweg zu umständlich war und fortgeschrittene serverseitige Techniken wie SSI nicht freigegeben waren. Doch mit einem vernünftig konfigurierten Webspace, der einem diese Möglichkeiten bietet, gibt es wesentlich bessere Methoden, um ein Dokument zu gliedern, ohne daß man es in mehrere Teile zerlegen müßte und so den logischen Bezug der einzelnen Teildokumente zueinander verliert.
So läßt sich eine Navigationsleiste ganz einfach mittels SSI einbinden, und mit einem sinnvoll geschriebenen Skript ist es sogar möglich, die Navigation in Abhängigkeit von der aufrufenden Datei derart aufzubauen, daß z. B. das aktuelle Dokument nicht noch einmal aufgerufen werden kann und in der Navigation speziell hervorgehoben wird. Dazu kann man mittels CSS das Dokument logisch so gestalten, daß man am Kopf und auf einer Seite einen kleinen Teil für den Titel und die Navigation abzweigt, den Rest aber für den eigentlichen Dokumenttext bereitstellt.
Da das Dokument lediglich rein optisch in mehrere Teile untergliedert ist, aber ansonsten seine Integrität behält, ist zudem wieder die Barrierefreiheit gegeben, da Screenreader und Braillezeilen das Dokument so problemlos verarbeiten und die Informationen extrahieren können. Weiterhin kann die Navigation nicht verlorengehen, wenn Sie über eine Suchmaschine auf eine solche Seite geleitet werden, da diese ein integraler Bestandteil davon ist, und zu guter Letzt läßt sich auf einfache Art und Weise auch JavaScript entwerfen, das mit allen Teilen eines Dokuments arbeiten kann. Der Umweg über die Elementknoten der einzelnen Frames entfällt so, und das JavaScript muß nicht umständlich ermitteln, womit es in anderen Frames zu tun bekommt.
Einzig ein iframe läßt sich einigermaßen sinnvoll einsetzen, um bestimmte Elemente aus anderen Domains in die eigenen Dokumente einzubinden. Dieser Weg wird beispielsweise von Facebook und Google beschritten, damit verschiedene Schaltflächen in die eigenen Dokumente eingebunden werden können, aber auch Paypal und andere Dienste, so auch zahlreiche Anbieter von Captchas, stellen Elemente bereit, die auf diese Art und Weise einzubinden sind. Allerdings erfordert dies zwingend einen Dokumenttyp, der den iframe bereitstellt, da Verschiedenes sonst überhaupt nicht funktioniert. Hier wären dann andere, deutlich sauberere, Lösungen erforderlich, insbesondere wenn Dokumenttypen Verwendung finden, die diesen nicht definieren, doch leider scheuen zahlreiche Entwickler den damit verbundenen Mehraufwand.

nach oben