Unsinnige Frames
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.
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 obenDer 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.
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 obenUnschö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.
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:
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 obenProbleme 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.
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.
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 stehen, der Aufbau eines JavaScripts
schlichtweg zu umständlich ist und fortgeschrittene serverseitige Techniken wie
SSI nicht freigegeben sind. 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.