Probleme mit FRAMEs

Inhalt

Frames, nur ein Problem alter Browser?

Seit ihrer Einführung mit dem Netscape Navigator 2 ist die Verwendung von Frames umstritten.

Zu Anfang waren die Hauptargumente, dass zuviele Browser die neue Technologie nicht unterstützten und dass Besucher mit älteren Browsern viel zu oft lesen mussten Your Browser doesn't support frames, get Netscape Navigator!

Das wäre von vorne herein nicht nötig gewesen. In den NOFRAMES-Teil eines Framesets gehört keine Beschimpfung der Kunden a la Mit Deinem ollen Programm kommst Du hier nicht rein, hol Dir erst mal anständige Software und komm dann wieder!, sondern ein Text mit Links, die die Inhalte der Site auch ohne Frames zugänglich machen.

Angesichts der heutigen Verbreitung von grafischen Browsern, die Frames anzeigen, wäre es übertrieben, alle Seiten in einer framelosen Alternativversion vorzuhalten. Das würde den Pflegeaufwand für das Projekt fast verdoppeln oder die NOFRAMES-Version würde schnell veralten. Ein Link auf die (sowieso vorhandene) Navigationsseite genügt in vielen Fällen (aber er sollte auf keinen Fall fehlen!). Für die wenigen User, die Frames nicht benutzen, halte ich es auch für zumutbar, dass sie mit dem Back-Button des Browsers immer wieder zu dieser Navigationsseite zurückgehen müssen (als Beispiel eine Site, die ich betreue: BUH e.V.).

Seit 1997 ist mit der Verabschiedung von HTML 4.0 die FRAME-Technik auch offizieller Teil der HTML-"recommendations" des World Wide Web Consortiums (W3C), das dafür einen eigenen Typ von HTML-Dokumenten eingeführt hat: HTML 4.0 Frameset.

Man sollte meinen, damit seien alle Vorbehalte ausgeräumt und der Verwendung von Frames stehe nichts mehr entgegen. Das ist leider nicht der Fall. Die eigentlichen Probleme mit Frames bestehen nach wie vor, angesichts der Weiterentwicklung des Webs teilweise noch in verschärfter Form.

Das ist ein interessantes Thema, oder? Dazu muss man etwas weiter ausholen, deshalb gibt es hier eine kurze Abhandlung über Frames. Danach sind sicherlich einige Dinge klarer, vielleicht bewirkt dieser Beitrag ja auch etwas.
Ganz an das Ende habe ich einige Links zum Weiterlesen gesetzt. Wer sich also so richtig in das Thema reinknien möchte, kann sich im Netz weiter darüber informieren. Selbstverständlich kann man viele dieser Infos auch in den entsprechenden Zeitschriften nachlesen (beispielsweise in den einschlägigen Computerzeitschriften, die man auch recht einfach im Abo bekommen kann). Das hat natürlich den Vorteil, dass man auch über andere Themen, die einen Computerfreak interessieren, informiert wird.
Wie auch immer, ihr werdet schon wissen, wie ihr eure Informationen bekommt. Jetzt aber zurück zum Thema.

Das Konzept ist unelegant

Mit HTML 4.0 wurde wieder mehr Wert auf die Trennung von Inhalt und Präsentation eines HTML-formatierten Textes gelegt. Im HTML-Code sollten nur Elemente verwendet werden, die etwas über die Bedeutung und die Struktur des Textes aussagen.

Eine FRAMESET-Datei hat dagegen überhaupt keinen Inhalt (der NOFRAMES-Bereich wird von einem FRAMEs-fähigen Browser völlig ignoriert)!
Sie macht ausschliesslich Angaben über die grafische Präsentation anderer Dokumente. Für andere Ausgabemedien als für die hochauflösende Bildschirmdarstellung hat das Frameset keine Bedeutung.

Auf den ersten Blick erscheint das als philosophisches Problem von Struktur-Dogmatikern, wir werden aber sehen, dass dies die Ursache aller weiteren Probleme ist.

Das FRAMESET ist ein toter Container, der nichts von seinen Inhalten weiß.

Skalierung

HTML-Browser sind selbstständig in der Lage, den Inhalt eines Dokumentes dem Anzeigemedium entsprechend optimal darzustellen. Ist das der Bildschirm eines grafischen Betriebssystems, wird der Zeilenumbruch an die Fenstergrösse angepasst, alle Seitenelemente werden so angeordnet, dass sie gut auf die Anzeigefläche passen.

Der HTML-Autor kann sich nie sicher sein, welche Browserfenster-Grösse seine User bevorzugen, welche Schriften in ihrem System vorhanden sind und welche Schriftgrösse er eingestellt hat. Muss er auch nicht, denn HTML beschreibt nicht das Aussehen einer Seite, sondern den Inhalt und die Struktur der Information. Um den Rest kümmert sich der Browser.

Dem Anfänger erscheint das bedrohlich und die geistige Unflexibilität mancher papiergewohnter Designer führt zu absurden Ansätzen, grosse Teile des Textes als Grafiken einzusetzen oder die Grösse von Tabellen grundsätzlich pixelgenau festzulegen. Dabei ist die Fähigkeit zur Selbstskalierung die wahre Stärke von HTML!

Wer das nicht nachvollziehen kann, möge versuchen, auf einem Monitor mit geringer Auflösung lange PDF-Dokumente zu lesen. Entweder die Schrift wird unleserlich klein oder man muss andauernd horizontal scrollen, um eine Zeile von vorne bis hinten lesen zu können. Eine typographisch exakte Festlegung von Schrift, Anordnung und Zeilenumbruch ist nur sinnvoll, wenn das Ausgabemedium (z.B. Druck auf A4-Papier) bekannt ist. Für das WWW taugt sie nicht viel.

Die Definition des FRAMESETs erfordert die Angabe von festen Teil-Fenstergrössen. Weder die Angabe in Pixeln noch in % nimmt irgendwie Rücksicht auf den Inhalt der anzuzeigenden Seiten.

Wer mal eine Seite mit Frames auf verschiedenen Computersystemen getestet hat, kennt das Problem: Auf dem einen sieht ein FRAME leer aus, auf dem anderen passt der Inhalt nicht in die gesetzten Grenzen, hässliche und platzverschwendende Scrollbars sind die Folge. Das mit dem Attribut SCROLLING="no" zu unterdrücken, kann dazu führen, dass Bereiche der Site gar nicht mehr erreichbar sind.

Verschiedene Schriftgrössen bei verschiedenen Benutzern sind keine Browserfehler, das ist ein Grundprinzip der HTML-Darstellung!

Diese Unflexibilität verdirbt einem schnell die Freude an Frames. Ein workaround ist, ganz auf Text zu verzichten und die schmalen Frames nur mit Grafiken zu füllen. Alleine der Aufwand, für einfachen Text Grafiken zu erzeugen, frisst schnell die durch Frames erhoffte Arbeitserleichterung auf. Bandbreitenverschwendung und längere Ladezeiten kommen dazu.

Umgang mit URIs

Normalerweise zeigt ein Browserfenster ein HTML-Dokument an. Dessen absolute Adresse im Internet (der Unified Resource Identifier URI) wird in der Adresszeile des Browsers angezeigt. Bei der Verwendung von Frames funktioniert das nicht mehr. Angezeigt wird immer der URI des Frame-Dokuments, nicht der des Hauptdokuments, das der Benutzer gerade liest. Dies erschwert die Orientierung im Web.

Manchen erscheint das sogar wünschenswert, mit dem Argument:
Wozu sollen sich die User mit meiner Ordnerhierarchie beschäftigen, für die Orientierung ist doch der Navigationsframe und die Überschriften der Einzeltexte da...

Diese Haltung vergisst zwei grundlegende Techniken der Orientierung im Netz: Das Setzen von Bookmarks ("Lesezeichen"), um später zu einer Fundstelle zurückzukommen und das referenzieren fremder Texte durch Hyperlinks. Das Problem ist das selbe.

Hier ein Beispiel:

An der FH Hildesheim/Holzminden/Göttingen gibt es die "Stelle für Wissens- und Technologietransfer". Angenommen ich schreibe an einer Seite über die Möglichkeiten der Zusammenarbeit von Wirtschaft und Hochschulen und möchte für jede Hochschule einen Link zu der zuständigen Kontaktstelle setzen. Dafür gibt es jetzt 2 Möglichkeiten:

  1. Ich setze den Link auf die Frames-Definition der FH, also auf die Adresse, die mein Browser anzeigt, wenn ich von der FH-Seite aus zur Technologietransferstelle komme:

    Eine eigene Stelle für Wissens- und Technologietransfer hat die FH Hildesheim/Holzminden/Göttingen eingerichtet.

    Ein interessierter Firmenvertreter kommt auf die Seite, sieht aber nichts von der Technologietransferstelle, sondern die FH-Homepage. Ob er die Geduld hat, zu suchen und darauf kommt, dass sie sich unter "zentrale Einrichtungen" verbirgt?
  2. Ich erkenne das Problem, öffne über das Kontextmenü des Browsers die Framesseite einzeln und gebe deren Adresse an:

    Eine eigene Stelle für Wissens- und Technologietransfer hat die FH Hildesheim/Holzminden/Göttingen eingerichtet.

    Der Firmenvertreter folgt meinem Link, findet direkt die Aufgaben der TT-Stelle und die Adresse und Telefonnummer des zuständigen Professors, aber dann will er auch noch sehen, ob sich die Hochschule von ihren Schwerpunkten her als Partnerin seines Unternehmens eignet. Aber - wo ist die Hochschule? Die Technologietransferstelle bietet zwar Links zu anderen Hochschulen, nicht jedoch zur eigenen.

In beiden Fällen geht der Wirtschaftsmann zurück zu meiner Linkseite und schaut lieber nach einem anderen Partner, bei dem er sowohl Zuständigkeit als auch Zusammenhang auf einen Blick finden kann.

Anderer Fall: Der Firmenvertreter kennt meine (fiktive) Linkliste nicht, sondern sucht seine Ansprechpartner von der Startseite der Hochschulen aus selber. Er findet auch die TT-Stelle und drückt strg-D um die Seite später wiederzufinden. Nachdem er die 15 in Frage kommenden Hochschulen gesichtet hat, will er im Schnelldurchlauf noch einmal die 5 vielversprechendsten anschauen und wählt das am Vortag gesetzte Browser-Bookmark an. Wo wird er landen?

Das Beispiel zeigt: Auch bei den Unterseiten eines FRAMESETs muss auf jeder Seite ein eigener Navigationsbereich vorhanden sein. Aber genau den wollten wir uns doch sparen, indem wir einen eigenen Navigationsframe einführten. Klappt leider nicht!

Suchmaschinen

Bei schätzungsweise 600000000 Internetseiten sind Suchmaschinen das wichtigste Mittel der Surfer, um uns zu finden und unser wichtigstes Mittel gefunden zu werden. Die meisten davon arbeiten mit "robots" oder "spiders", flinken Computerprogrammen, die Webseiten lesen, indizieren und in die Datenbank aufnehmen. Diese arbeiten im Prinzip wie ganz einfache Textbrowser und sie suchen nach Inhalt. Das ist aus ihrer Sicht vor allem der TITLE eines Dokuments, dann die Überschriften H1...H6, dann der eigentliche Text (manche werten auch spezielle META-Tags für Suchmaschinen aus; deren Gewichtung wurde aber stark reduziert, nachdem damit zuviel Schindluder getrieben wurde).

Was sieht ein Suchmaschinen-robot auf einer Frames-Seite? Nichts! Denn die Seite mit der Frames-Definition hat keinen Inhalt und die aufgerufenen Unterseiten werden nicht verfolgt.

Was unter Umständen gefunden und katalogisiert wird, ist der NOFRAMES-Teil (z.B. findet ein Suchmaschine den Satz "Ihr Browser unterstützt keine Frames" 44300 mal im Netz). Der führt wiederum zu den einzelnen Seiten oder zu einer extra NOFRAMES-Version der Site.

Der Surfer, der uns über eine Suchmaschine findet, kommt also vielleicht zu uns, aber genauso wie der Firmenvertreter aus obigem Beispiel entweder auf unsere Startseite oder auf eine aus dem Zusammenhang gerissene Unterseite.

Wenn man sich mit seiner Web-Präsenz zu Beginn auf eine Framsetseite festgelegt hat und heute feststellt, dass die Einzelseiten bei den namhaften Suchmaschinen nicht richtig indexiert und auch nicht wirklich gut gefunden werden, sollte man sich ernsthafte Gedanken machen. Unter Umständen kann es sinnvoll sein, einen Spezialisten für Websiteoptimierung zu Rate zu ziehen. Der Website-Optimierer sollte hierbei seriöse Suchmaschinenoptimierung betreiben. Website-Optimierer haben oft einen fragwürdigen Ruf, doch seriös arbeitende Unternehmen sind selbst bei den großen Dienstleistern für Internet-Suchanfragen (Beispiel Google) gerne gesehen; helfen Sie doch, die Qualität der Websites und damit die Qualität der Suchanfragen zu verbessern.

Die Minibrowser kommen

Die aktuellen Browser auf den gängigen Computerplattformen haben mit der Darstellung von Frames keine Probleme mehr. Auch das vielzitierte LYNX (ein Browser für Textterminals) kommt mit Frames klar (zumindest, solange nicht 7 Frames mit nichtssagenden Namen verwendet werden, von denen 5 nur gestalterischen Zwecken dienen). Es bietet die einzelnen Frames einfach als Links an.

Im Jahr 2001 schrieb ich dazu:

Aber eine neue Generation von low-end-Browsern ist im Kommen. Auf einem Handy-display oder auf einem Fernsehbildschirm ist schlichtweg kein Platz für eine Unterteilung. Diese Browser zeigen daher alle keine Frames an. Wieder stellt sich die Frage: Ist jede unserer Seiten auch ohne die Inhalte der anderen Frames aussagekräftig und navigierbar?

Mittlerweile (2011) gibt es kaum noch Mobiltelefone auf dem Markt, bei denen kein Webbroser integriert ist. Viele davon "können" Frames, aber auf den kleinen Bildschirmen wünscht man sich als Anwender oft, sie würden es gleich bleiben lassen ...

Möglichkeiten und Anwendungshinweise

Frames haben auch Vorteile und sinnvolle Anwendungen (wobei die besprochenen Nachteile bestehen bleiben). Dafür sollte man aber einige Grundregeln beachten:

Der Frames-Aufbau soll für den Nutzer nachvollziehbar sein. Eine offensichtliche Unterteilung des Browserfensters in Zeilen und Spalten kann die Übersicht erhöhen. Dies erzeugt einen multipane-Aufbau, wie ihn vor allem unter Windows viele Programme verwenden.
Die Sichtbarkeit der Grenzen ist auch Voraussetzung dafür, dass Benutzer die Grenzen mit der Maus verschieben und so zumindest von Hand ihren Gegebenheiten anpassen können.

Frames sollten immer in einem sinnvollen inhaltlichen Zusammenhang / Trennung stehen (Navigation - Haupttext, Erklärung - Beispiel).
Um nur ein Logo ständig im Blickfeld zu behalten oder um verschiedenen Bereichen verschiedene Hintergrundbilder zuzuordnen, lohnen sich Frames nicht. Dafür gibt es inzwischen weitaus einfachere und elegantere Möglichkeiten mit CSS.

Es gibt eine Möglichkeit, das Bookmark- und Link-Problem einigermassen in den Griff zu bekommen: Jeder Link zu einem neuen Thema öffnet mit TARGET="_parent" ein neues Frameset. So lassen sich über eine Vielzahl einzelner Framesets verschiedene Texte im Frame-Zusammenhang über ihren URI ansprechen. Dafür hat man noch ein mal eine Menge mehr Dateien zu erstellen und zu pflegen.

Ausblicke und Alternativen

Tabellen ...
IFRAME ...
Positionierung mit CSS ...
Includes ...

Links

André Leopold: FRAMES
Eine vollständige, deutschsprachige Einführung, die erklärt, wie es richtig geht.
HTML 4.01 Specification: Frames
Definitive Auskunft über den richtigen Aufbau eines Framesets gibt das W3C in der Recommendation für HTML 4 (vor allem der NOFRAMES-Teil wird oft falsch eingebaut!).
Web Authoring FAQ: HTML Frames
Die häufigsten Fragen zum Thema, gesammelt und beantwortet von der Web Design Group.
Frames - An Introduction
Die orginale Einführung zu Frames von Netscape. Vorsicht, sie entspricht nicht in allen Punkten den HTML4 recommendations! Der Link ist hier nur 'zur Vollständigkeit' angegeben, nicht als Empfehlung.
Warum Sie Frames vermeiden sollten
In seiner HTML-Einführung beschreibt Hubert Partl die Nachteile der Frames-Konstruktion.
Why Frames Suck (Most of the Time)
Jakob Nielsen behandelt das Thema vor dem Hintergrund seiner Untersuchungen über das Nutzerverhalten.
Search Engines And Frames
Search engines have a tough time with frames. Using frames either prevents them from finding pages within a web site, or it causes them to send visitors into a site without the proper frame "context" being established. Both problems can be corrected, with a little foresight by webmasters.
amalaya.de - webdesign: frames
Kurz, treffend, schöne Site!
Frames - Heaven or Hell
Ein Text von 1996, einige Punkte sind veraltet, trotzdem lesenswert.
[95q3] Subject: A proposal for addition to HTML 3.0: Frames
Das Elend begann am 29.09.1995:
Mit den Worten Hi. I'm the Netscape Navigator marketing guy. eröffnete Alex Edelstein seine mail an die Entwicklerliste des IEFT.
Was er zu diesem Zeitpunkt verschwieg: Netscape hatte überhaupt nicht vor, das Ergebnis der Diskussion irgendwie zu beachten. Mit der Arroganz des Marktführers brachte der Konzern das neue Feature gegen alle Bedenken auf den Markt.
Die Diskussionsbeiträge der anderen HTML-Entwickler geben mögliche Antworten auf die Frage: "Was wäre entstanden, wenn Netscape eine bessere Lösung abgewartet hatte?"

Zum Schluss...

Wie immer freue ich mich über Anmerkungen und weitere Links.


www.subotnik.net --> html --> frames | private Homepage | e-mail | Seitenanfang